프로그램이 32 비트 또는 64 비트라는 것은 무엇을 의미합니까?

프로그램이 32 비트 또는 64 비트라는 것은 무엇을 의미합니까?

---

이 질문 : 32/64 비트 OS에서 WORD는 각각 몇 비트를 포함합니까? , 워드 크기는 프로세서 레지스터의 비트 크기를 나타냅니다. 즉, 컴퓨터 프로세서가 작동하는 비트 수를 의미합니다. 즉, 프로세서가 작동하는 가장 작은 '보이지 않는'비트 양을 의미합니다.

그 맞습니까? Word / Excel / etc와 같은 소프트웨어를 사용하여 설치 프로그램에는 32 비트 또는 64 비트 설치 옵션이 있습니다. 차이점은 무엇입니까?

컴퓨터 아키텍처가 고정되어 있기 때문에 '32 비트 '소프트웨어는 32 비트 아키텍처를 사용하는 컴퓨터 아키텍처에 맞게 설계 될 것 같습니다. 그리고 64 비트 프로그램은 명령어 세트를 64 비트 워드 크기에 맞추기 위해 노력합니다.

그 맞습니까?

여기에 매우 유사한 질문이 있습니다. 프로그래밍 관점에서 프로그램이 32 비트 또는 64 비트라는 것은 무엇을 의미합니까? -그리고 받아 들여진 대답은 그 차이가 응용 프로그램에 할당 할 수있는 메모리 양이라는 것을 언급합니다. 그러나 이것은 너무 모호합니다. 32 비트 / 64 비트 소프트웨어 개념이 32 비트 / 64 비트 워드 프로세서 크기와 완전히 관련이없는 경우가 아니면?

---

단어 크기는 큰 차이이지만 유일한 것은 아닙니다. CPU가 "등급을받는"비트 수를 정의하는 경향이 있지만, 단어 크기와 전체 기능은 약간의 관련이 있습니다. 그리고 전반적인 기능이 중요합니다.

Intel 또는 AMD CPU에서 32 비트 대 64 비트 소프트웨어는 실제로 CPU를 실행할 때 작동하는 모드를 나타냅니다. 32 비트 모드에는 사용 가능한 레지스터와 명령어가 적거나 적지 만 가장 중요한 제한은 사용 가능한 메모리 양입니다. 32 비트 소프트웨어는 일반적으로 2GB에서 4GB 미만의 메모리 사용으로 제한됩니다 .

메모리의 각 바이트에는 고유 한 주소가 있으며 이는 고유 한 우편 주소를 가진 각 집과 크게 다르지 않습니다. 메모리 주소는 프로그램이 데이터를 메모리에 저장 한 후 다시 데이터를 찾는 데 사용할 수있는 숫자 일 뿐이며 메모리의 각 바이트에는 주소가 있어야합니다. 주소가 32 비트이면 2 ^ 32 개의 가능한 주소가 있으며 이는 2 ^ 32 개의 주소 지정 가능한 메모리 바이트를 의미합니다. 오늘날의 Intel / AMD CPU에서 메모리 주소의 크기는 레지스터의 크기와 동일합니다 (항상 사실은 아니었지만).

32 비트 주소를 사용하면 프로그램에서 4GB (2 ^ 32 바이트) 주소를 지정할 수 있지만 해당 공간의 최대 절반은 OS에 의해 예약됩니다. 사용 가능한 메모리 공간에는 프로그램 코드, 데이터 및 종종 액세스되는 파일이 있어야합니다. 많은 기가 바이트의 RAM이있는 오늘날의 PC에서는 사용 가능한 메모리를 활용하지 못합니다. 이것이 64 비트가 대중화되는 주된 이유입니다. 64 비트 CPU는 2GB보다 큰 메모리 크기가 일반화 될 때까지 (일반적으로 32 비트 모드에서) 사용 가능하고 널리 사용되었습니다.이 시점에서 64 비트 모드는 실제 이점을 제공하기 시작하여 인기를 얻었습니다. 64 비트의 메모리 주소 공간은 현재 소프트웨어가 사용할 수있는 것보다 더 많은 16 엑사 바이트의 주소 지정 가능 메모리 (~ 18 조 바이트)를 제공하며,이 정도의 RAM 근처에는 PC가 없습니다.

64 비트 모드에서도 일반적인 애플리케이션에서 사용되는 대부분의 데이터는 64 비트 일 필요가 없으므로 대부분의 데이터는 여전히 32 비트 (또는 더 작은) 형식으로 저장됩니다. 일반적인 ASCII 및 UTF-8 텍스트 표현은 8 비트 데이터 형식을 사용합니다. 프로그램이 메모리의 한 위치에서 다른 위치로 큰 텍스트 블록을 이동해야하는 경우 한 번에 64 비트를 시도 할 수 있지만 텍스트를 해석해야하는 경우 한 번에 8 비트를 수행합니다. . 마찬가지로 32 비트는 정수의 일반적인 크기입니다 (최대 범위 +/- 2 ^ 31 또는 약 +/- 21 억). 21 억은 많은 용도에 충분한 범위입니다. 그래픽 데이터는 일반적으로 픽셀 단위로 자연스럽게 표현되며, 각 픽셀은 일반적으로 최대 32 비트의 데이터를 포함합니다.

64 비트 데이터를 불필요하게 사용하는 데는 단점이 있습니다. 64 비트 데이터는 메모리에서 더 많은 공간을 차지하고 CPU 캐시에서 더 많은 공간을 차지합니다 (단기 저장을 위해 CPU에서 사용하는 매우 빠른 메모리). 메모리는 최대 속도로만 데이터를 전송할 수 있으며 64 비트 데이터는 두 배입니다. 낭비 할 경우 성능이 저하 될 수 있습니다. 그리고 32 비트 및 64 비트 버전의 소프트웨어를 모두 지원해야하는 경우 가능하면 32 비트 값을 사용하면 두 버전 간의 차이를 줄이고 개발을 더 쉽게 할 수 있습니다 (항상 그렇게 작동하지는 않음).

32 비트 이전에는 주소와 워드 크기가 일반적으로 달랐습니다 (예 : 20 비트 메모리 주소가 있지만 16 비트 레지스터가있는 16 비트 8086/88, 16 비트 메모리 주소가있는 8 비트 6502, 또는 초기 32 비트 -26 비트 주소가있는 ARM). 더 나은 레지스터를 찾는 프로그래머는 없었지만 메모리 공간은 일반적으로 각 발전하는 기술 세대의 진정한 원동력이었습니다. 이는 대부분의 프로그래머가 레지스터로 직접 작업하는 경우는 드물지만 메모리로 직접 작업하고 메모리 제한은 프로그래머에게 직접적으로 불편 함을 유발하고 32 비트에서 64 비트의 경우 사용자에게도 불편 함을 유발하기 때문입니다.

요약하면, 다양한 비트 크기간에 실질적이고 중요한 기술적 차이가 있지만 32 비트 또는 64 비트 (또는 16 비트 또는 8 비트)가 실제로 의미하는 것은 단순히 다음과 관련된 기능 모음입니다. 특정 기술 세대의 CPU 및 / 또는 이러한 기능을 활용하는 소프트웨어. 단어 길이는 그것의 일부이지만 유일하거나 반드시 가장 중요한 부분은 아닙니다.

출처 :이 모든 기술 시대를 통해 프로그래머였습니다.

---

참조하는 답변 은 32 비트보다 64 비트의 이점 을 설명 합니다 . 프로그램 자체가 실제로 다른 점은 당신의 관점에 달려 있습니다.

일반적으로 프로그램 소스 코드는 전혀 다를 필요가 없습니다. 대부분의 프로그램은 컴파일러 및 / 또는 컴파일러 옵션의 적절한 선택에 의해 제어되는대로 32 비트 또는 64 비트 프로그램과 완벽하게 컴파일되도록 작성할 수 있습니다. 그러나 64 비트를 대상으로하는 (C) 컴파일러가 유형을 다르게 정의하도록 선택할 수 있다는 점에서 소스에 약간의 영향 이있는 경우가 많습니다 . 특히, long int32 비트 플랫폼에서는 어디에서나 32 비트 폭이지만 많은 (전부는 아님) 64 비트 플랫폼에서 64 비트 폭입니다. 이는 이러한 세부 사항에 대해 부당한 가정을하는 코드 버그의 원인이 될 수 있습니다.

주요 차이점은 모두 바이너리에 있습니다. 64 비트 프로그램은 64 비트 대상 CPU의 전체 명령어 세트를 사용하며, 이는 항상 32 비트 대응 CPU에 포함되지 않은 명령어를 포함합니다. 32 비트 대응 CPU에없는 레지스터를 사용합니다. 대상 CPU에 적합한 함수 호출 규칙을 사용합니다. 이는 32 비트 프로그램보다 레지스터에 더 많은 인수를 전달하는 것을 의미합니다. 이러한 기능과 64 비트 CPU의 기타 기능을 사용하면 더 많은 메모리를 사용할 수있는 능력과 (때로는) 성능 향상과 같은 기능적 이점을 얻을 수 있습니다.

---

프로그램은 프로세서에 의해 구현되는 주어진 아키텍처 (아치 또는 ISA) 위에서 실행됩니다. 일반적으로 아키텍처는 "기본"단어 크기를 정의합니다. 이는 레지스터에서 실행되는 대부분의 레지스터 및 작업 크기입니다 (다르게 작동하는 아키텍처를 설계 할 수 있음). 아키텍처는 서로 다른 크기의 레지스터를 사용하는 작업을 허용 할 수 있지만 일반적으로 "기본"단어 크기라고합니다.

또한 프로세서는 메모리를 사용하므로 어떻게 든 해당 메모리를 처리해야합니다. 즉, 해당 주소로 작동한다는 의미입니다. 따라서 주소는 일반적으로 다른 번호처럼 저장 및 조작 할 수 있습니다. 즉, 주소를 보유 할 수있는 레지스터가 있습니다. 이러한 레지스터가 워드 크기와 일치 할 필요는없고 단일 레지스터에서 주소를 계산할 필요도 없지만 일부 아키텍처에서는 이것이 사실입니다.

역사를 통틀어 단어 크기가 다른 많은 아키텍처, 심지어 이상한 아키텍처가있었습니다. 요즘에는 32 비트 및 64 비트뿐만 아니라 8 비트 및 16 비트 (일반적으로 임베디드 장치에서) 인 프로세서를 쉽게 찾을 수 있습니다. 일반적인 데스크톱 컴퓨터에서는 각각 32 비트 및 64 비트 인 x86 또는 x64를 사용하고 있습니다.

따라서 프로그램이 32 비트 또는 64 비트라고 말할 때 특정 아키텍처를 참조하는 것입니다. 널리 사용되는 데스크톱 시나리오에서는 x86 대 x64를 언급합니다. 둘 사이의 차이점을 논의하는 많은 질문, 기사 및 책이 있습니다.

이제 마지막 참고 사항 : 호환성을 위해 x64 프로세서는 다른 모드에서 작동 할 수 있으며, 그중 하나는 x86에서 32 비트 코드를 실행할 수 있습니다. 즉, 컴퓨터가 x64 (가능성이 높음)이고 운영 체제가이를 지원하는 경우 (예 : Windows 64 비트) x86 용으로 컴파일 된 프로그램을 계속 실행할 수 있습니다.

---

Word / Excel / etc와 같은 소프트웨어를 사용하여 설치 프로그램에는 32 비트 또는 64 비트 설치 옵션이 있습니다. 차이점은 무엇입니까?

이것은 사용 된 CPU에 따라 다릅니다.

SPARC CPU에서 "32 비트"와 "64 비트"프로그램의 차이점은 다음과 같습니다.

64 비트 프로그램은 32 비트 SPARC CPU에서 지원하지 않는 추가 작업을 사용합니다. 반면에 Solaris 또는 Linux 운영 체제는 64 비트 명령어를 사용해서 만 액세스 할 수있는 메모리 영역에 64 비트 프로그램이 액세스 한 데이터를 배치합니다. 즉, 64 비트 프로그램은 32 비트 CPU에서 지원하지 않는 명령어를 사용해야합니다.

x86 CPU의 경우 이것은 다릅니다.

최신 x86 CPU는 작동 모드가 다르며 다양한 유형의 코드를 실행할 수 있습니다. 다양한 모드에서 16 비트, 32 비트 또는 64 비트 코드를 실행할 수 있습니다.

16 비트, 32 비트 및 64 비트 코드에서 CPU는 바이트를 다르게 해석합니다.

바이트 (16 진수) b8 4e 61 bc 00 c3는 다음과 같이 해석됩니다.

mov    eax,0xbc614e
ret

... 32 비트 코드에서 다음과 같이 :

mov    ax,0x614e
mov    sp,0xc300

... 16 비트 코드에서.

"64 비트 설치"와 "32 비트 설치"의 EXE 파일에있는 바이트는 CPU에서 다르게 해석되어야합니다.

그리고 64 비트 프로그램은 명령어 세트를 64 비트 워드 크기에 맞추기 위해 노력합니다.

16 비트 코드 (위 참조)는 CPU가 16 비트 CPU가 아닌 경우 32 비트 레지스터에 액세스 할 수 있습니다.

따라서 "16 비트 프로그램"은 32 비트 또는 64 비트 x86 CPU의 32 비트 레지스터에 액세스 할 수 있습니다.

---

워드 크기는 프로세서 레지스터의 비트 크기를 나타냅니다.

일반적으로 예 (몇 가지 예외 / 합병증이 있지만)

• 이것은 컴퓨터 프로세서가 작동하는 비트 수를 의미합니다. 즉, 프로세서가 작동하는 가장 작은 '보이지 않는'비트 수입니다.

아니요, 대부분의 프로세서 아키텍처는 기본 단어 크기보다 작은 값에서 작동 할 수 있습니다. 더 나은 (완벽하지 않은) 정의는 프로세서가 단일 단위로 (주 정수 데이터 경로를 통해) 처리 할 수있는 가장 큰 데이터 조각입니다.

일반적으로 최신 32 비트 및 64 비트 시스템에서 포인터는 워드 크기와 동일한 크기이지만 많은 64 비트 시스템에서는 해당 포인터의 모든 비트를 실제로 사용할 수있는 것은 아닙니다. 주소 지정 가능한 메모리가 시스템의 기본 단어 크기보다 큰 메모리 모델을 가질 수 있으며 8 비트 및 16 비트 시대에 일반적으로 사용되었지만 32 비트가 도입 된 이후로 선호되지 않았습니다. 비트 CPU.

컴퓨터 아키텍처가 고정되어 있기 때문에

물론 물리적 아키텍처는 고정되어 있지만 많은 프로세서에는 프로그래머가 사용할 수있는 명령어와 레지스터가 다른 여러 작동 모드가 있습니다. 64 비트 모드에서는 CPU의 전체 기능을 사용할 수 있으며 32 비트 모드에서는 프로세서가 기능과 주소 공간을 제한하는 이전 버전과 호환되는 인터페이스를 제공합니다. 모드는 코드가 특정 모드에 대해 컴파일되어야 할 정도로 충분히 다릅니다.

일반적으로 64 비트 모드에서 실행되는 OS는 32 비트 모드에서 실행되는 응용 프로그램을 지원할 수 있지만 그 반대의 경우도 마찬가지입니다.

따라서 32 비트 애플리케이션은 32 비트 OS를 실행하는 32 비트 프로세서, 32 비트 OS를 실행하는 64 비트 프로세서 또는 64 비트 OS를 실행하는 64 비트 프로세서에서 32 비트 모드로 실행됩니다.

반면에 64 비트 응용 프로그램은 일반적으로 64 비트 OS를 실행하는 64 비트 프로세서에서만 실행됩니다.

---

가지고있는 정보는 사진의 좋은 부분이지만 전부는 아닙니다. 나는 프로세서 전문가가 아니기 때문에 내 대답이 누락 될 수있는 몇 가지 세부 사항이있을 수 있습니다.

32 비트 대 64 비트는 프로세서 아키텍처와 관련이 있습니다. 단어 크기를 늘리면 몇 가지 작업이 수행됩니다.

• 단어 크기가 클수록 더 많은 명령어를 정의 할 수 있습니다. 예를 들어, 단일로드 명령어를 수행하는 8 비트 프로세서는 총 256 개의 명령어 만 가질 수 있으며, 워드 크기가 클수록 프로세서 마이크로 코드에 더 많은 명령어를 정의 할 수 있습니다. 분명히, 얼마나 많은 유용한 명령어가 정의되는지에는 한계가 있습니다.
• 더 많은 비트를 사용할 수 있으므로 단일 명령 사이클로 더 많은 데이터를 처리 할 수 ​​있습니다. 이렇게하면 실행 속도가 빨라집니다.
• Like you stated, it also allows access to a larger memory space without having to do things like multiple address cycles, or multiplexing high/low data words.

When the processor architecture moves from 32-bit to 64-bit, the chip manufacturer will likely maintain compatibility with the previous instruction set, so that all the software that was developed previously will still run on the new architecture. When you target the 64-bit architecture, the compiler will have new instructions available and memory addressing schemes with which to process data more efficiently.

---

Short answer: This is a convention based solely on the width of the underlying data bus

An n-bit program is a program that is optimized for an n-bit CPU. Said otherwise a 64-bit program is a binary program compiled for a 64 bit CPU. A 64 bit CPU, in turn, is one taking advantage of a 64-bit data bus for the exchange of data between CPU and memory.

That's as simple, but you can read more below.

---

The definition actually redirects to understanding what is a 32/64 bit CPU, indirectly to what is a 32/64 bit operating system, and how compilers optimize binaries for a given architecture.

Optimization here encompasses the format of the binary itself. 32 bit and 64-bit binaries for a given OS, e.g. a Windows binary, have different formats. However, a given 64 bit OS, e.g. Windows 64, will be able to read and launch a 32-bit binary file written for the 32-bit version and a 32-bit wide data bus.

---

32/64 bit CPU, first definition

The CPU can store/recall a certain quantity of data in memory in a single instruction. A 32-bit CPU can transfer 4 bytes (32 bits) at once and a 64-bit CPU can transfer 8 bytes (64 bits) at once. So "32/64 bit" prefix comes from the quantity of RAM transferred in a single read/write cycle.

This quantity impacts the execution time: The fewer transfer cycles are required, the less the CPU waits for the memory, the program executes faster. It's like carrying a large quantity of water with a small or a large bucket.

The size of the bucket (the number of bits used for data transfer) is used to indicate how efficient the architecture is, hence for the same CPU, a 32-bit application is less efficient than a 64-bit application.

32/64 bit CPU, technical definition

Obviously, the RAM and the CPU must be both able to manage a 32/64-bit data transfer, which in turn determines the number of wires used to connect the CPU to the RAM (system bus). 32/64 bit is actually the number of wires/tracks composing the data bus (usually named the bus "width").

^{(Wikipedia: System bus - The data bus width determines the prefix 32/64 bit for a CPU, a program, an OS, ...)}

(Another bus is the address bus, which is usually wider, but the address bus width is irrelevant in naming a CPU as 32 or 64 bit CPU. This address bus width determines the total quantity of RAM which can be reached / "addressed" by the CPU, e.g. 2 GB or 32 GB. As for the control bus, it is a small bus used to synchronize everything connected to the data bus, in particular, it indicates when the data bus is stable and ready to be sampled in a data transfer operation).

When bits are transferred between the CPU and the RAM, the voltage on the different copper tracks of the data bus must be stable prior to reading data on the bus, else one or more bit values would be wrong. It takes less time to stabilize 8 bits than 64 bits, so increasing the data bus width is not without problems to solve.

32/64 bit program: A compiler matter

Programs don't always need to transfer 4 bytes (32-bit data bus) or 8 bytes (64-bit data bus), so they use different instructions to read 1 byte, 2 bytes, 4 bytes, and 8 bits, for performance reasons.

Binaries (native assembly language programs) are written either with the 32-bit architecture in mind, or the 64-bit architecture, and the associated instruction set. So the name 32/64 bit program.

The choice of the target architecture is a matter of compiler/compiler options used when converting the source program into a binary. Most compilers are able to produce a 32 bit or a 64 binary from the same source program. That's why you'll find both versions of an application when downloading your preferred program or tool.

However, most programs rely on ready-made libraries written by other programmers (e.g. a video editing program may use FFmpeg library). To produce a fully 64-bit application, the compiler (actually the link editor, but let's keep it simple) needs to access a 64-bit version of any library used, which may not be possible.

This also applies to operating systems themselves, as an OS is just a suite of individual programs and libraries. However, an OS is itself a kind of big library for the user programs, acting as a gateway between the computer hardware and the user programs, for efficiency and security reasons. The way OS is written car prevent the user programs to access the full potential of the underlying CPU architecture.

32-bit program compatibility with 64-bit CPU

A 64-bit operating system is able to run a 32-bit binary on a 64-bit architecture, as the 64 bit CPU instruction set is retro-compatible. However, some adjustments are required.

In addition of the data bus width and read/write instructions subset, there are many other differences between 32 bit and 64 bit CPU (register operations, memory caches, data alignment/boundaries, timing, ...).

Running a 32-bit program on a 64-bit architecture:

• is more efficient than running it on an older 32-bit architecture (almost solely due to CPU clock speed improvement compared to older 32/64 bit CPU generations)
• is less efficient than running the same application compiled into a 64-bit binary to take advantage of the 64-bit architecture, in particular, the ability to transfer 64 bits at once from/to memory.
  
  When compiling a source into a 32-bit binary, the compiler will still use small buckets, instead of the larger available with the 64-bit data bus. This has the largest impact on execution speed, compared to the same application compiled to use large buckets.

For information, the applications compiled into 16 bit Windows binaries (earlier versions of Windows running on 80-286 CPU with a 16-bit data bus) are not fully supported anymore, though there is still a possibility on Windows 10 to activate NTVDM.

The case of .NET, Java and other interpreted "byte-code"

While until recent years, compilers were used to translate a source program (e.g. a C++ source) into a machine language program, this method is now in regression.

The main problem is that machine language for some CPU is not the same than for another (think about differences between a smartphone using an ARM chip and a server using an Intel chip). You definitely can't use the same binary on both hardware, they are not talking the same language, and even if this were possible it would be inefficient on both machines due to the huge differences in how they work.

The current idea is to use an intermediate representation (IR) of the instructions, derived from the source. Java (Sun, sadly now Oracle) and IL (Microsoft) are such intermediate representations. The same IR file can be used on any OS supporting the IR.

Once the OS opens the file, it performs the final compilation into the "local" machine language understood by the actual CPU and taking into account the final architecture on which to run the program. For example, for Microsoft .NET, the universal version is executed by a CoreCLR virtual machine located on the final computer. There is usually no notion of data bus width in such intermediate languages, hence less and less application will have this n-bit prefix.

However we cannot forget the actual architecture, so there will be still 32 and 64 bit versions produced for the CoreCLR to optimize the final code, even if the application itself, at the IR level, is not optimized for a given architecture (only one IR version to download and install).

ReferenceURL : https://stackoverflow.com/questions/56186081/what-does-it-mean-for-a-program-to-be-32-or-64-bit