win64비트와 win32비트의 구분 방법
- CPU가 버스를 통해서 한 번에 전송 및 수신할 수 있는 데이터의 크기
- 데이터 처리 능력(명령어 포함)
- 메모리에서 CPU에 한번에 전달할 수 있는 명령어의 개수에 따라 달라짐
1) 32비트
- 데이터를 4byte 단위로 처리 및 송신
- 32비트의 컴퓨터에서 최대 RAM의 크기는 4G바이트
2) 64비트
- 데이터를 8byte 단위로 처리 및 송신
- 64비트 컴퓨터에서 최대 RAM의 크기는 16테라 바이트
내부 메모리에 해당하는 램의 주소
- 운영체제에서 프로그램을 위한 가상의 주소
- 주소의 표현 범위가 넓으면 좋은 이유 -> 메모리 부족으로 프로그램 실행 불가하지 않음
내 컴퓨터에서 RAM 할당 방법
- 주소를 표현하는데 32비트를 활용(2의 32승)에 해당하는 4G바이트 할당
- 주소값은 4G(1024*1024*1024*1024)까지 표현 가능
- 32비트 컴퓨터(포인터가 32비트) / 64비트 컴퓨터(포인터가 64비트) (포인터:주소값을 저장)
64비트와 32비트 공존의 문제점 (소주잔 / 맥주잔 비교) - 데이터 손실 ( overflow / underflow)
- 주소값을 출력하기 위해서 int형 변수 지정
- 32비트 시스템에서 정상 출력 (int, pointer -> 4byte)
- 64비트 pointer -> int, long 4byte 정수형 형변환(x)
- 40byte를 4byte로 줄이려다 데이터 손실 발생!!
64비트 기반 프로그래밍
64비트 시스템을 고려한 프로그램으로 자료형에 대해서 고려해야 함
LLP64 vs L64 (모델 자체가 다름)
Linux, UNIX는 64bit에서 long형이 64bit / Windows는 64bit에서 long형이 32bit
1) LLP64 (윈도우기반 모델)
- int와 long은 그대로 4바이트로 표현
- 포인터만 8바이트로 표현하는 방식
- 32비트 시스템과의 호환성을 중시한 모델(포괄)
2) LP64 (유닉스기반 모델)
- UNIX에서 취하는 모델
- Long을 표현하는 부분
Windows 스타일의 자료형
- 다른 시스템으로의 이식성을 고려하기 위해 사용
- 프로젝트의 성격 및 특성에 맞게 새로운 이름으로 자료형을 정의
- 선언의 편리성 (typedef는 복잡한 선언을 단순화) #define
- 확장의 용이성
포인터에 대한 Windows 정의
- win64로 이전하면서 등장한 자료형들을 사용할 경우
- 변수 선언시 할당된 바이트 수를 정확하고도 쉽게 파악
- win32에 저장된 자료형이 win64환경에서 쓸모가 없어진 것은 아님
- 유니코드와 아스키코드를 공통으로 지원
Polymorphic 자료형
- 다양한 모습이 있는 다형적이라는 뜻
- 상황과 환경에 따라 그 자료형이 의미하는 바가 유동적
- 32bit, 64bit 포인터 정밀도가 달라 발생하는 문제 해결
'Programming > System Programming' 카테고리의 다른 글
[System Programming] 프로세스의 스케줄링과 상태 변화 (0) | 2021.02.13 |
---|---|
[System Programming] 프로젝트 디자인 - 에러코드확인 / 명령프롬프트 (0) | 2020.12.20 |
[System Programming] 아스키코드와 유니코드 (0) | 2020.12.14 |
[System Programming] 프로그램의 실행 과정 / 데이터버스 주소버스 컨트롤버스 (0) | 2020.12.14 |
[System Programming] 컴퓨터 하드웨어의 구성 / CPU (0) | 2020.12.14 |