8 비트 문자 이외의 플랫폼이있는 플랫폼은 무엇입니까?

때때로, 누군가 SO char(일명 '바이트')가 반드시 8 비트는 아니라고 지적합니다 .

8 비트 char는 거의 보편적 인 것 같습니다 . 주류 플랫폼의 char경우 시장에서 생존 가능성을 보장하기 위해 8 비트가 필요하다고 생각했을 것 입니다.

현재와 ​​역사적으로 char8 비트가 아닌 어떤 플랫폼을 사용 하며 왜 "일반"8 비트와 다른가?

코드를 작성하고 플랫폼 간 지원 (예 : 범용 라이브러리)에 대해 생각할 때 8 비트가 아닌 플랫폼에 어떤 종류의 고려가 필요 char합니까?

과거 char에는 16 비트 인 일부 아날로그 장치 DSP를 살펴 보았습니다 . DSP는 내가 생각하는 틈새 아키텍처입니다. (그 당시에도 수작업으로 코딩 된 어셈블러는 사용 가능한 C 컴파일러가 할 수있는 것을 쉽게 이길 수 있었으므로 해당 플랫폼에서 C에 대한 경험이 많지 않았습니다.)

char또한 Texas Instruments C54x DSP에서 16 비트로, 예를 들어 OMAP2에서 나타났습니다. 16 비트와 32 비트의 다른 DSP가 있습니다 char. 24 비트 DSP에 대해 들어 본 것 같지만 무엇을 기억할 수 없으므로 상상했을 수도 있습니다.

또 다른 고려 사항은 POSIX가 위임한다는 것 CHAR_BIT == 8입니다. 따라서 POSIX를 사용하는 경우 가정 할 수 있습니다. 누군가가 나중에 POSIX를 거의 구현하기 위해 코드를 이식 해야하는 경우 사용하는 기능이 다르지만 크기가 다르기 char때문에 불행한 일입니다.

그러나 일반적으로 문제를 해결하는 것보다 문제를 해결하는 것이 거의 항상 쉽다고 생각합니다. 그냥 입력하십시오 CHAR_BIT. 정확한 8 비트 유형을 원하면을 사용하십시오 int8_t. 예상치 못한 크기를 자동으로 사용하는 대신 코드를 제공하지 않는 구현에서 코드가 시끄럽게 컴파일되지 않습니다. 적어도, 내가 그럴만 한 이유가있는 사건에 부딪쳤다면, 나는 그것을 주장 할 것입니다.

코드를 작성하고 플랫폼 간 지원 (예 : 범용 라이브러리)에 대해 생각할 때 8 비트가 아닌 문자가있는 플랫폼에 어떤 종류의 고려가 필요합니까?

규칙에 따라 행동 할 때 "고려해야 할 가치"는 그리 크지 않습니다. 예를 들어 C ++에서 표준은 모든 바이트가 "최소한"8 비트를 가질 것이라고 말합니다. 코드에서 바이트가 정확히 8 비트라고 가정하면 표준을 위반하는 것입니다.

" 물론 모든 바이트에는 8 비트가 있습니다!"라는 말이 들립니다. 그러나 많은 영리한 사람들이 보장되지 않은 가정에 의존하고 모든 것이 파산되었습니다. 역사는 그러한 예들로 가득합니다.

예를 들어, 90 년대 초반의 대부분의 개발자들은 대부분의 소비자 CPU가 거의 동등한 전력을 사용하기 때문에 고정 된 횟수의주기를 갖는 특정 비 작동 CPU 타이밍 지연이 일정량의 클럭 시간을 필요로한다고 가정했습니다. 불행히도 컴퓨터는 매우 빠르게 빨라졌습니다. 아이러니하게도 시간 지연 기술을 사용하는 게임을 적절한 속도로 재생할 수 있도록 컴퓨터 속도를 낮추는 것이 목적인 "터보"버튼으로 상자가 등장했습니다.

한 의견 제시자는 표준에서 char이 최소 8 비트를 가져야한다고 말하는 곳을 물었습니다. 섹션 5.2.4.2.1에 있습니다. 이 섹션에서는 CHAR_BIT주소를 지정할 수있는 가장 작은 엔티티의 비트 수를 정의 하고 기본값은 8입니다.

그들의 구현-정의 된 값은 동일한 부호로 표시된 것 이상의 크기 (절대 값) 이상이어야한다.

따라서 8 이상의 숫자는로 구현을 대체하기에 적합합니다 CHAR_BIT.

36 비트 아키텍처를 가진 머신은 9 비트 바이트를 갖습니다. Wikipedia에 따르면 36 비트 아키텍처를 가진 머신 은 다음과 같습니다.

• Digital Equipment Corporation PDP-6 / 10
• IBM 701/704/709/7090/7094
• UNIVAC 1103 / 1103A / 1105 / 1100 / 2200,

내가 알고있는 몇 가지 :

• DEC PDP-10 : 가변적이지만 대부분의 경우 7 비트 문자는 36 비트 워드 당 5 개, 그렇지 않으면 9 비트 문자, 워드 당 4 개
• 제어 데이터 메인 프레임 (CDC-6400, 6500, 6600, 7600, Cyber ​​170, Cyber ​​176 등) 6 비트 문자 (60 비트 워드 당 10 개).
• 유니시스 메인 프레임 : 9 비트 / 바이트
• Windows CE :`char` 유형을 전혀 지원하지 않습니다. 대신 16 비트 wchar_t가 필요합니다.

완전히 이식 가능한 코드는 없습니다. :-)

예, 다양한 바이트 / 문자 크기가있을 수 있습니다. 예, CHAR_BIT및의 값이 매우 특이한 플랫폼에 대해 C / C ++ 구현이있을 수 있습니다 UCHAR_MAX. 예, 때로는 문자 크기에 의존하지 않는 코드를 작성할 수 있습니다.

그러나 거의 모든 실제 코드는 독립형이 아닙니다. 예를 들어 바이너리 메시지를 네트워크로 보내는 코드를 작성하고있을 수 있습니다 (프로토콜은 중요하지 않습니다). 필요한 필드가 포함 된 구조를 정의 할 수 있습니다. 직렬화 해야하는 것보다. 구조를 출력 버퍼에 바이너리로 복사하는 것은 이식성이 없습니다. 일반적으로 플랫폼의 바이트 순서 나 구조 멤버 정렬을 모르므로 구조는 데이터를 보유하지만 데이터를 직렬화하는 방법은 설명하지 않습니다. .

확인. 바이트 순서 변환을 수행 하고 버퍼를 uint32_t사용하여 구조 멤버 (예 : 또는 이와 유사한)를 이동할 수 있습니다 memcpy. 왜 memcpy? 대상 주소가 올바르게 정렬되지 않은 경우 32 비트 (16 비트, 64 비트-차이 없음)를 작성할 수없는 플랫폼이 많이 있기 때문입니다.

따라서 이미 이식성을 달성하기 위해 많은 노력을 기울였습니다.

그리고 이제 마지막 질문입니다. 버퍼가 있습니다. 데이터가 TCP / IP 네트워크로 전송됩니다. 이러한 네트워크는 8 비트 바이트를 가정합니다. 문제는 버퍼의 유형은 무엇입니까? 당신의 문자가 9 비트라면? 16 비트라면? 24? 어쩌면 각 문자는 네트워크로 전송 된 하나의 8 비트 바이트에 해당하며 8 비트 만 사용됩니까? 아니면 여러 네트워크 바이트가 24/16/9 비트 문자로 압축되어 있습니까? 그것은 하나의 질문이며, 모든 경우에 맞는 단일 답변이 있다고 믿기가 어렵습니다. 많은 것은 대상 플랫폼의 소켓 구현에 달려 있습니다.

그래서 내가 말하는 것. 일반적으로 코드는 어느 정도 쉽게 이식 할 수 있습니다 . 다른 플랫폼에서 코드를 사용할 것으로 예상되면 그렇게하는 것이 매우 중요합니다. 그러나 실제 코드는 거의 항상 다른 코드 (위의 예제에서 소켓 구현)에 의존 하기 때문에 그 측정 이상의 이식성을 향상시키는 것은 많은 노력이 필요하고 종종 거의 제공하지 않는 것 입니다. 8 비트 이외의 바이트가있는 플랫폼에서 작동하는 코드 기능의 약 90 %가 8 비트에 바인딩 된 환경을 사용하기 때문에 거의 쓸모가 없다고 확신합니다. 바이트 크기를 확인하고 컴파일 시간 어설 션을 수행하십시오. 매우 특이한 플랫폼을 위해서는 많은 것을 다시 작성해야 할 것입니다.

그러나 코드가 "독립형"이라면 왜 안될까요? 다른 바이트 크기를 허용하는 방식으로 작성할 수 있습니다.

창고에서 IM6100 (즉, 칩의 PDP-8)을 계속 구입할 수 있습니다 . 12 비트 아키텍처입니다.

많은 DSP 칩에는 16 비트 또는 32 비트가 char있습니다. TI는 일상적으로 이러한 칩 을 만듭니다 .

예를 들어, C 및 C ++ 프로그래밍 언어는 바이트를 "실행 환경의 기본 문자 세트의 멤버를 보유 할 수있을 정도로 큰 주소 지정 가능 데이터 단위"(C 표준 3.6 절)로 정의합니다. C 문자 적분 데이터 타입은 8 비트 이상을 포함해야하기 때문에 (5.2.4.2.1 절) C의 바이트는 적어도 256 개의 다른 값을 보유 할 수 있습니다. C 및 C ++의 다양한 구현은 바이트를 8, 9, 16, 32 또는 36 비트로 정의합니다.

http://en.wikipedia.org/wiki/Byte#History 에서 인용

다른 언어에 대해서는 확실하지 않습니다.

http://en.wikipedia.org/wiki/IBM_7030_Stretch#Data_Formats

해당 머신의 바이트를 가변 길이로 정의

DEC PDP-8 제품군에는 출력에 주로 8 비트 ASCII를 사용했지만 (주로 Teletype에서) 12 비트 워드가있었습니다. 그러나 단일 12 비트 워드로 2 개의 문자를 인코딩 할 수있는 6 비트 문자 코드도있었습니다.

하나의 유니 코드 문자는 8 비트보다 깁니다. 앞에서 언급했듯이 C 스펙은 최소 크기로 데이터 유형을 정의합니다. 데이터 유형을 조사하고 구성 및 아키텍처에 대한 정확한 크기를 찾으려면 사용 sizeof및 값을 사용하십시오 limits.h.

이러한 이유로 uint16_t특정 비트 길이의 데이터 유형이 필요할 때 와 같은 데이터 유형을 고수하려고합니다 .

편집 : 죄송합니다. 처음에 귀하의 질문을 잘못 읽었습니다.

C 스펙은 char객체가 "실행 문자 세트의 모든 멤버를 저장할만큼 충분히 크다" 고 말합니다 . limits.h8 비트의 최소 크기를 나열하지만 정의는 최대 크기를 char열어 둡니다 .

따라서 a char는 아키텍처의 실행 세트에서 가장 큰 문자 (일반적으로 가장 가까운 8 비트 경계로 반올림)만큼 길어야합니다. 아키텍처에 더 긴 opcode가 있으면 char크기가 더 길어질 수 있습니다.

역사적으로 x86 플랫폼의 opcode는 1 바이트 길이 였으므로 char처음에는 8 비트 값이었습니다. 현재 x86 플랫폼은 1 바이트보다 긴 opcode를 지원하지만 char프로그래머 (및 많은 양의 기존 x86 코드)가 조정하는 길이이므로 8 비트 길이로 유지됩니다.

다중 플랫폼 지원에 대해 생각할 때에 정의 된 유형을 활용하십시오 stdint.h. 당신이 uint16_t (예를 들어)를 사용하는 경우, 당신은 확인이 값이 16 비트 값의 대응 여부에, 어떤 아키텍처에 부호없는 16 비트 값이라고 할 수있다 char, short, int다른, 또는 뭔가. 대부분의 어려운 작업은 이미 컴파일러 / 표준 라이브러리를 작성한 사람들이 수행했습니다.

char저수준의 하드웨어 조작이 필요하기 때문에 정확한 크기를 알아야하는 경우 일반적으로 char지원되는 모든 플랫폼 을 보유하고 (보통 16 비트이면 충분합니다) 데이터 유형을 사용 합니다. convert_to_machine_char정확한 기계 표현이 필요할 때 루틴을 통한 가치 . 그렇게하면 플랫폼 별 코드가 인터페이스 기능에 국한되며 대부분 normal을 사용할 수 있습니다 uint16_t.

8 비트가 아닌 문자가있는 플랫폼에는 어떤 종류의 고려가 필요합니까?

예를 들어 변속 할 때 마법 번호가 발생합니다.

이들 중 대부분은 CHAR_BIT 및 예를 들어 8 및 255 (또는 유사한) 대신 UCHAR_MAX를 사용하여 매우 간단하게 처리 할 수 ​​있습니다.

희망적으로 당신의 구현은 그것들을 정의합니다 :)

"일반적인"문제입니다 .....

또 다른 간접적 인 문제는 다음과 같습니다.

struct xyz {
   uchar baz;
   uchar blah;
   uchar buzz; 
}

이것은 하나의 플랫폼에서 24 비트 만 "만"(가장 좋은 경우) 취할 수 있지만 다른 곳에서는 72 비트가 필요할 수 있습니다.

각 uchar에 "비트 플래그"가 있고 각 uchar에 현재 사용중인 2 개의 "유의 한"비트 또는 플래그 만 있고 "명확도"를 위해 3 개의 uchar로만 구성한 경우 상대적으로 "더 낭비"가 될 수 있습니다. 24 비트 uchar가있는 플랫폼

비트 필드는 해결할 수 없지만 조심해야 할 다른 것들이 있습니다 ....

이 경우, 하나의 열거 형만으로 실제로 필요한 "가장 작은"크기의 정수를 얻을 수 있습니다.

아마도 실제 예제는 아니지만 코드를 이식 / 재생할 때이 "비트"와 같은 것들 .....

만약 uchar가 "정상적으로"예상되는 것보다 3 배 크다면, 그러한 구조는 일부 플랫폼에서 많은 메모리를 낭비 할 수 있습니다. "..." "일반적으로"큰 문제는 아닙니다 .... .

따라서 uchar가 다른 플랫폼보다 사용 가능한 RAM에 비해 한 플랫폼에서 "매우 낭비가 적지 않다"는 가정으로 인해 여전히 "손상"되거나이 경우 "많은 메모리를 매우 빠르게 낭비"할 수 있습니다. ..

예를 들어 int 또는 다른 유형의 경우 더 두드러 질 수 있습니다. 예를 들어 15 비트가 필요한 일부 구조가 있으므로 int에 고정하지만 다른 플랫폼에서는 int가 48 비트 또는 기타입니다 .... .

"일반적으로"2 uchar로 나눌 수 있지만, 예를 들어 24 비트 uchar에서는 하나만 필요합니다.

열거 형이 더 나은 "일반적인"솔루션이 될 수 있습니다 ....

그래도 비트에 액세스하는 방법에 따라 다릅니다. :)

따라서 머리를 뒤로하는 "디자인 결함"이있을 수 있습니다 ... 코드가 uchar 또는 uint의 크기에 관계없이 여전히 작동 / 실행될 수있는 경우에도 ...

코드에 "마법의 숫자"가 없더라도주의해야 할 사항이 있습니다 ...

이것이 의미가 있기를 바랍니다 :)

int는 16 비트 (pdp11 등)였습니다. 32 비트 아키텍처로가는 것은 어려웠습니다. 사람들은 점점 나아지고 있습니다. 어떤 사람도 포인터가 더 이상 길게 맞을 것이라고 생각하지 않습니다 (당신이 옳지 않습니까?). 또는 파일 오프셋 또는 타임 스탬프 또는 ...

8 비트 문자는 이미 다소 비동기 적입니다. 우리는 이미 모든 세계의 문자 집합을 보유하기 위해 32 비트가 필요합니다.