✅ 요약

32비트와 64비트의 차이는 ‘한 번에 처리할 수 있는 정보량’과
‘다룰 수 있는 메모리 크기’의 차이이며,
프로그램의 성능과 범위를 결정짓는 아주 중요한 요소이다.

---

1️⃣ 32비트? 64비트? 그게 뭔데?

컴퓨터는 모든 데이터를 숫자로 처리하며,
이 숫자를 계산하거나 저장할 때 쓰는 공간이 레지스터(Register)이다.

32비트 시스템은 한 번에 32자리 숫자를 처리할 수 있으며,
64비트 시스템은 64자리 숫자를 한 번에 처리할 수 있다.

📦 쉽게 말해 계산기의 화면 크기가 두 배가 된 셈이다.

---

2️⃣ 가장 큰 차이: 다룰 수 있는 메모리 크기

항목	32비트	64비트
최대 메모리 주소	약 4GB	약 18엑사바이트(EB)
포인터 크기	4바이트	8바이트

포인터(pointer)는 메모리 주소를 저장하는 변수로,
이 크기에 따라 프로그램이 다룰 수 있는 메모리 범위가 결정된다.

📚 32비트는 책장 하나라면, 64비트는 도서관 전체라고 볼 수 있다.

---

3️⃣ 함수 호출 방식도 다르다

📌 32비트 방식

32비트 시스템에서는 함수를 호출할 때,
전달할 값들을 스택(stack)이라는 메모리 구조에 저장한 뒤 호출한다.

push arg2
push arg1
call function

이 방식은 비교적 단순하지만, 연산마다 스택에 접근해야 하므로 느릴 수 있다.

---

📌 64비트 방식

64비트 시스템에서는 인자를 스택이 아니라 CPU 내부 레지스터에 직접 넣어 호출한다.

mov rdi, arg1
mov rsi, arg2
call function

이 방식은 처리 속도가 훨씬 빠르고, CPU의 성능을 더 효율적으로 끌어낼 수 있는 구조이다.

---

4️⃣ 시스템 콜 처리 방식의 차이

시스템 콜(system call)이란, 프로그램이 운영체제에게 어떤 기능을 요청할 때 사용하는 명령이다.
예를 들어 파일을 열거나 출력하는 작업은 시스템 콜을 통해 요청한다.

항목	32비트	64비트
방식	int 0x80	syscall
특징	인터럽트를 발생시켜 처리한다	전용 명령어로 빠르게 처리한다

64비트 시스템은 더 현대적인 명령어를 사용하므로 속도가 빠르고 효율적이다.

---

5️⃣ 실행 파일 구조도 다르다 (ELF 포맷)

운영체제는 실행 가능한 파일을 실행할 때 ELF(Executable and Linkable Format)이라는 구조를 따른다.

항목	ELF32	ELF64
포인터 크기	4바이트	8바이트
주소 표현 범위	작다	크다
헤더 크기	52바이트	64바이트

🔍 다음과 같이 터미널에서 ELF 파일 구조를 확인할 수 있다:

file a.out
# ELF 64-bit LSB executable, x86-64

---

6️⃣ PintOS와의 연결

⚙️ PintOS는 32비트 기반이다

PintOS는 교육용 운영체제 프로젝트로,
x86 32비트 구조를 기반으로 설계되어 있다.

커널과 유저 프로그램은 4GB 안에서 주소를 나눠 쓰며,
모든 레지스터와 주소도 32비트(4바이트) 크기를 기준으로 한다.

---

🔍 그러나 64비트 개념도 반드시 이해해야 한다

현대의 컴퓨터는 대부분 64비트 구조를 따르고 있으며,
우리가 사용하는 리눅스 시스템과 디버깅 툴(GDB)도 64비트 환경에서 동작한다.

따라서 PintOS를 실습할 때도 rax, rsp, ELF64 같은 개념을 마주하게 된다.
이를 제대로 이해하지 못하면 실습 과정에서 혼란이 생길 수 있다.

---

🧮 핵심 비교 정리

항목	32비트	64비트
주소 크기	4바이트	8바이트
최대 메모리 공간	4GB	이론상 18EB
레지스터 이름	eax, esp 등	rax, rsp, r8~r15 등
함수 인자 전달	스택 사용	레지스터 사용
시스템 콜	int 0x80	syscall
실행 파일 형식	ELF32	ELF64
PintOS 구조	32비트 고정	GDB 환경에서는 64비트 이해 필요

---

📌 마무리

• 32비트와 64비트의 차이는 단순한 숫자가 아니라,
  컴퓨터가 처리할 수 있는 데이터의 양과 속도, 구조 전체에 영향을 미치는 중요한 기준이다.
• PintOS는 32비트 기반이지만, 실습 환경은 64비트이며,
  이 둘을 연결해 이해하는 것이 시스템 프로그래밍을 공부하는 핵심 포인트이다.

---

✅ 정리: KAIST PintOS는 "64비트 리눅스 + 32비트 PintOS" 구조이다.

구분	설명
호스트 환경 (Linux)	64비트 리눅스 (x86_64)에서 빌드하고 실행
QEMU 가상 머신	32비트 x86 하드웨어로 에뮬레이션
PintOS 내부 커널	32비트 아키텍처(x86, IA-32) 기반 코드

---

🧠 왜 이런 구조인가?

1. 교육 목적: 32비트 구조는 단순하고 명확하여, 운영체제의 기본 원리를 학습하기에 적합하다.
2. 레지스터 구조가 단순: eax, ebx, esp, ebp 등 기본 8개의 레지스터만 사용
3. 메모리 모델이 제한적: 가상 메모리, 스택, 힙 등을 직관적으로 설계하고 실험할 수 있음
4. 현실과의 연결도 가능: 리눅스에서 실행하지만, 실제 OS 구조의 축소판으로 작동함

---

💻 예시: 시스템 콜 처리 방식

KAIST PintOS에서도 시스템 콜은 여전히 인터럽트 방식으로 처리한다.

// syscall.c
void syscall_init(void) {
  intr_register_int(0x30, 3, INTR_ON, syscall_handler, "syscall");
}

• int 0x30 명령으로 커널로 진입한다.
• struct intr_frame 구조체를 통해 유저 스택 → 커널 전환 시 레지스터 상태를 저장한다.
• syscall 번호는 f->eax에 들어 있고, 결과값도 f->eax에 넣어 다시 유저 모드로 복귀한다.

---

🤔 왜 64비트 환경에서 32비트 커널을 쓰는가?

• QEMU 가상 머신은 CPU를 흉내내는 소프트웨어다.
  KAIST PintOS는 QEMU 위에서 32비트 x86 CPU를 가상으로 실행한다.
• 우리가 사용하는 컴파일러(GCC), GDB, 터미널은 모두 64비트 환경에서 실행되지만,
  그 안에서 돌아가는 PintOS 자체는 32비트 모드로 동작한다.

---

🔍 실습 시 나타나는 현상

상황	이유
GDB에선 eax, esp 같은 32비트 레지스터만 보임	PintOS 커널이 32비트로 컴파일되기 때문
유저 프로그램이 syscall 할 때 int 0x30 사용	syscall이 인터럽트 기반이기 때문
포인터 크기가 4바이트로 제한됨	32비트 아키텍처이기 때문

---

✅ 결론

• KAIST PintOS는 64비트 환경에서 빌드되지만,
  운영체제 실습 대상인 커널은 철저히 32비트 아키텍처를 따른다.
• 시스템 콜은 int 0x30을 사용하는 인터럽트 기반 구조이고,
  이는 리눅스 32비트 시절 시스템 콜 처리 방식과 유사하다.
• 64비트 환경에서 실습하더라도, 모든 커널 설계는 32비트 기준으로 사고해야 한다.

---

추가 이야기

64비트 게임으로 바뀌면서 기존의 32비트 매크로 프로그램이 더 이상 게임 프로세스에 접근하지 못하거나, 일부 기능만 되는 이유는 “비트 호환성”과 “메모리 구조 접근 방식의 차이” 때문이다.

---

🧠 핵심 요약

구분	설명
✅ 되는 매크로	게임과 간접적으로 상호작용하거나, 별도 외부 입력만 쓰는 방식 (ex. 마우스 클릭, 키 입력 등)
❌ 안 되는 매크로	게임 메모리 내부를 읽거나 조작하는 방식 (ex. 주소 찾아서 직접 값 바꾸기, 메모리 기반 매크로)

---

💻 좀 더 자세히 설명해볼게

1. ✅ 어떤 매크로는 잘 작동하는 이유

• 키보드 입력, 마우스 클릭, 윈도우 포커스 같은 표준 입력 방식을 사용하는 매크로는
  32비트든 64비트든 운영체제의 WinAPI가 중간에서 다 처리해주기 때문에 작동 가능하다.
• 예: SendInput(), keybd_event(), mouse_event() 같은 함수는 비트 차이와 무관하게 작동함.

2. ❌ 어떤 매크로는 작동이 안 되는 이유

🧨 이유 1. 매크로가 메모리 접근 방식에 의존할 경우

• 예전 32비트 게임은 프로세스 주소 공간이 4GB 내에서 단순해서,
  매크로가 특정 주소나 구조체 위치를 쉽게 찾아 조작할 수 있었음
• 하지만 64비트에서는 주소 크기가 8바이트로 커지고,
  구조체 정렬(Padding)도 달라지고, 메모리 보호도 강화됨

→ 32비트 매크로는 더 이상 올바른 메모리 주소를 참조하지 못하거나, 잘못된 크기로 읽음

🧨 이유 2. 운영체제 보호 구조 때문

• 64비트 Windows에서는 WOW64 (Windows on Windows64)라는 호환 계층이 있음
  → 32비트 프로그램은 64비트 프로세스 메모리에 직접 접근 불가
• 32비트 매크로는 64비트 게임 프로세스를 열어서 메모리를 읽거나 쓰려고 할 경우,
  권한 거부나 접근 실패가 발생함

32비트 프로그램은 64비트 프로세스의 메모리에 OpenProcess(), ReadProcessMemory() 같은 API로 접근할 수 없도록 제한되어 있다.

---

🧪 예시로 정리해보면

매크로 기능	32비트 게임	64비트 게임
키보드 입력 자동화	가능	가능
마우스 클릭 자동화	가능	가능
게임 메모리 읽고 수정	가능	❌ (구조 달라짐 + 접근 차단)
특정 좌표나 체력 정보 읽기	가능	❌ (주소 해석 실패)
DLL 인젝션 방식	가능	❌ (비트 다르면 인젝션 불가)

---

🔧 해결 방법은?

1. 매크로를 64비트로 다시 컴파일해야 함
   → 메모리 구조에 맞게 주소 크기, 구조체 정렬 등을 고쳐야 함

2. 64비트 게임에 맞는 매크로 새로 제작
   → 특히 메모리 스캔이나 게임 구조 분석을 다시 해야 함

3. 또는, 게임 제작자가 아예 매크로를 막은 경우도 있음
   → 그럴 땐 어떤 방식으로도 동작하지 않게 막혀 있을 수 있음

---

✅ 마무리 요약

• 64비트 게임은 구조가 완전히 다르기 때문에,
  32비트로 만든 매크로는 일부 기능을 제외하면 호환되지 않는다.
• 특히 메모리 접근 방식이나 주소 해석에 의존하는 매크로는 대부분 작동하지 않는다.
• 해결하려면 매크로를 64비트 환경에 맞게 다시 개발하거나, 아예 새로 제작해야 한다.