팻 바이너리

Fat binary
Portable 실행 파일 또는 Portable 응용 프로그램과 혼동하지 마십시오.

팻 바이너리(또는 멀티 아키텍처 바이너리)는 여러 명령어 세트에 고유한 코드를 사용하여 확장(또는 "패턴 처리"된 컴퓨터 실행 가능 프로그램 또는 라이브러리이며, 결과적으로 여러 프로세서 [1]유형에서 실행될 수 있습니다.따라서 일반적인 단일 아키텍처 바이너리 파일보다 큰 파일이 생성되므로 이름이 지정됩니다.

일반적인 구현 방법은 각 명령 집합의 기계 코드 버전을 포함하며, 그 앞에 모든 운영 체제와 호환되는 코드를 가진 단일 입력 지점을 포함하면 해당 섹션으로 건너뜁니다.대체 구현에서는 서로 다른 실행 파일을 서로 다른 포크에 저장합니다. 각 포크는 운영 체제에서 직접 사용하는 고유한 진입점을 가집니다.

팻 바이너리를 사용하는 것은 운영체제 소프트웨어에서는 흔하지 않습니다.설치 프로그램을 사용하여 설치 시 아키텍처 고유의 바이너리를 선택하고(예를 들어 Android의 여러 APK), 실행 시 아키텍처 고유의 바이너리를 선택하는 등 동일한 문제를 해결할 수 있는 몇 가지 대안이 있습니다(예: Plan 9의 Union Direct).ories 및 GNUstep의 Fat 번들,[2][3] 소스 코드 형식으로 소프트웨어를 배포하고 인플레이스 컴파일, 가상 머신(예: Java) 및 Just-In-Time 컴파일을 사용할 수 있습니다.

아폴로

아폴로 복합 실행 파일

1988년, 아폴로 컴퓨터의 도메인/OS SR10.1은 모토로라 680x0 및 아폴로 프리즘 실행 [4]파일용 바이너리를 번들한 새로운 파일 형식인 "cmpexe"(복합 실행 파일)를 도입했습니다.

사과

애플의 지방 2진수

1994년부터 68k 마이크로프로세서에서 파워로 전환된 Apple Macintosh는 이원적인 계획을 통해 원활하게 운영되었습니다.PC 마이크로프로세서오래된 플랫폼의 많은 애플리케이션은 진화하는 에뮬레이션 방식 하에서 새로운 플랫폼에서 투과적으로 실행되었지만 에뮬레이션된 코드는 일반적으로 네이티브 코드보다 느리게 실행됩니다."팻 바이너리"로 출시된 애플리케이션은 더 많은 스토리지 공간을 차지했지만 두 플랫폼 모두에서 최대 속도로 실행되었습니다.이는 동일한 프로그램의 68000 컴파일 버전과 PowerPC 컴파일 버전을 모두 실행 [5][6]파일로 패키지함으로써 실현되었습니다.이전 68K 코드(CFM-68K 또는 클래식 68K)는 리소스 포크에 계속 저장되지만 최신 Power는 계속 저장되었습니다.PC 코드는 데이터 포크에 PEF [7][8][9]형식으로 포함되어 있습니다.

팻 바이너리가 Power만을 지원하는 프로그램보다 컸습니다.PC 또는 68k로 인해 불필요한 [5][6]버전을 제거할 수 있는 다수의 유틸리티가 생성되었습니다.80MB 하드 드라이브가 일반적인 크기였던 소형 하드 드라이브 시대에는 이러한 유틸리티가 유용하기도 했습니다. 프로그램 코드가 일반적으로 전체 드라이브 사용량의 많은 부분을 차지했기 때문입니다. 따라서 불필요한 바이너리 구성원을 제거하면 하드 드라이브의 상당한 공간을 확보할 수 있습니다.

NeXT/Apple의 멀티 아키텍처 바이너리

NextSTEP 멀티 아키텍처 바이너리

Fat 바이너리는 NextSTEP 3.1부터 NextSTEP/OPENSTEP 운영 체제의 기능입니다.NextSTEP에서는 이들을 "멀티 아키텍처 바이너리"라고 불렀습니다.멀티아키텍처 바이너리는 원래 NeXT의 Motorola 68k 기반 하드웨어와 NeXTSTEP를 실행하는 Intel IA-32 기반 PC 모두에서 실행할 수 있도록 소프트웨어를 컴파일하는 것을 목적으로 하고 있습니다.두 플랫폼 [10]모두 하나의 바이너리 파일을 사용합니다.나중에 PC에서 OPENSTEP 응용 프로그램을 실행할 수 있도록 하고 다양한 RISC 플랫폼 OPENSTEP을 지원하기 위해 사용되었습니다.Multi-Architecture Binary 파일은 Multi-Architecture Binary에서 지원되는 각 아키텍처에 대해 1개 이상의 Mach-O 하위 파일을 저장하는 특수 아카이브 형식입니다.모든 멀티아키텍처 바이너리는 구조에서 시작합니다(struct fat_header)는 부호 없는 2개의 정수를 포함합니다.첫 번째 정수("magic")는 이 파일을 Fat Binary로 식별하기 위한 매직 번호로 사용됩니다.두 번째 정수(nfat_arch)는 아카이브에 포함된 Mach-O 파일 수(다른 아키텍처에 대해 동일한 프로그램의 인스턴스 수)를 정의합니다.이 헤더 뒤에는 nfat_arch 수의 fat_arch 구조가 있습니다(struct fat_arch이 구조는 파일, 얼라인먼트, 크기 및 (아카이브 내의) 마하-O 바이너리를 대상으로 하는 CPU 타입과 서브 타입을 찾는 오프셋을 정의합니다.

Developer Tools와 함께 제공되는 GNU 컴파일러 컬렉션 버전은 NeXTStep이 실행할 수 있는 다른 아키텍처의 소스 코드를 교차 컴파일할 수 있었습니다.예를 들어, (아키텍처를 인수로 하여) 여러 '-arch' 옵션을 사용하여 대상 아키텍처를 선택할 수 있었습니다.이는 다양한 아키텍처에서 실행되는 NeXTStep용 프로그램을 배포하는 편리한 방법입니다.

또한 다른 대상 객체 파일을 사용하여 라이브러리(예: NeXTStep의 libtool 사용)를 생성할 수도 있습니다.

Mach-O 및 Mac OS X

애플 컴퓨터는 1996년에 NeXT를 인수하여 OPENSTEP 코드로 작업을 계속했다.Mach-O는 Apple의 무료 Darwin 운영 체제(2000)와 Apple Mac OS X(2001)에서 네이티브 객체 파일 형식이 되었으며 NeXT의 Multi-Architecture Binarys는 운영 체제에서 계속 지원되었습니다.Mac OS X에서는 멀티 아키텍처 바이너리를 사용하여 여러 종류의 아키텍처를 지원할 수 있습니다. 예를 들어 Power에 최적화된 32비트 코드 버전이 서로 다릅니다.PC G3, 전원PC G4 및 전원PC 970 세대의 프로세서.또한 32비트 및 64비트 PowerPC, PowerPC 및 x86, x86-64 및 ARM64 [11]등의 여러 아키텍처를 지원하는 데도 사용할 수 있습니다.

애플의 유니버설 바이너리

주요 기사:유니버설 바이너리
Apple 유니버설 바이너리 로고

2005년, Apple은 PowerPC 프로세서에서 Intel x86 프로세서로의 이행을 발표했습니다.애플은 멀티아키텍처 바이너리 [12]형식의 실행 파일을 사용하여 PowerPC와 x86을 네이티브로 지원하는 새로운 애플리케이션의 배포를 촉진했습니다.Apple은 이러한 프로그램을 "Universal Applications"라고 부르며, 파일 형식을 이전 전환 또는 멀티 아키텍처 바이너리 형식의 다른 용도와 구별하기 위한 방법으로 "Universal Binary"라고 부릅니다.

2006년부터 2011년까지 애플은 PowerPC(PPC)에서 x86으로 변환하는 다이내믹 바이너리 변환기인 Rosetta를 공급하여 기존 네이티브 PowerPC 어플리케이션의 포워드 이행에 유니버설 바이너리 포맷은 필요 없습니다.그러나 Rosetta는 성능 오버헤드가 상당히 높았기 때문에 개발자들은 유니버설 바이너리를 사용하여 PPC와 인텔 바이너리를 모두 제공할 것을 권장받았다.유니버설 바이너리의 분명한 비용은 설치된 모든 실행 파일이 더 크다는 것입니다. 그러나 PPC 출시 이후 몇 년 동안 하드 드라이브 공간이 실행 파일 크기를 크게 앞질렀습니다. 반면 유니버설 바이너리는 동일한 애플리케이션의 단일 플랫폼 버전보다 두 배 크기일 수 있지만 빈 공간 리소스는 일반적으로 코드 크기를 줄입니다.사소한 문제가 됩니다.실제로 유니버설 바이너리 어플리케이션은 중복되는 것이 아니라 프로그램 자원을 공유할 수 있기 때문에 보통 2개의 싱글 아키텍처 어플리케이션보다 작습니다.모든 아키텍처가 필요하지 않은 경우 lipo 및 ditto 명령줄 애플리케이션을 사용하여 멀티 아키텍처 바이너리 이미지에서 버전을 삭제함으로써 씬 바이너리라고도 불리는 것을 만들 수 있습니다.

또한 Multi-Architecture Binary 실행 파일에는 PowerPC와 x86의 32비트 버전과 64비트 버전 모두에 대한 코드가 포함될 수 있으므로 32비트 프로세서를 지원하지만 64비트 프로세서에서 실행할 경우 더 큰 주소 공간과 더 넓은 데이터 경로를 사용하는 형태로 애플리케이션을 출하할 수 있습니다.

2.1~3.2 버전의 Xcode 개발 환경(Mac OS X 10.4~Mac OS X 10.6에서 실행)에서 Apple은 Intel과 PowerPC 아키텍처 모두를 대상으로 애플리케이션을 실행할 수 있는 유틸리티를 포함했습니다.유니버설 바이너리에는 최대 4가지 버전의 실행 가능 코드(32비트 PowerPC, 32비트 x86비트)가 포함될 수 있습니다.PowerPC 및 64비트 x86)를 지원합니다.단, 파워PC 지원은 Xcode 4.0에서 삭제되었기 때문에 Mac OS X 10.7 이상을 실행하는 개발자는 사용할 수 없습니다.

2020년, Apple은 인텔 x86 프로세서에서 Apple 실리콘(ARM64 아키텍처)으로의 전환을 발표했습니다.전환을 원활하게 하기 위해 애플은 Universal 2 바이너리 포맷에 대한 지원을 추가했습니다.Universal 2 바이너리 파일은 x86-64 및 ARM64 실행 코드를 모두 포함하는 멀티 아키텍처 바이너리 파일로, 64비트 Intel과 64비트 Apple 실리콘 모두에서 바이너리를 네이티브하게 실행할 수 있습니다.또한, 애플은 x86에서 Arm64 명령어 세트를 위한 Rosetta 2 동적 바이너리 변환을 도입하여 사용자가 범용 바이너리 베리에이션을 사용하지 않는 애플리케이션을 실행할 수 있도록 했습니다.

CP/M 및 DOS

CP/M-80 및 DOS용 COM 스타일의 바이너리 조합

인텔 8080 (및 Z80) 프로세서 패밀리용 CP/M-80, MP/M-80, Concurrent CP/M, CP/M Plus, Personal CP/M-80, SCP 및 MSX-DOS 실행 파일도 동일합니다.인텔 8086 [nb 1]바이너리용 DOS 호환 운영체제로서의 COM 파일 확장자.두 경우 모두 프로그램은 오프셋 +100h로 로드되고 파일의 [13][14]첫 번째 바이트로 점프하여 실행됩니다.2개의 프로세서 패밀리의 opcode는 호환성이 없기 때문에, 잘못된 operating system으로 프로그램을 기동하려고 하면, 부정하고 예측할 수 없는 동작이 발생합니다.

이를 피하기 위해 CP/[14]M-80과 DOS 프로그램을 모두 포함하는 fat 바이너리를 구축하기 위해 두 플랫폼에서 올바르게 해석되는 초기 코드가 선행됩니다.이 메서드는 각각 대응하는 환경에 대해 작성된2개의 완전 기능 프로그램을 조합하거나 잘못된 프로세서에서 기동했을 경우 프로그램을 정상적으로 종료하는 스터브를 추가합니다.이것을 동작시키려면 , 의 최초의 몇개의 순서(가젯[15] 헤더라고도 불립니다)를 참조해 주세요.COM 파일은 8086 및 8080 프로세서에 유효한 코드여야 합니다.이를 통해 프로세서가 코드 [15]내의 다른 위치에 분기할 수 있습니다.예를 들어 Simeon Cran의 에뮬레이터 MyZ80의 유틸리티는 opcode 시퀀스 EBh,[16][17] 52h, EBh로 시작합니다.8086은 이것을 점프로 간주하고 오프셋 +154h에서 다음 명령을 읽는 반면 8080 또는 호환되는 프로세서는 직진하여 +103h에서 다음 명령을 읽습니다.이 목적에 사용되는 유사한 시퀀스는 EBh, 03h, C3h.[18][19] John C이다.엘리엇의 FATBIN은[20][21][22] CP/M-80과 DOS를 조합하는 유틸리티입니다.COM 파일을 하나의 실행 [16][23]파일로 만듭니다.원본 PMSfx의 파생형은 Yoshiko Mino의 PMarc에 의해 작성된 아카이브를 CP/M-80과 DOS의 양쪽에서 자기해동할 수 있도록 수정하고,[24][16][23][17] EBh, 18h, 2Dh, 6Dh, 73h, 2Dh로 시작하여 PMA의 자기해동, PMS-도 포함한다.

DOS 호환 운영 체제가 잘못 실행되지 않도록 하는 또 다른 방법입니다.CP/M-80 및 MSX-DOS[14] 머신용 COM 프로그램은 8080 코드를 C3h, 03h, 01h로 시작하여 x86 프로세서에 의해 [nb 2]"RET" 명령으로 디코딩되고 8080 프로세서에 의해 "JP 103h" 명령으로 디코딩되어 다음 명령으로 넘어갑니다.마찬가지로 CP/M 어셈블러 Z80도ASM+ by SLR Systems는 [16]DOS에서 잘못 실행되면 오류 메시지를 표시합니다.

일부 CP/M-80 3.0COM 파일에는 GENCOM에 [25]의해1개 이상의 RSX 오버레이가 부가될 수 있습니다.이 경우 추가 256바이트 헤더(1페이지)로 시작합니다.이를 나타내기 위해 헤더 내의 첫 번째 바이트는 매직바이트 C9h로 설정되며, 매직바이트 C9h는 CP/M 3.0 실행 가능 로더에 대한 이러한 유형의 COM 파일을 식별하는 시그니처로서 기능할 뿐만 아니라 파일이 오래된 버전의 CP/[nb 2]M-80에서 실행될 경우 그레이스풀한 종료로 이어지는 8080 호환 프로세서의 "RET" 명령으로 기능한다.

C9h는 x86 프로세서에 대해 프로그램의 첫 번째 바이트로 적합하지 않습니다(세대에 따라 [nb 3]다른 의미를 가지지만 의미 있는 첫 번째 바이트가 아닙니다). DOS 일부 버전의 실행 가능한 로더는 C9h로 시작하는 COM 파일을 거부하여 잘못된 동작을 방지합니다.

조합된 Z80/[16]6502, 8086[16]/68000 또는 x86/MIPS/ARM [15]바이너리에 대해서도 유사한 중복 코드 시퀀스가 고안되었습니다.

CP/M-86 및 DOS용 바이너리 조합

CP/M-86과 DOS는 실행 [nb 1]파일의 공통 확장자를 공유하지 않습니다.따라서 일반적으로 실행 파일을 혼동할 수 없습니다.그러나 초기 버전의 DOS는 아키텍처 면에서 CP/M과 많은 공통점을 가지고 있어서 일부 초기 DOS 프로그램은 실행 가능한 코드를 포함하는 바이너리를 공유하도록 개발되었습니다.이를 위해 알려진 프로그램 중 하나는 WordStar 3.2x로, CP/M-86과 [26]MS-DOS용 포트에서 동일한 오버레이 파일을 사용하고 런타임에 [26]이러한 운영 체제의 서로 다른 호출 규칙에 적응하기 위해 동적으로 고정된 코드를 사용했습니다.

Digital Research의 GSX for CP/M-86 및 DOS도 동일한 이진 16비트 [27]드라이버를 공유합니다.

COM 파일과 SYS 파일의 조합

DOS 디바이스 드라이버(통상은 파일 확장자).SYS) 파일헤더부터 시작합니다.단, 파일헤더의 첫 번째 4바이트는 관례상 FFFFFH입니다.단,[28] 이것은 필수는 아닙니다.이것은 드라이버가 로드될 때 운영체제에 의해 동적으로 수정됩니다(일반적으로 CONFIG에서 DEVICE 문을 실행할 때 DOS BIOS에서).SYS). DOS는 파일을 거부하지 않기 때문입니다.COM 확장자는 디바이스별로 로드되며 FFFFFH를 테스트하지 않습니다.파일의 처음 4바이트 이내에서 임베디드 COM 프로그램의 엔트리 포인트에 점프 명령을 배치함으로써 COM 프로그램과 디바이스 드라이버를 같은 파일에[29][28] 조합할 수 있습니다(통상 3바이트로 [28]충분합니다).임베디드 프로그램 및 디바이스 드라이버 섹션이 코드 또는 데이터의 공통 부분을 공유하는 경우로서 오프셋 +0100h 로 로딩되는 것을 처리할 필요가 있습니다.디바이스 드라이버로서 +[29]0000h의 COM 스타일 프로그램.공유 코드를 위해" 잘못된"오프셋에 있지만 위치 독립이 되도록 설계된 것이 아닌 이것은 이 self-relocatin과 상황과 비슷하다 내부 주소 fix-up[29] 그렇지 않았다면 이미가 이전할 로더에 의해 행해질 것인가, 이러한 경우에 로드된 프로그램 자체에 의존할 수밖에 없을 제외하고 유사한 필요로 한다.gd그러나 운영 체제의 로더에 의해 대상 위치에 프로그램이 이미 로드된 상태여야 합니다.

크래시 보호 시스템 파일

DOS에서 일부 파일은 일반적으로 실제 파일 형식을 [nb 4]반영하지 않는 파일 확장자를 가집니다.예를 들어 COUNTRY 입니다.SYS는 DOS 디바이스 [nb 5]드라이버가 아니라 CONFIG에서 사용하는 바이너리 NLS 데이터베이스 파일입니다[30].SYS COUNTRY 디렉티브 및 NLSFUNC 드라이버.[30]PC DOS 및 DR-DOS 시스템 파일 IBMBIO.COM 및 IBMDOS.COM은 부트스트랩로더에 의해 로드되는 특수한 바이너리 이미지이며 COM 스타일의 [nb 5]프로그램이 아닙니다.COUNTRY를 로드하려고 합니다.DEVICE 스테이트먼트를 사용하거나 IBMB를 실행하는SYSIO.COM 또는 IBMDOS.명령 프롬프트에서 COM을 실행하면 예기치 않은 [nb 4][nb 6]결과가 발생합니다.

상기와 같은 기술을 사용하여 이를 회피할 수 있는 경우가 있습니다.예를 들어 DR-DOS 7.02 이상에는 Matthias R.[31]Paul이 개발한 안전 기능이 포함되어 있습니다.이 파일들이 부적절하게 호출되면 작은 내장 스텁은 일부 파일 버전 정보를 표시하고 정상적으로 [32][31][33][30]종료됩니다.또, 이 메시지는, 외부 NetWare & DR-DOS VERSION 파일 식별 [30][31][nb 7]유틸리티로 인식되는 「매직」패턴에 따르도록 특별히 작성되어 있습니다.

유사한 보호 기능은 Jay Sage와 Joe Wright의 Z-System 타입 3 및 타입 4의 첫 번째 8080 명령 C7h(RST 0)입니다.ENV" 프로그램[34][35] 및 "Z3TXT" 언어 오버레이 [36]파일을 사용하면 부적절하게 [34][35][36][nb 2]로드될 경우 CP/M-80에서 웜부트가 발생합니다.

매우 유사한 방식으로, 관례상 많은 (바이너리) 파일 형식에는 파일 시작 부분에 1Ah 바이트(ASCII ^Z)가 포함됩니다.이 제어 문자" 부드러운"파일 종료(EOF)표지 파일을 비-2진 모드에서, 따라서 많은 운영 체제(그 PDP-6 monitor[37]과 RT-11, VMS, TOPS-10,[38]CP[39][40]DOS,[41]과 Windows[42]포함)에 열리게 된다로 해석됩니다, 그것은 파일 우연히에 출력한다가 표시되지 않"쓰레기 2진"를 방지한다.콘솔.

리눅스

FatELF: Linux용 유니버설 바이너리

FatELF 로고

FatELF는[43] Linux 및 기타 Unix 계열 운영 체제용 팻 바이너리 구현이었습니다.엄밀히 말하면, FatELF 바이너리는 어떤 [44]아키텍처에서 어떤 바이너리를 사용할 것인지를 나타내는 메타 데이터와 ELF 바이너리를 결합한 것입니다.CPU 아키텍처 추상화(바이트 순서, 워드 크기, CPU 명령 세트 등) 외에도 여러 커널 ABI 및 버전을 지원하는 바이너리의 이점이 있습니다.

개발자에 [43]따르면 FatELF에는 다음과 같은 몇 가지 사용 사례가 있습니다.

  • 디스트리뷰션에서는 다양한 플랫폼에 대해 별도의 다운로드가 필요 없게 되었습니다.
  • OS 디렉토리 구조에서 /lib, /lib32 및 /lib64 트리는 더 이상 필요하지 않습니다.
  • 셸 스크립트 대신 올바른 바이너리와 라이브러리가 시스템에 의해 중앙에서 선택됩니다.
  • ELF ABI가 언젠가 변경되더라도 레거시 사용자는 계속 지원받을 수 있습니다.
  • 여러 플랫폼에서 즉시 사용할 수 있는 웹 브라우저 플러그인의 배포.
  • 플랫폼 호환성 계층 없이 Linux 및 BSD OS 버전 간에 작동하는 하나의 응용 프로그램 파일 배포.
  • 하나의 하드 드라이브 파티션은 개발 및 실험을 위해 CPU 아키텍처가 다른 다른 다른 기계에서 부팅할 수 있습니다.동일한 루트 파일 시스템, 다른 커널 및 CPU 아키텍처.
  • 네트워크 공유 또는 USB 스틱으로 제공되는 애플리케이션은 여러 시스템에서 작동합니다.이는 또한 휴대용 애플리케이션 및 [45]이종 시스템용 클라우드 컴퓨팅 이미지 작성에도 도움이 됩니다.

개념 실증 Ubuntu 9.04 이미지를 이용할 [46]수 있습니다.2021년 현재 FatELF는 메인라인 Linux [citation needed][47][48]커널에 통합되어 있지 않습니다.

창문들

팻팩

Windows에서 사용하는 Portable Executable 형식에서는 플랫폼에 코드를 할당할 수 없지만 아키텍처에 따라 디스패치하는 로더 프로그램을 만들 수 있습니다.이는 데스크톱 버전의 Windows on ARM이 32비트 x86 에뮬레이션을 지원하므로 유용한 "범용" 머신 코드 타깃이 되기 때문입니다.Fatpack은 개념을 보여주는 로더입니다. 32비트 x86 프로그램이 포함되어 리소스 섹션에 하나씩 [49]채워진 실행 파일을 실행하려고 합니다.

유사한 개념

다음 접근법은 동일한 용도의 여러 기계 코드 버전이 동일한 파일에 제공된다는 점에서 fat 바이너리와 유사합니다.

이종 컴퓨팅

2007년 이후 일부 이기종 플랫폼 전용 컴파일러는 여러 종류의 프로세서에서 병렬 실행하기 위한 코드 파일을 생성합니다.예를 들어 인텔 EXOCHI(Exokelton Sequencer) 개발 스위트의 CHI(C for Etheric Integration) 컴파일러는 OpenMP 플러그마 개념을 확장하여 다음을 포함하는 팻 바이너리를 생성합니다.런타임 로더가 이종 시스템 환경에서 [50][51]사용 가능한 여러 CPU 및 GPU 코어로 병렬 실행을 동적으로 시작할 수 있는 다양한 명령 집합 아키텍처(ISA)의 코드 섹션.

2007년 2월에 도입된 Nvidia의 병렬 컴퓨팅 플랫폼 CUDA(Compute Unified Device Architecture)는 GPU(General Purpose Compute Unified Device Architecture) 상에서 범용 컴퓨팅을 가능하게 하는 소프트웨어입니다.LLVM 기반의 컴파일러 NVCC는 이른바 PTX 가상 어셈블리(텍스트)를 포함한 ELF 기반의 팻 바이너리를 작성할 수 있습니다.이것을 CUDA 런타임 드라이버는 나중에 실제로 존재하는 타겟 GPU의 Just-in-Time Assembly(Streaming Assembler) 바이너리 실행 코드로 컴파일 할 수 있습니다.실행 파일에는 CUDA 바이너리(cuba 파일)도 포함할 수 있습니다.로드 [52][53][54][55][56][57]시 CUDA 런타임에서 선택할 수 있는1개 이상의 특정 GPU 아키텍처 전용 실행 가능 코드 섹션이 있습니다.또한 Fat 바이너리는 2007년에 도입된 GPU 시뮬레이터인 GPGPU-Sim [de]에서도 지원됩니다.[58][59]

OpenCL의 이기종 시스템 시뮬레이터 프레임워크인 M2S(M2S)는 (원래는 MIPS 또는 x86 CPU에서만 사용 가능하지만 나중에 AMD/ATI Evergreen 및 Southern Islands 및 Nvidia Fermi 및 Kepler [60]패밀리 등 ARM CPU 및 GPU를 지원하도록 확장되었습니다) ELF 기반의 패밀리를 지원합니다.[61][60]

뚱뚱한 물체

GNU 컴파일러 컬렉션(GCC) 및 LLVM에는 팻 바이너리 형식이 없지만 링크 타임 최적화(LTO)용 팻 오브젝트 파일은 있습니다.LTO는 컴파일을 링크 타임으로 지연시키는 것을 수반하기 때문에 오브젝트 파일에는 Intermediate Representation(IR; 중간 표현)을 저장해야 하지만 다른 한편으로 (속도 또는 호환성을 위해) 머신 코드도 저장해야 할 수 있습니다.IR과 기계 코드를 모두 포함하는 LTO 개체를 Fat [62]개체라고 합니다.

함수 다중 버전

같은 명령어 집합 아키텍처를 의도한 프로그램이나 라이브러리에서도 프로그래머는 오래된 CPU와의 호환성을 유지하면서 새로운 명령어 집합 확장을 사용할 수 있습니다.이는 Function Multi-Versioning(FMV; 함수 다중 버전)을 통해 달성할 수 있습니다.동일한 기능의 버전이 프로그램에 기록되고 코드 조각이 CPU의 기능을 감지하여 사용할 기능을 결정합니다(CPUID를 통해 등).인텔 C++ 컴파일러, GCC 및 LLVM은 모두 멀티버전 [63]함수를 자동으로 생성할 수 있습니다.이것은 의미적 효과가 없는 동적 디스패치의 한 형태입니다.

많은 수학 라이브러리는 CPU 기능에 따라 자동으로 선택되는 손으로 쓴 어셈블리 루틴을 특징으로 합니다.예를 들어 glibc, 인텔 MKL, OpenBLAS 등이 있습니다.또한 glibc의 라이브러리 로더는 특정 CPU [64]기능에 대해 대체 경로로부터의 로드를 지원합니다.

Matthias R. Paul과 Axel C가 원래 고안한 유사한 바이트 수준의 세분화된 접근법입니다.Frinke는 임의의 수의 대체 바이너리 코드 스니펫과 함께 실행 파일에 내장된 작은 자기 폐기, 릴렉스 및 재배치 로더를 통해 특정 타깃 환경에서 특정 기능을 실행(또는 실행하지 않음)하기 위해 필요한 프로그램 또는 드라이버의 크기 또는 속도에 최적화된 런타임 이미지를 조건부로 구축할 수 있도록 합니다.Dynamic Dead Code Elimation(DDCE;[65][66][67][68] 동적 데드코드 제거) 형식을 통한 d-time.

「 」를 참조해 주세요.

메모들

  1. ^ a b 이는 CP/M-86, CP/M-86 Plus, Personal CP/M-86, S5-DOS, Concurrent CP/M-86, Concurrent DOS 286, FlexOS, Concurrent DOS 386, Concurrent DOS 386 Plus의 CP/M-86 스타일의 실행 파일에는 문제가 없습니다.가 아닌 CMD.이 파일들의 COM.(단, .CMD 확장자는 명령줄 프로세서 CMD용으로 작성된 배치 작업의 파일 확장자와 경합합니다.OS/2 및 Windows NT 운영체제 패밀리에서 EXE를 실행합니다.)
  2. ^ a b c 이는 (적절한) 반환 명령을 사용하여 CP/M-80, CP/M-86 및 DOS에서 프로그램을 종료할 수 있기 때문입니다.단, opcode, 정확한 조건 및 기본 메커니즘은 다릅니다.CP/M-80에서는 프로그램이 0페이지로 점프하여 종료(즉, 0/80에서 직접 BIOS로 웜부트)할 수 있습니다.CALL 5 인터페이스를 통해 BDOS 함수 0을 호출합니다.또는 스택은 로드된 프로그램에 제어를 넘기기 전에 0 리턴 주소를 유지할 준비가 되어 있기 때문에 스택이 정렬되어 있는 한 RET 명령어를 발행하여 종료할 수도 있으며, 이로 인해 제로 페이지의 오프셋 0에서 종료 코드에 빠진다.DOS에는 프로그램을 종료하기 위한 전용 INT 20h 인터럽트 및 INT 21h API 하위 함수가 있지만(더 복잡한 프로그램에는 선호됨), 기계 번역된 프로그램의 경우 DOS는 CP/M의 동작을 어느 정도 에뮬레이트합니다.프로그램은 시스템이 이전에 INT 20h 명령을 심었던 PSP(CP/M의 제로 페이지와 동일)에서 오프셋 0으로 점프함으로써 자신을 종료할 수 있다.또, 로드된 프로그램의 초기 스택은, 0의 워드를 보관 유지하도록 준비되기 때문에, 근복귀 RETN(8088/8086 opcode C3h)을 발행하는 프로그램도 그 코드 세그먼트의 선두까지 암묵적으로 점프해, 최종적으로 INT20h에도 도달한다.[a]CP/M-86에서는 제로 페이지는 다른 구조로 CALL 5 인터페이스는 없지만 스택 반환 방식과 BDOS 함수 0(현재는 INT E0h를 통해)도 모두 작동합니다.
  3. ^ 8088/8086 프로세서에서 opcode C9h는 CBh('RETF')의 문서화되어 있지 않은 에일리어스로 CS:스택으로부터의 IP). 단, 80188/80186 이후의 프로세서에서는 「LEave」(SP를 BP 및 팝 BP로 설정)로 디코딩 됩니다.
  4. ^ a b 이 문제는 경합하지 않는 파일 확장자를 선택함으로써 회피할 수 있었습니다만, 도입 후에는, 이러한 특정의 파일명은, 이러한 특정의 파일명을 상정하도록 유선 접속되어 있는 (서드 파티제의) 툴과의 호환성을 위해서, MS-DOS/PC DOS 의 초기 버전으로부터 유지되고 있었습니다.
  5. ^ a b 이 유형의 다른 DOS 파일은 키보드입니다.SYS는 MS-DOS 및 PC DOS의 키보드 드라이버 KEYB용 바이너리 키보드 레이아웃 데이터베이스 파일입니다.MS-DOS 및 MSDOS의 DOS BIOS를 포함한 SYS.SYS: Windows 95/MS-DOS 7.0 이후의 텍스트 구성 파일입니다만, 원래는 MS-DOS 커널을 포함한 바이너리 시스템 파일입니다.단, MS-DOS 및 PC DOS는 크래시 방지 시스템파일을 전혀 제공하지 않습니다.이 파일명은 DR-DOS 7.02 이후에서는 사용되지 않습니다.이 파일명은 크래시 방지 시스템파일을 제공하지 않습니다.
  6. ^ 이 때문에, 이러한 파일에는 숨김 어트리뷰트가 설정되어 있기 때문에, 디폴트로 리스트 되어 있지 않기 때문에, 잘못해 기동하는 리스크를 줄일 수 있습니다.
  7. ^ 그COUNTRY.SYSMS-DOS/PC DOS 및 DR-DOS 패밀리의 운영 체제에서 지원되는 파일 형식은 유사한 데이터를 포함하지만 구성이 다르거나 호환되지 않습니다.데이터 구조의 진입점은 파일에서 서로 다른 오프셋에 있으므로 "지방"을 생성할 수 있습니다.COUNTRY.SYS양쪽 DOS [b]패밀리에서 사용할 수 있는 데이터베이스입니다.다만, DR-DOS 7.02 와 그 NLSFUNC 4.00 이상에는, 양쪽 모두의 형식(및 바리안트)을 동시에 읽어낼 수 있는 개량된 파서가 포함되어 있기 때문에,[c][d] Janus 헤드의 파일은 불필요합니다.그러나 출하된 파일은 부적절하게 [d][b]호출되었을 때 삽입된 메시지를 표시하는 작은 실행 파일 스텁이 포함되어 있기 때문에 "뚱뚱한" 파일입니다.

레퍼런스

  1. ^ Devanbu, Premkumar T.;Fong에, 필립 W.L.;Stubblebine, 스튜어트 G.(19–25 1998년 4월)."3.3Java그리고 TH"(PDF).신뢰할 수 있는 소프트웨어 공학 기술.20국제 회의 소프트웨어 기술에 관한 회보다.논문집-국제 회의 소프트웨어 기술에 관한.일본 교토. 우편 131.doi:10.1109/ICSE.1998.671109.아이 에스비엔 0-8186-8368-6.ISSN 0270-5257.2014-01-16에 있는 원본(PDF)에서 Archived..(10페이지)2021-09-29 Retrieved
  2. ^ Pero, Nicola (2008-12-18). "gnustep/tools-make: README.Packaging". GitHub. Archived from the original on 2022-05-25. Retrieved 2022-05-26.
  3. ^ "PackagingDrafts/GNUstep". Fedora Project Wiki. 2009-02-25. Archived from the original on 2022-05-25. Retrieved 2022-05-26.
  4. ^ "Domain System Software Release Notes, Software Release 10.1" (PDF) (first printing ed.). Chelmsford, Massachusetts, USA: Apollo Computer Inc. December 1988. p. 2-16. Order No. 005809-A03. Retrieved 2022-07-24. (256페이지)
  5. ^ a b Engst, Adam C. (1994-08-22). "Should Fat Binaries Diet?". TidBITS. No. 240. TidBITS Publishing Inc. ISSN 1090-7017. Archived from the original on 2021-09-29. Retrieved 2021-09-29. [1]
  6. ^ a b Engst, Adam C. (1994-08-29). "Fat Binary Comments". TidBITS. No. 241. TidBITS Publishing Inc. ISSN 1090-7017. Archived from the original on 2021-09-29. Retrieved 2021-09-29. [2]
  7. ^ "Chapter 1 - Resource Manager / Resource Manager Reference - Resource File Format". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer, Inc. 1996-07-06. Archived from the original on 2021-09-29. Retrieved 2021-09-29.
  8. ^ "Chapter 7 - Fat Binary Programs - Creating Fat Binary Programs". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer, Inc. 1997-03-11. Archived from the original on 2021-09-29. Retrieved 2011-06-20. [3]
  9. ^ "Chapter 8 - PEF Structure". Inside Macintosh: Mac OS Runtime Architectures. Apple Computer, Inc. 1997-03-11. Archived from the original on 2021-09-29. Retrieved 2021-09-29.
  10. ^ Tevanian, Avadis, DeMoney, 마이클 엔더비, 케빈;Wiebe, 더글러스, 스나이더 Garth[1993-08-20](1995-07-11)."방법 및 장치 아키텍처 독립적으로 실행 파일"(PDF).캘리포니아 주 레드 우드시, USA:NeXTComputer, Inc.미국 특허 5432937A.그 2020-12-14에 원래에서Archived(PDF).2022-05-26 Retrieved.[4](9페이지);Tevanian, Avadis, DeMoney, 마이클 엔더비, 케빈;Wiebe, 더글러스, 스나이더 Garth[1995-02-28](1997-02-18)."방법 및 장치 아키텍처 독립적으로 실행 파일"(PDF).캘리포니아 주 레드 우드시, USA:NeXTComputer, Inc.미국 특허 5604905A.그 2022-05-26에 원래에서Archived(PDF)..(9페이지)2022-05-26 Retrieved
  11. ^ "Mac OS X ABI Mach-O File Format Reference". Apple Inc. 2009-02-04 [2003]. Universal Binaries and 32-bit/64-bit PowerPC Binaries. Archived from the original on 2012-04-27. [5]
  12. ^ Singh, Amit (2006-06-19). "2.6.2 Fat Binaries". Mac OS X Internals - A Systems Approach. Pearson Education. p. 66. ISBN 978-0-13270226-3. Retrieved 2021-09-28.
  13. ^ Paul, Matthias R. (2002-10-07) [2000]. "Re: Run a COM file". Newsgroup: alt.msdos.programmer. Archived from the original on 2017-09-03. Retrieved 2017-09-03. [6] (NB)DOS COM 프로그램의 호출 규칙에 대한 자세한 내용을 기재하고 있습니다.)
  14. ^ a b c Wilkinson, William "Bill" Albert (2005-04-02) [2003, 1999-02-16, February 1987, 1986-11-15, 1986-11-10]. Written at Heath Company, USA. "Something COMmon About MS-DOS and CP/M". REMark. Vol. 8, no. 2. St. Joseph, Michigan, USA: Heath/Zenith Users' Group (HUG). pp. 55–57. #85. P/N 885-2085. Archived from the original on 2021-12-13. [7]
  15. ^ a b c 차인표는 상 길;박세리, 브라이언, Brumley, David;립턴, 리차드 제이(2010-10-08)[2010-10-04].플랫폼 독립 프로그램(PDF).컴퓨터 통신 보안(CCS'10)에 17ACM컨퍼런스 논문집.일리노이 주, 시카고 미국:카네기 Mellon대학교, 펜실베니아 주 피츠버그, 미국/조지아 공과 대학, 조지아, 아틀란타, 미국.를 대신하여 서명함. 547–558. doi:10.1145/1866307.1866369.아이 에스비엔 978-1-4503-0244-9.그 2022-05-26에 원래에서Archived(PDF).2022-05-26 Retrieved.(12페이지)(참고 항목:[9])(NB다. 구체적으로 8080과 86명령어 집합 아키텍처들(CP/M과 도스 기구로 시나리오를 언급하지 않나),지만platform-independent 프로그램의 일반적인"self-identifying 프로그램"개념에 대해 설명합니다[8]은 저자들 가젯을 헤더(즉, 프로그램 논리의 혼동하지 마시라고 부르는 것을 통해(PIPs).ROP 가젯 포함) x86, MIPS 및 ARM의 경우: 0Eh, B2h, 02h, A9h, 0Eh, B2h, 02h, 02h, 3Ah, 24h, 77h, 01h, 04h, 90h, EBh, 20h, 77H, 3H, 3H
  16. ^ a b c d e f 윌킨슨, 윌리엄"빌"알버트;셀리그먼, 코리, Drushel, 리차드 F.;Harston, 조나단 그레이엄, 엘리엇, 존 C.(1999-02-17)."MS-DOS&, CP/M-Compatible Binaries".뉴스:comp.os.cpm.그 2021-12-13에 원래에서 Archived..(NB다. 몇몇 엘리엇의 코드 예제에서는을 opcode(EBh, 44h, EBh과 EBh, 04h,...)뒤죽박죽이 될 수 있다.)2021-12-13 Retrieved.
  17. ^ a b Elliott, John C. (2009-10-27). "CP/M info program". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] DOS protection feature […] The idea is based on the utilities in Simeon Cran's MYZ80 emulator; the DOS-protection header in those goes one better by not changing any Z80 registers. The magic sequence is EB 52 EB: […] XCHG […] MOV D,D […] XCHG […] but that means the DOS code ends up quite a way away from the start of the program. […] More fun can be had with self-extract PMArc archives. Start one with […] defb 0EBh, 018h, '-pms-' […] and it's treated as a valid archive by the PMA utilities, sends 8086 processors to 011Ah, and Z80 processors to 0130h. […]
  18. ^ ChristW(2012-11-14)[2012-11-13].Chen, 레이먼드(교육.)."계정 거래의 수입 중 마이크로 소프트 돈이 충돌이날 때 다운로드한 거래의 지불 받는 사람 변화".뉴 올드 짓이다.그 2018-07-05에 원래에서 Archived.2018-05-19 Retrieved.[…]바이트 시퀀스[…]EB03C3yy xx[…]만약 너를 만든.그 5바이트로 첫번째[…] 있는 COM파일 보자 'JMP하도록 구속당하 3'에 따른 3바이트입니다.만약 당신이 Z80 분해는 'EX DE,HL, INC기원전으로 번역되다;[…]은 3바이트''JUMP은 16비트 주소yy xx[…]로 지정된 뒤에[…]을 보면[…]당신은 하겠습니다.는 MS-DOS및[…]CP/M[…](NB에 달린 COM파일입니다.반면 작가는 Z80에 대해 말하겠습니다, 이 반복이 또한 그 8080과 호환되는 프로세서.) 일한다.
  19. ^ Brehm, Andrew J. (2016). "CP/M and MS-DOS Fat Binary". DesertPenguin.org. Archived from the original on 2018-05-19. Retrieved 2018-05-19. (NB. 기사에서는 Z80에 대해 설명하지만 코드 시퀀스는 8080 및 호환 프로세서에서도 작동합니다.)
  20. ^ Elliott, John C. (1996-06-13). "Upload to micros.hensa.ac.uk". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] FATBIN 1.00 - combine a CP/M .COM file and a DOS .COM file to create one which runs on both platforms. […] It was used to create: […] MSODBALL 2.05 - convert floppy discs between Amstrad 706k format and a DOS 706k format. […] Both the programs run under CP/M-80 and DOS. […] {{cite newsgroup}}:외부 링크 quote=(도움말)
  21. ^ Elliott, John C. (1998-06-28) [1997-04-01]. "FATBIN v1.01". Archived from the original on 1998-06-28. (NB.FATBN101).COM 22k 1997-04-01 FATBin v1.01.CP/M과 DOS 모두에서 실행되는 팻 바이너리 파일을 만듭니다.CP/M-80 및 DOS용 자기 압축 해제 아카이브에 배포됩니다.)
  22. ^ Elliott, John C. (2002-03-11). "DSKWRITE v1.00". Fossies - the Fresh Open Source Software Archive. Archived from the original on 2021-12-12. Retrieved 2021-12-12. […] DSKWRITE.Z80 contains source for the CP/M version. […] DSKWRITE.ASM contains source for the DOS version. […] To get the single .COM file, you need to use FBMAKE: […] [10] (NB).FATBNSEA의 FBMAKE에 대해 설명합니다.COM 패키지).
  23. ^ a b Elliott, John C. (2012-06-20) [2005-01-05]. "Generic CP/M". Seasip.info. Archived from the original on 2021-11-17. Retrieved 2021-12-12. […] Self-extracting archives are .COM files containing a number of smaller files. When you run one, it will create its smaller files […] The self-extract archive programs will run under DOS (2 or later) or CP/M, with identical effects. To extract them under Unix, you can use ZXCC […] FATBNSEA.COM […] FATBIN combines a CP/M-80 .COM file and a DOS .COM file to produce one that will work on both systems. […] M3C4SEA.COM […] M3CONV version 4 - converts Spectrum snapshots in the .Z80 or .SNA format to or from Multiface 3 format (Multiface 3 -> Z80 only on a PC). […] PMSFX21X.COM […] PMSFX is the program that was used to generate these self-unpacking archives. This version (2.11) can generate archives which unpack themselves under CP/M or DOS. You will need PMARC to use PMSFX. New: Under DOS, it supports exact file sizes. […] SP2BMSEA.COM […] Converts a Stop Press Canvas file to a Windows .BMP […] {{cite web}}:외부 링크 quote=(도움말) [11]
  24. ^ Elliott, John C. (1997-01-18) [1997-01-11]. "PMSFX 2". Newsgroup: comp.os.cpm. Archived from the original on 2021-12-13. Retrieved 2021-12-13. […] I've written a version of PMSFX that produces .COM files unpackable under DOS and CP/M (the first three bytes are both legal Z80 code, legal 8086 code and legal PMA header) […] as a self-extracting archive. […]
  25. ^ Elliott, John C.; Lopushinsky, Jim (2002) [1998-04-11]. "CP/M 3 COM file header". Seasip.info. Archived from the original on 2016-08-30. Retrieved 2016-08-29.
  26. ^ a b Necasek, Michal (2018-01-30) [2018-01-28, 2018-01-26]. "WordStar Again". OS/2 Museum. Archived from the original on 2019-07-28. Retrieved 2019-07-28. […] The reason to suspect such difference is that version 3.2x also supported CP/M-86 (the overlays are identical between DOS and CP/M-86, only the main executable is different) […] the .OVR files are 100% identical between DOS and CP/M-86, with a flag (clearly shown in the WordStar 3.20 manual) switching between them at runtime […] the OS interface in WordStar is quite narrow and well abstracted […] the WordStar 3.2x overlays are 100% identical between the DOS and CP/M-86 versions. There is a runtime switch which chooses between calling INT 21h (DOS) and INT E0h (CP/M-86). WS.COM is not the same between DOS and CP/M-86, although it's probably not very different either. […]
  27. ^ Lineback, Nathan. "GSX Screen Shots". Toastytech.com. Archived from the original on 2020-01-15. Retrieved 2020-01-15.
  28. ^ a b c Paul, Matthias R. (2002-04-11). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev. Archived from the original on 2020-02-21. Retrieved 2020-02-21. […] FreeKEYB is […] a true .COM and .SYS driver (tiny model) in one. You can safely overwrite the first JMP, that's part of what I meant by "tricky header". […] you can replace the FFFFh:FFFFh by a 3-byte jump and a pending DB FFh. It works with MS-DOS, PC DOS, DR-DOS, and most probably any other DOS issue as well. […]
  29. ^ a b c Paul, Matthias R. (2002-04-06). "Re: [fd-dev] ANNOUNCE: CuteMouse 2.0 alpha 1". freedos-dev. Archived from the original on 2020-02-07. Retrieved 2020-02-07. […] Add a SYS device driver header to the driver, so that CTMOUSE could be both in one, a normal TSR and a device driver - similar to our FreeKEYB advanced keyboard driver. […] This is not really needed under DR DOS because INSTALL= is supported since DR DOS 3.41+ and DR DOS preserves the order of [D]CONFIG.SYS directives […] but it would […] improve the […] flexibility on MS-DOS/PC DOS systems, which […] always execute DEVICE= directives prior to any INSTALL= statements, regardless of their order in the file. […] software may require the mouse driver to be present as a device driver, as mouse drivers have always been device drivers back in the old times. These mouse drivers have had specific device driver names depending on which protocol they used ("PC$MOUSE" for Mouse Systems Mode for example), and some software may search for these drivers in order to find out the correct type of mouse to be used. […] Another advantage would be that device drivers usually consume less memory (no environment, no PSP) […] It's basically a tricky file header, a different code to parse the command line, a different entry point and exit line, and some segment magics to overcome the ORG 0 / ORG 100h difference. Self-loadhighing a device driver is a bit more tricky as you have to leave the driver header where it is and only relocate the remainder of the driver […]
  30. ^ a b c d Paul, Matthias R. (2001-06-10) [1995]. "DOS COUNTRY.SYS file format" (COUNTRY.LST file) (1.44 ed.). Archived from the original on 2016-04-20. Retrieved 2016-08-20.
  31. ^ a b c 폴, 마티아스 R.[1994-05-01](1997-07-30).장 II.4.Undokumentierte Eigenschaften externer Kommandos-곧 또 보자.COM". NWDOS-TIPs — 팁을 &, Tricks rund)노벨 도스 7, mit Blick aufundokumentierte 자세한 내용은 벅스 und Workarounds.MPDOSTIP.157(독일어로)(3판)를 해제한다.그 2017-09-10에 원래에서 Archived.2014-08-06 Retrieved.자유시의 국가 ein Calderas OpenDOS 7.01habe 지느러미·굴 Startcode 폰 IBMB für Updatezukünftiges.IO.COM 그렇게modifiziert,daß 어-fälschlicherweise Programm gestartet-ohne Absturz zur Kommandozeile zurückkehrt으로서의 normales 떨어진다.die offizielle 버전 Einzughalten wird에 완diese Sicherheitsfunktion,ist jedoch nochnicht abzusehen.(NB다. NWDOSTIP.TXT는 Novell DOS 7 및 OpenDOS 7.01에 관한 포괄적인 작업이며, 문서화되어 있지 않은 많은 기능 및 내부 기능에 대한 설명을 포함합니다.그것은 저자의 한층 더 큰 작품의 일부이다.MPDOSTIP.ZIP컬렉션은 2001년까지 유지되어 당시 많은 사이트에 배포되었습니다.제공된 링크는 HTML 변환된 이전 버전의NWDOSTIP.TXT파일). [12]
  32. ^ Paul, Matthias R. (1997-10-02). "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM README.TXT". Archived from the original on 2003-10-04. Retrieved 2009-03-29. [13]
  33. ^ DR-DOS 7.03 WHATSNEW.TXT - Changes from DR-DOS 7.02 to DR-DOS 7.03. Caldera, Inc. 1998-12-24. Archived from the original on 2019-04-08. Retrieved 2019-04-08.
  34. ^ a b Sage, Jay (May–June 1988). Carlson, Art (ed.). "ZCPR 3.4 - Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. ZCPR3 Corner. Columbia Falls, Montana, USA (32): 10–17 [16]. ISSN 0748-9331. ark:/13960/t1wd4v943. Retrieved 2021-11-29. [14][15]
  35. ^ a b Sage, Jay (May–June 1992) [March–June 1992]. Carlson, Art; McEwen, Chris (eds.). "Type-3 and Type-4 Programs". The Computer Journal (TCJ) - Programming, User Support, Applications. Z-System Corner - Some New Applications of Type-4 Programs. S. Plainfield, New Jersey, USA: Socrates Press (55): 13–19 [14, 16]. ISSN 0748-9331. ark:/13960/t4dn54d22. Retrieved 2021-11-29. [16][17]
  36. ^ a b Sage, Jay (November–December 1992). Carlson, Art; Kibler, Bill D. (eds.). "Regular Feature, ZCPR Support, Language Independence, part 2". The Computer Journal (TCJ) - Programming, User Support, Applications. The Z-System Corner. Lincoln, CA, USA (58): 7–10. ISSN 0748-9331. ark:/13960/t70v9g87h. Retrieved 2020-02-09. […] there was an opcode of "RST 0", which, if executed, would result in a warm boot. A file containing a Z3TXT module should never be executed, but at a cost of one byte we could protect ourself against that outside chance. The header also contained the string of characters "Z3TXT" followed by a null (0) byte. Many Z-System modules include such identifiers. In this category are resident command packages (RCPs), flow command packages (FCPs), and environment descriptor modules (Z3ENVs). Programs, such as Bridger Mitchell's […] JETLDR.COM, that load these modules from files into memory can use the ID string to validate the file, that is, to make sure that it is the kind of module that the user has stated it to be. User mistakes and damaged files can thus be detected. […] The header, thus, now stands as follows: […] rst […] db 'Z3TXT',0 ; null-terminated ID […] ; 12345678 ; must be 8 characters, […] db 'PROGNAME' ; pad with spaces […] ; 123 ; must be 3 characters […] db 'ENG' ; name of language […] dw LENGTH ; length of module […] [18][19]
  37. ^ "Table of IO Device Characteristics - Console or Teletypewriters". PDP-6 Multiprogramming System Manual (PDF). Maynard, Massachusetts, USA: Digital Equipment Corporation (DEC). 1965. p. 43. DEC-6-0-EX-SYS-UM-IP-PRE00. Archived (PDF) from the original on 2014-07-14. Retrieved 2014-07-10. (1+84+10페이지)
  38. ^ "5.1.1.1. Device Dependent Functions - Data Modes - Full-Duplex Software A(ASCII) and AL(ASCII Line)". PDP-10 Reference Handbook: Communicating with the Monitor - Time-Sharing Monitors (PDF). Vol. 3. Digital Equipment Corporation (DEC). 1969. pp. 5-3–5-6 [5-5 (431)]. Archived (PDF) from the original on 2011-11-15. Retrieved 2014-07-10. (207페이지)
  39. ^ "2. 운영 시스템 콜 협약".CP/M 2.0인터페이스 가이드(1판)(PDF).캘리포니아 PacificGrove에 사는, USA:디지털 리서치. 1979년의 5페이지.그 2020-02-28에 원래에서Archived(PDF).2020-02-28 Retrieved.는 아스키 파일의 끝[…]control-Z 캐릭터(1AH)또는 파일의 진정한 끝에...그 CP/M 읽어 준 연산에서 반환되여 설명이다.Control-Z 문자(예:COM파일)무시되고 기계 코드 파일 내에 있다고 하고 파일 조건의 끝 CP/M에서 반환 작전을 읽고 해지하는 데 사용되는 넘었다.[…](56쪽)
  40. ^ Hogan, Thom (1982). "3. CP/M Transient Commands". Osborne CP/M User Guide - For All CP/M Users (2 ed.). Berkeley, California, USA: A. Osborne/McGraw-Hill. p. 74. ISBN 0-931988-82-9. Retrieved 2020-02-28. […] CP/M marks the end of an ASCII file by placing a CONTROL-z character in the file after the last data character. If the file contains an exact multiple of 128 characters, in which case adding the CONTROL-Z would waste 127 characters, CP/M does not do so. Use of the CONTROL-Z character as the end-of-file marker is possible because CONTROL-z is seldom used as data in ASCII files. In a non-ASCII file, however, CONTROL-Z is just as likely to occur as any other character. Therefore, it cannot be used as the end-of-file marker. CP/M uses a different method to mark the end of a non-ASCII file. CP/M assumes it has reached the end of the file when it has read the last record (basic unit of disk space) allocated to the file. The disk directory entry for each file contains a list of the disk records allocated to that file. This method relies on the size of the file, rather than its content, to locate the end of the file. […] [20][21]
  41. ^ BC_Programmer (2010-01-31) [2010-01-30]. "Re: Copy command which merges several files tags the word SUB at the end". Computer Hope Forum. Archived from the original on 2020-02-26. Retrieved 2020-02-26.
  42. ^ "What are the differences between Linux and Windows .txt files (Unicode encoding)". Superuser. 2011-08-03 [2011-06-08]. Archived from the original on 2020-02-26. Retrieved 2020-02-26.
  43. ^ a b Gordon, Ryan C. (October 2009). "FatELF: Universal Binaries for Linux". icculus.org. Archived from the original on 2020-08-27. Retrieved 2010-07-13.
  44. ^ Gordon, Ryan C. (November 2009). "FatELF specification, version 1". icculus.org. Archived from the original on 2020-08-27. Retrieved 2010-07-25.
  45. ^ Windisch, Eric (2009-11-03). "Subject: Newsgroups: gmane.linux.kernel, Re: FatELF patches..." gmane.org. Archived from the original on 2016-11-15. Retrieved 2010-07-08.
  46. ^ Gordon, Ryan C. (2009). "FatELF: Universal Binaries for Linux. - The proof-of-concept virtual machine download page". icculus.org. Archived from the original on 2022-05-21. Retrieved 2022-05-26. (NB. Fat Binary를 지원하는 Ubuntu 9.04의 VM 이미지).
  47. ^ Holwerda, Thom (2009-11-05). "Ryan Gordon Halts FatELF Project". Linux. osnews.com. Archived from the original on 2022-05-26. Retrieved 2010-07-05.
  48. ^ Brockmeier, Joe "Zonker" (2010-06-23). "SELF: Anatomy of an (alleged) failure". LWN.net. Linux Weekly News. Archived from the original on 2022-05-26. Retrieved 2011-02-06.
  49. ^ Mulder, Sijmen J. (2021-03-06) [2018-04-25]. "sjmulder/fatpack - Build multi-architecture 'fat' binaries for Windows". GitHub. Archived from the original on 2022-05-26. Retrieved 2022-05-26.
  50. ^ Wang, Perry H.; Collins, Jamison D.; Chinya, Gautham N.; Jiang, Hong; Tian, Xinmin; Girkar, Milind; Yang, Nick Y.; Lueh, Guei-Yuan; Wang, Hong (June 2007). "EXOCHI: architecture and programming environment for a heterogeneous multi-core multithreaded system". ACM SIGPLAN Notices. 42 (6): 156–166. doi:10.1145/1273442.1250753. (11페이지)
  51. ^ 왕, 페리 H., 콜린스, 제미슨 D;Chinya, Gautham N, 홍, 티엔주, 신민, Girkar, Milind, 피어스, 리사;Lueh, Guei-Yuan, Yakoushkin, 세르게이, 왕 홍(2007-08-22)."바로 연결 외골격"(PDF).인텔 기술 저널.인텔. 11:Tera-scale 컴퓨팅(3):185–196. doi:10.1535/itj.1103.ISSN 1535-864X.그 2022-05-26에 원래에서Archived(PDF)..(121+vii+90+1 페이지의)2022-05-26 Retrieved.
  52. ^ "cudaFatFormat.h / ptxomp.c". 1.13. Nvidia Corporation. 2004-11-15. Archived from the original on 2022-05-26. Retrieved 2022-05-26.
  53. ^ Harris, Mark J. (2014-05-08) [2013-06-05]. "Technical Walkthrough: CUDA Pro Tip: Understand Fat Binaries and JIT Caching". Nvidia Developer. Nvidia. Archived from the original on 2022-03-23. Retrieved 2022-05-26.
  54. ^ "CUDA Binary Utilities" (PDF) (Application Note). 6.0. Nvidia. February 2014. DA-06762-001_v6.0. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25.
  55. ^ "fatbinary - help". helpmanual.io. 8.0. 2016. Archived from the original on 2022-05-25. Retrieved 2022-05-25.
  56. ^ "CUDA Compiler Driver NVCC - Reference Guide" (PDF). 11.7. Nvidia. May 2022. TRM-06721-001_v11.7. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25.
  57. ^ Braun, Lorenz; Fröning, Holger (2019-11-18). CUDA Flux: A Lightweight Instruction Profiler for CUDA Applications (PDF). IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems (PMBS). Denver, Colorado, USA: IEEE. doi:10.1109/PMBS49563.2019.00014. ISBN 978-1-7281-5977-5. Archived (PDF) from the original on 2022-03-21. Retrieved 2022-05-26.
  58. ^ Fung, Wilson W. L.; Sham, Ivan; Yuan, George; Aamodt, Tor M. (2007). "Dynamic Warp Formation and Scheduling for Efficient GPU Control Flow" (PDF). Vancouver, British Columbia, Canada. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. (12페이지)
  59. ^ Bakhoda, Ali; Yuan, George L.; Fung, Wilson W. L.; Wong, Henry; Aamodt, Tor M. (2009-04-28) [2009-04-26]. Analyzing CUDA Workloads Using a Detailed GPU Simulator (PDF). Proceedings of the IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS). Boston, Massachusetts, USA. pp. 163–174. doi:10.1109/ISPASS.2009.4919648. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-06. [22]
  60. ^ a b "13.4 The AMD Compiler Wrapper: Fat binaries". The Multi2Sim Simulation Framework - A CPU-GPU Model for Heterogeneous Computing (PDF). multi2sim.org. v4.2. 2013. pp. 173–176 [176]. Archived (PDF) from the original on 2022-05-25. Retrieved 2022-05-25. (210페이지 중 4페이지)
  61. ^ Ubal, 라파엘, 장혁, Byunghyun;미스트리 군 Perhaad, Schaa, 다나, Kaeli, 데이비드 R.[2012-09-19](2012-09-23)."Multi2Sim:시뮬레이션 FrameworkCPU-GPU 센터"(PDF). 21일 국제 회의 병렬 건축에 컴필레이션 기법(PACT).미니애 폴리스, 미네소타, USA:IEEE.아이 에스비엔 978-1-4503-1182-3.그 2022-05-25에 원래에서Archived(PDF)..(10페이지)2022-05-25 Retrieved
  62. ^ "LTO Overview (GNU Compiler Collection (GCC) Internals)". gcc.gnu.org. Archived from the original on 2021-09-12. Retrieved 2021-09-12.
  63. ^ Wennborg, Hans (2018). "Attributes in Clang". Clang 7 documentation. Archived from the original on 2022-04-07. Retrieved 2022-05-26.
  64. ^ Bahena, Victor Rodriguez (2018-04-03). "Transparent use of library packages optimized for Intel architecture". Power and Performance. Clear Linux Project. Intel Corporation. Archived from the original on 2022-04-26. Retrieved 2022-05-26.
  65. ^ Paul, Matthias R.; Frinke, Axel C. (1997-10-13) [first published 1991], FreeKEYB - Enhanced DOS keyboard and console driver (User Manual) (v6.5 ed.) [23] (NB).FreeKEYB는 대부분의 키보드 레이아웃, 코드 페이지 및 국가 코드를 지원하는 Unicode 기반의 동적 구성 가능한 K3PLUS의 후속 버전입니다.시판 매크로 어셈블러와 자동 전처리 및 후처리 분석 툴의 프레임워크를 사용하여 바이너리 코드와 함께 실행 파일에 내장되는 의존관계 및 코드 모핑 메타 데이터를 생성하고 로더를 스스로 폐기, 완화 및 재배치함으로써 드라이버는 바이트 수준의 세분화된 동적 데드 코드를 구현합니다.e 부하 시 제거 및 재배치 기술, 실행 시 자체 코드 및 재구성 가능.기본 하드웨어, 운영체제, 드라이버 구성 및 선택한 기능 세트 및 로케일에 따라 메모리 설치 공간을 최소화하고 표준 형식을 닫습니다(약 60개의 구성 스위치 위트).h 거의 무제한의 조합에 대해 수백 개의 옵션을 선택할 수 있습니다).이러한 복잡성과 역동성은 기존 드라이버와 마찬가지로 단일 실행 파일을 처리하는 사용자에게는 숨겨져 있습니다.)
  66. ^ Paul, Matthias R. (2002-04-06). "[fd-dev] Ctrl+Alt+Del". freedos-dev. Archived from the original on 2019-04-27. Retrieved 2019-04-27. […] FreeKEYB builds the driver's runtime image at initialization time depending on the type of machine it is being loaded on, the type of keyboard, layout, country and code page used, the type of mouse and video adapter(s) installed, the other drivers loaded on that system, the operating system and the load and relocation method(s) used, the individual features included, and the configuration options specified in the command line. Due to the large number of command line switches and options supported […] (around fifty switches […] with multiple possible settings) there is a high number of feature combinations with uncountable dependencies […] resulting in […] endless number of […] different target images. FreeKEYB's Dynamic Dead Code Elimination technique manages to resolve […] these […] dependencies and […] remove dead code and data […] is not restricted to […] include or exclude a somewhat limited number of modules or whole sub-routines and fix up some dispatch tables as in classical TSR programming, but […] works […] at […] byte level […] able to remove […] individual instructions in the middle of larger routines […] distributed all over the code to handle a particular case or support a specific feature […] special tools are used to analyze the code […] and create […] fixup tables […] automated […] using conditional defines […] to declare the various cases […] not only optional at assembly time but at initialization time […] without the […] overhead of having at least some amount of dead code left in the runtime image […] to keep track of all the dependencies between […] these conditionals, dynamically build and relocate the runtime image, fix up all the references between these small, changing, and moving binary parts […] still allowing to use the tiny .COM/.SYS style […] model […] is done at initialization time […]
  67. ^ Paul, Matthias R. (2001-08-21). "[fd-dev] Changing codepages in FreeDOS". freedos-dev. Archived from the original on 2019-04-19. Retrieved 2019-04-20. […] a […] unique feature […] we call dynamic dead code elimination, so you can at installation time […] specify which components of the driver you want and which you don't. This goes to an extent of dynamic loadable modularization and late linkage I have not seen under DOS so far. If you do not like the screen saver, macros, the calculator, or mouse support, or <almost anything else>, you can specify this at the command line, and FreeKEYB, while taking all the dependencies between the routines into account, will completely remove all the code fragments, which deal with that feature and are not necessary to provide the requested functionality, before the driver relocates the image into the target location and makes itself resident. […]
  68. ^ Paul, Matthias R. (2001-04-10). "[ANN] FreeDOS beta 6 released" (in German). Newsgroup: de.comp.os.msdos. Archived from the original on 2017-09-09. Retrieved 2017-07-02. […] brandneue[s] Feature, der dynamischen Dead-Code-Elimination, die die jeweils notwendigen Bestandteile des Treibers erst zum Installationszeitpunkt zusammenbastelt und reloziert, so daß keine ungenutzten Code- oder Datenbereiche mehr resident bleiben (z.B. wenn jemand ein bestimmtes FreeKEYB-Feature nicht benötigt). […]

추가 정보