표준위원회가 주목하는 이국적인 아키텍처

표준위원회가 주목하는 이국적인 아키텍처

C와 C++ 규격은 다른 특성을 가진 아키텍처가 있는 경우 표준 적합 컴파일러를 작성하는 것이 매우 어렵거나 불가능하기 때문에 언어 구현 정의의 많은 측면을 남겨두고 있다는 것을 알고 있습니다.

40년 전만 해도 컴퓨터마다 독자적인 사양이 있었던 것을 알고 있습니다.그러나 현재 다음과 같은 용도로 사용되는 아키텍처는 없습니다.

• CHAR_BIT != 8
• signed2개의 보완물이 아닙니다(Java에서 문제가 있었다고 들었습니다).
• 부동 소수점은 IEEE 754에 준거하지 않습니다(편집:「IEEE 754 바이너리 부호화 없음」을 의미합니다.

제가 질문하는 이유는 C++가 고정 사이즈^† 타입과 같은 다른 낮은 레벨의 측면을 요구하지 않는 것이 좋다고 사람들에게 자주 설명하기 때문입니다.이는 '다른 언어'와 달리 올바르게 사용하면 코드를 이식할 수 있기 때문에 좋습니다(편집: 2개의 보완 산술 온사인+크기 아키텍처 등 기계의 낮은 수준의 측면에 대한 에뮬레이션 없이 더 많은 아키텍처로 이식할 수 있기 때문입니다).하지만 제가 직접 어떤 건축물을 가리킬 수 없어서 아쉽습니다.

따라서 위의 특성을 나타내는 아키텍처는 무엇입니까?

†uint*_t는 옵션입니다.

이것 좀 봐

Unisys ClearPath Dorado 서버

모든 Univac 소프트웨어를 아직 이행하지 않은 사용자에게 하위 호환성을 제공합니다.

요점:

• 36비트 워드
• CHAR_BIT == 9
• 보충역
• 72비트 비 IEEE 부동소수점
• 코드와 데이터를 위한 별도의 주소 공간
• 단어 변환
• 전용 스택 포인터 없음

그들이 C++ 컴파일러를 제공하는지는 모르겠지만, 그들은 할 수 있다.

---

그리고 C매뉴얼의 최신판에 대한 링크가 공개되었습니다.

Unisys C 컴파일러 프로그래밍 참조 매뉴얼

섹션 4.5에는 9, 18, 36 및 72비트의 데이터 유형 표가 있습니다.

메인프레임에 대한 전제 조건 중 어느 것도 성립하지 않습니다.IEEE 754의 경우, IEEE 754는 IEEE 754로 지정됩니다.IBM(R) Base 16(R) Unisys(R) Base 8(R)Unisys ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★」Bo는 2200 아키텍처에 대해 언급했지만 MPS 아키텍처는 더 이상합니다. 48비트 태그가 달린 단어입니다. (단어가 포인터인지 아닌지는 단어에 따라 다릅니다.)그리고 숫자 표현은 부동소수와 적분 산술 사이에 실질적인 구분이 없도록 설계되어 있습니다. 8시 정각 이치노 )지수(가수 추가)입니다.그 결과 정수 부동 소수점 값은 부호 있는 크기 정수와 정확히 동일한 비트 표현을 가질 수 있습니다.부동소수점 산술 명령어는 없습니다.).（ 텍 ( ( ( ( ( ( ( 。은 즉, 그 which which which which which는 동안,int48번입니다.8시 0시 0시 0으로 하다.그렇지 않으면 값은 정수로 취급되지 않습니다.

이 링크를 찾았는데 이 링크에는CHAR_BIT != 8 것들이 있습니다.

TI 에는 'TI DSP'가 있습니다.CHAR_BIT == 16

칩칩은, 「Cambridge Silicon Radio」(Cambridge Silicon Radio)를 탑재하고 있습니다.CHAR_BIT == 16.

물론 Stack Overflow에 대한 질문도 있습니다.8비트 문자 이외의 것을 가진 플랫폼은 무엇입니까?

2가 아닌 보완 시스템에 대해서는 comp.lang.c++.moderated에 관한 흥미로운 정보가 있습니다.요약: 자신의 보완 또는 기호와 크기를 나타내는 플랫폼이 있습니다.

저는 VAX 시스템이 아직 사용되고 있다고 확신합니다.IEEE 부동소수는 지원되지 않습니다.자체 포맷을 사용합니다.Alpha는 VAX 형식과 IEEE 부동소수점 형식을 모두 지원합니다.

새로운 Cray 시스템은 IEEE를 사용하지만, T90과 같은 Cray 벡터 머신도 독자적인 부동소수점 포맷을 가지고 있습니다(제가 사용한 T90은 몇 년 전에 폐기되었습니다.아직도 사용되고 있는지 모르겠습니다).

또한 T90은 포인터와 정수에 대한 몇 가지 흥미로운 표현을 가지고 있습니다.네이티브 주소는 64비트 단어만 가리킬 수 있습니다. 및 에는 CHAR_BC '++'CHAR_B'가 있습니다.IT==8(Unicos, Unix의 풍미인 Unicos를 실행하고 다른 시스템과 상호 운용해야 했기 때문에 사용 가능)이지만 네이티브 주소는 64비트 단어만 가리킬 수 있습니다.되었습니다.void* ★★★★★★★★★★★★★★★★★」char*바이트 오프셋을 워드의 상위 3비트에 저장합니다.어떤 정수형은 패딩 비트가 있었던 것 같아요.

IBM 메인프레임은 또 다른 예입니다.

한편, 이러한 특정 시스템은 언어 표준의 변경을 반드시 막을 필요는 없습니다.Cray는 C 컴파일러를 C99로 업그레이드하는 데 특별한 관심을 보이지 않았습니다.아마도 같은 것이 C++ 컴파일러에도 적용되었을 것입니다.CHAR_B를 요구하는 등 호스트형 구현에 대한 요건을 강화하는 것이 합리적일 수 있습니다.IT==8, IEEE 형식 부동 소수점(전체 의미론 아님) 및 부호 있는 정수에 대한 패딩 비트가 없는 2's-recision.구식 시스템은 이전 언어 표준을 계속 지원할 수 있었고(C90은 C99가 나왔을 때 사용되지 않았으며), DSP와 같은 구현(임베디드 시스템)에 대한 요구사항은 더 느슨할 수 있습니다.

한편, 미래 시스템이 오늘날에는 이국적으로 여겨질 만한 일들을 해야 할 타당한 이유가 있을 수 있습니다.

CHAR_비트

gcc 소스 코드:

CHAR_BIT161750a, dsp16xx 아키텍처용 비트입니다.
CHAR_BIT24dsp56k 아키텍처용 비트.
CHAR_BIT32c4x 아키텍처용 비트

다음 작업을 통해 더 많은 정보를 쉽게 찾을 수 있습니다.

find $GCC_SOURCE_TREE -type f | xargs grep "#define CHAR_TYPE_SIZE"

또는

find $GCC_SOURCE_TREE -type f | xargs grep "#define BITS_PER_UNIT"

CHAR_TYPE_SIZE이치노

IEEE 754 준거

타깃 아키텍처가 부동소수점 명령을 지원하지 않는 경우 gcc가 소프트웨어 폴백위치를 생성하는 것은 기본적으로는 표준 규격에 준거하지 않습니다.그 이상의 특별한 옵션(예:-funsafe-math-optimizationswitch는 또한 0에 대한 부호 보존을 비활성화합니다.)를 사용할 수 있습니다.

부동소수점 실장에서는 IEEE 754에 완전히 준거한 경우는 거의 없습니다.그리고 이 점에서 사양을 약화시키면 많은 최적화가 가능합니다.

예를 들어, 하위 규격은 x87과 SSE 사이의 차이점을 지원합니다.

소스 코드에서 분리된 곱셈 및 덧셈과 같은 최적화는 결과도 약간 변화하지만 일부 아키텍처에서는 좋은 최적화입니다.

또는 x86의 엄격한 IEEE 준거에서는 특정 플래그를 설정하거나 부동소수점 레지스터와 일반 메모리 간에 추가 전송하여 내부 80비트 부동소수점 유형을 사용하도록 강제해야 할 수 있습니다.

또한 일부 플랫폼에는 하드웨어 플로트가 전혀 없기 때문에 소프트웨어에서 에뮬레이트해야 합니다.또, IEEE 754 의 요건의 일부는, 소프트웨어에 실장하기 위해서 비용이 많이 드는 경우가 있습니다.특히 반올림 규칙이 문제가 될 수 있습니다.

결론은 엄격한 IEEE 컴플라이언스를 항상 보장하고 싶지 않다면 상황에 대응하기 위해 이국적인 아키텍처가 필요하지 않다는 것입니다.이 때문에 엄격한 IEEE 준거를 보증하는 프로그래밍 언어는 거의 없었습니다.

IEEE 754 바이너리 표현은 최근까지 GPU에서 일반적이지 않았습니다. GPU 부동 소수점 편집증을 참조하십시오.

편집: GPU 부동 소수점이 그래픽과 무관한 일반적인 컴퓨터 프로그래밍과 관련이 있는지 여부에 대한 질문이 댓글에 제기되었습니다.그래, 맞아!오늘날 산업적으로 계산된 대부분의 고성능은 GPU에서 수행됩니다. 목록에는 AI, 데이터 마이닝, 신경 네트워크, 물리적 시뮬레이션, 일기 예보 등이 포함됩니다.코멘트의 링크 중 하나는 그 이유를 나타내고 있습니다.GPU의 부동소수점 우위성이 크기입니다.

또 하나 덧붙이고 싶은 것은 OP 질문입니다.GPU 부동소수가 IEEE가 아니었던 10~15년 전에 GPU 프로그래밍에 OpenCL이나 CUDA 등의 API가 없었던 시기에는 어떤 작업을 했을까요?믿거나 말거나 초기 GPU 컴퓨팅의 선구자들은 API 없이 GPU를 프로그래밍할 수 있었습니다.우리 회사에서 그들 중 한 명을 만났어요.그는 다음과 같은 작업을 했습니다.연산에 필요한 데이터를 이미지로서 부호화한 후 OpenGL을 사용하여 필요한 연산(예를 들어 정규 분포를 사용하여 "가우스 블러"를 표시함)을 수행하고 결과 이미지를 일련의 결과물로 디코딩했습니다.그리고 이것은 여전히 CPU를 사용하는 것보다 더 빨랐습니다!

이러한 이유로 NVidia는 내부 데이터 바이너리를 IEEE와 호환되게 하고 이미지 조작이 아닌 연산 지향의 API를 도입하게 되었습니다.

언급URL : https://stackoverflow.com/questions/6971886/exotic-architectures-the-standards-committees-care-about