C 및 C ++ 표준은 다른 특성을 가진 아키텍처가있는 경우 표준 준수 컴파일러를 작성하는 것이 매우 어렵거나 불가능하기 때문에 언어 구현 정의의 여러 측면을 남겨둔다는 것을 알고 있습니다.
나는 40 년 전에 모든 컴퓨터가 고유 한 사양을 가지고 있다는 것을 알고 있습니다. 그러나 현재 사용되는 아키텍처는 다음과 같습니다.
CHAR_BIT != 8signed2의 보수가 아닙니다 (Java에 문제가 있다고 들었습니다).- 부동 소수점은 IEEE 754와 호환되지 않습니다 (편집 : “IEEE 754 이진 인코딩이 아님”을 의미 함).
내가 묻는 이유는 사람들에게 C ++이 고정 크기 유형 † 과 같은 다른 저수준 측면을 요구하지 않는 것이 좋다고 종종 설명하기 때문 입니다. ‘다른 언어’와 달리 코드를 올바르게 사용할 때 코드를 이식 가능하게 만들기 때문에 좋습니다 (편집 : 부호 + 크기 아키텍처에 대한 2의 보수 산술과 같이 기계의 저수준 측면을 에뮬레이션하지 않고도 더 많은 아키텍처로 이식 될 수 있기 때문에) . 그러나 특정 아키텍처를 직접 가리킬 수 없다는 것은 기분이 좋지 않습니다.
질문은 무엇입니까? 위의 속성을 나타내는 아키텍처는 무엇입니까?
† uint*_ts는 선택 사항입니다.
답변
이것 좀 봐
아직 모든 Univac 소프트웨어를 마이그레이션하지 않은 사람들에게 역 호환성을 제공합니다.
키 포인트:
- 36 비트 단어
CHAR_BIT == 9- 보완하다
- 72 비트 비 IEEE 부동 소수점
- 코드와 데이터를위한 별도의 주소 공간
- 단어 주소
- 전용 스택 포인터가 없음
그들이 비록 C ++ 컴파일러를 제공하고 있는지 알고 있지만하지 마십시오 있었다 .
그리고 현재 C 매뉴얼의 최신 버전에 대한 링크가 나타났습니다.
4.5 절에는 9, 18, 36 및 72 비트의 데이터 유형 표가 있습니다.
답변
메인 프레임에 대한 가정은 없습니다. 우선 IEEE 754를 사용하는 메인 프레임에 대해 잘 모르겠습니다. IBM은 기본 16 부동 소수점을 사용하고 두 Unisys 메인 프레임은 모두 8을 사용합니다. Unisys 시스템은 다른 여러 측면에서 약간 특별합니다. Bo는 2200을 언급했습니다. MPS 아키텍처는 48 비트 태그가 붙은 단어입니다. (단어가 포인터인지 여부는 워드의 비트에 따라 달라집니다.) 그리고 숫자 표현은 부동 소수점과 정수 산술 사이에 실질적인 구분이 없도록 설계되었습니다. 부동 소수점은 밑이 8입니다. 정규화가 필요하지 않으며 내가 본 다른 모든 부동 소수점과 달리 소수점을 왼쪽이 아닌 가수의 오른쪽에 소수점을 넣고 지수에 부호가있는 크기를 사용합니다 (가수에 추가). 그 결과 정수 부동 소수점 값은 부호있는 크기 정수와 정확히 동일한 비트 표현을 갖거나 가질 수 있습니다. 부동 소수점 산술 명령어는 없습니다. 두 값의 지수가 모두 0 인 경우 명령어는 정수 산술을 수행하고, 그렇지 않으면 부동 소수점 산술을 수행합니다. (아키텍처의 태깅 철학이 계속됨)int 48 비트를 차지할 수 있으며 그 중 8은 0이어야합니다. 그렇지 않으면 값이 정수로 취급되지 않습니다.
답변
부동 소수점 구현에서는 전체 IEEE 754 준수가 거의 없습니다. 그리고 이와 관련하여 사양을 약화 시키면 많은 최적화가 가능합니다.
예를 들어, subnorm은 x87과 SSE의 차이점을 지원합니다.
소스 코드에서 분리 된 곱셈과 덧셈의 융합과 같은 최적화는 결과도 약간 변경하지만 일부 아키텍처에서는 최적화가 좋습니다.
또는 x86 엄격한 IEEE 준수에서는 내부 80 비트 부동 소수점 대신 지정된 부동 소수점 유형을 사용하도록 부동 소수점 레지스터와 일반 메모리간에 특정 플래그를 설정하거나 추가 전송이 필요할 수 있습니다.
또한 일부 플랫폼에는 하드웨어 플로트가 전혀 없으므로 소프트웨어로 에뮬레이션해야합니다. IEEE 754의 일부 요구 사항은 소프트웨어로 구현하는 데 비용이 많이들 수 있습니다. 특히 반올림 규칙이 문제가 될 수 있습니다.
제 결론은 항상 엄격한 IEEE 준수를 보장하고 싶지는 않은 상황에 대비하기 위해 이국적인 아키텍처가 필요하지 않다는 것입니다. 이러한 이유로 엄격한 IEEE 준수를 보장하는 프로그래밍 언어는 거의 없었습니다.
답변
내가 찾은 일부 시스템 목록이 링크 어디 CHAR_BIT != 8. 그들은 포함
일부 TI DSP는
CHAR_BIT == 16BlueCore-5 칩 (Cambridge Silicon Radio의 Bluetooth 칩)
CHAR_BIT ==.
16
물론 스택 오버플로에 대한 질문 이 있습니다 .8 비트 문자 이외의 플랫폼이있는 플랫폼
비 보완 시스템에 대해서는
comp.lang.c ++. moderated 에 대한 흥미로운 내용이 있습니다. 요약 : 보완 또는 부호 및 크기 표현을 가진 플랫폼이 있습니다.
답변
VAX 시스템이 여전히 사용되고 있다고 확신합니다. IEEE 부동 소수점을 지원하지 않습니다. 그들은 자신의 형식을 사용합니다. Alpha는 VAX 및 IEEE 부동 소수점 형식을 모두 지원합니다.
최신 Cray 시스템은 IEEE를 사용하지만 T90과 같은 Cray 벡터 시스템도 자체 부동 소수점 형식을 갖습니다. (내가 사용한 T90은 몇 년 전에 사용이 중단되었으므로 아직 활발하게 사용중인 제품인지는 모르겠습니다.)
T90에는 포인터와 정수에 대한 흥미로운 표현이 있습니다. 기본 주소는 64 비트 단어 만 가리킬 수 있습니다. C 및 C ++ 컴파일러는 CHAR_BIT == 8 (유닉스의 풍미 인 Unicos를 실행하고 다른 시스템과 상호 운용해야했기 때문에 필요함)을 가졌지 만 기본 주소는 64 비트 단어 만 가리킬 수있었습니다. 모든 바이트 레벨 연산은 컴파일러에 의해 합성되고 워드의 상위 3 비트에 바이트 오프셋이 저장 void*되거나 char*저장됩니다. 그리고 일부 정수 유형에는 패딩 비트가 있다고 생각합니다.
IBM 메인 프레임이 또 다른 예입니다.
반면에 이러한 특정 시스템 은 언어 표준의 변경을 반드시 배제 할 필요는 없습니다 . Cray는 C 컴파일러를 C99로 업그레이드하는 데 특별한 관심을 보이지 않았다. 아마도 C ++ 컴파일러에도 같은 내용이 적용됩니다. CHAR_BIT == 8, 전체 의미가 아닌 경우 IEEE 형식 부동 소수점, 부호있는 정수에 대한 패딩 비트가없는 2의 보수 요구와 같은 호스팅 된 구현에 대한 요구 사항을 강화하는 것이 합리적 일 수 있습니다. 오래된 시스템은 이전 언어 표준을 계속 지원할 수 있었으며 (C99가 나왔을 때 C90은 죽지 않았습니다) DSP와 같은 독립 실행 형 구현 (임베디드 시스템)에 대한 요구 사항이 느려질 수 있습니다.
반면에, 미래 시스템이 오늘날 이국적으로 여겨 질 수있는 일을해야 할 이유가있을 수 있습니다.
답변
CHAR_BITS
gcc 소스 코드 에 따르면 :
CHAR_BIT인 16에 대한 비트로 1750a는 , dsp16xx 아키텍처.
CHAR_BIT인 24에 대한 비트로 dsp56k의 구조.
CHAR_BIT인 32에 대한 비트로 c4x 구조.
다음을 수행하여 더 쉽게 찾을 수 있습니다.
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-optimizations마법사도 0의 부호 보존을 비활성화) 과 같은 특수 옵션을 사용할 수 있습니다.
답변
IEEE 754 이진 표현은 최근까지 GPU에서 흔하지 않았습니다 . GPU 부동 소수점 편집증을 참조하십시오 .
편집 : GPU 부동 소수점이 그래픽과 관련이없는 일반적인 컴퓨터 프로그래밍과 관련이 있는지에 대한 의견이 제기되었습니다. 당근 빠따 지! 오늘날 산업적으로 계산 된 대부분의 고성능 작업은 GPU에서 수행됩니다. 이 목록에는 AI, 데이터 마이닝, 신경망, 물리적 시뮬레이션, 일기 예보 등이 포함됩니다. 주석의 링크 중 하나는 이유를 보여줍니다 . GPU의 소수 자릿수 부동 소수점 이점.
내가 추가하고 싶은 또 다른 것은 OP 질문과 관련이 있습니다 .10-15 년 전 사람들이 GPU 부동 소수점이 IEEE가 아니고 오늘날의 OpenCL 또는 CUDA와 같은 API가 없어서 GPU를 프로그래밍하지 않았을 때 사람들은 무엇을 했습니까? 초기 GPU 컴퓨팅 개척자들은 API없이 GPU 를 프로그래밍 하여 관리 할 수있었습니다 . 나는 회사에서 그들 중 하나를 만났다. 그가 한 일은 다음과 같습니다. 그는 자신이 작업 한 값을 나타내는 픽셀로 이미지로 계산하는 데 필요한 데이터를 인코딩 한 다음 OpenGL을 사용하여 필요한 작업을 수행했습니다 (예 : “가우시안 블러”와 같이 정규 분포의 회선을 나타냅니다. , 결과 이미지를 다시 결과 배열로 디코딩했습니다. 그리고 이것은 여전히 CPU를 사용하는 것보다 빠릅니다!
NVidia는 내부 데이터 바이너리를 IEEE와 호환 가능하게하고 이미지 조작보다는 계산에 중점을 둔 API를 도입하게되었습니다.