상위 메모리 영역
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
상위 메모리 영역은 IBM PC의 메모리 맵에서 ROM, RAM, I/O에 예약된 640KB와 1MB 사이의 주소 영역을 말한다. 초기 DOS 운영체제에서 상위 메모리 블록(UMB)과 고 메모리 영역(HMA)을 활용하여 메모리 사용을 최적화하는 데 사용되었으며, DR DOS 5.0과 MS-DOS 5.0에서 이 기술이 도입되었다. 윈도우 환경의 발전과 함께 상위 메모리 영역의 중요성은 점차 감소했지만, 가상 8086 모드, Shadow RAM, IBM XT 등 다양한 방식으로 구현되었다.
더 읽어볼만한 페이지
- 바이오스 - 아메리칸 메가트렌즈
아메리칸 메가트렌즈(AMI)는 1985년에 설립된 회사로, BIOS 펌웨어, 서버용 마더보드, 스토리지 컨트롤러 등을 공급하며, 현재는 AMIBIOS, Aptio, AMIDiag 등 다양한 제품을 제공한다. - 바이오스 - 부트 섹터
부트 섹터는 시스템 부팅 코드를 담은 저장 매체의 특정 영역으로, 볼륨 부트 레코드(VBR)와 마스터 부트 레코드(MBR)로 나뉘며, BIOS는 이를 실행하고 UEFI는 부트로더를 직접 로드하지만 바이러스 공격에 취약하다. - 기억 장치 - EPROM
EPROM은 자외선을 사용하여 내용을 지울 수 있는 읽기 전용 메모리이며, MOSFET의 부유 게이트를 사용하여 데이터를 저장하고, 펌웨어 업데이트가 용이하여 소량 생산에 사용되었으나 EEPROM과 플래시 메모리에 의해 대체되었다. - 기억 장치 - 정적 램
정적 램(SRAM)은 전원이 공급되는 동안 데이터를 저장하며, 갱신 회로가 필요 없고 빠른 접근 속도를 가지는 휘발성 메모리 유형이다.
| 상위 메모리 영역 | |
|---|---|
| 상위 메모리 영역 (UMA) | |
| 설명 | |
| 종류 | 물리 메모리 영역 |
| 크기 | 384KB |
| 주소 범위 | 0xA0000-0xFFFFF (640KB-1MB) |
| 용도 | 비디오 어댑터의 프레임 버퍼 BIOS 기타 장치용 메모리 매핑 영역 |
| 특징 | 실제 주소 모드에서 직접 접근 가능 보통의 메모리보다 접근 속도가 느림 DOS 운영체제에서 중요한 역할 수행 |
| 역사 | |
| 배경 | IBM PC의 초기 설계 제한으로 인해 640KB 이상의 메모리를 직접 사용하기 어려웠음. 상위 메모리 영역은 이러한 제한을 극복하기 위한 방편으로 도입됨. |
| 발전 | EMS (Expanded Memory Specification) 및 XMS (Extended Memory Specification) 등의 기술을 통해 상위 메모리 영역의 활용도가 높아짐. DOS 확장기를 사용하여 640KB 제한을 넘어선 프로그램 실행이 가능해짐. |
| 기술적 세부 사항 | |
| 메모리 맵 | 0xA0000-0xBFFFF: 비디오 메모리 (VGA, EGA 등) 0xC0000-0xF7FFF: 어댑터 ROM BIOS (하드 디스크 컨트롤러, 비디오 카드 등) 0xF8000-0xFFFFF: 시스템 BIOS |
| 메모리 관리 | UMB (Upper Memory Block): 상위 메모리 영역 내에서 사용되지 않는 블록. 메모리 관리자를 통해 UMB를 DOS 프로그램에 제공하여 메모리 활용도를 높임. |
| 활용 | |
| DOS 게임 | 게임 실행에 필요한 데이터나 코드를 상위 메모리 영역에 로드하여 640KB 기본 메모리 부족 문제를 해결. 게임의 성능 향상에 기여. |
| 장치 드라이버 | 장치 드라이버를 상위 메모리 영역에 로드하여 기본 메모리 점유를 줄임. 시스템의 안정성 및 성능 향상에 기여. |
| TSR (Terminate and Stay Resident) 프로그램 | 상주 프로그램들을 상위 메모리 영역에 위치시켜 기본 메모리 확보. 메모리 관리 효율성을 높임. |
| 문제점 및 한계 | |
| 단편화 | 상위 메모리 영역이 여러 조각으로 나뉘어져 있어 연속적인 메모리 블록 확보가 어려울 수 있음. 메모리 관리의 복잡성을 증가시킴. |
| 충돌 | 여러 장치나 프로그램이 동일한 메모리 주소를 사용하려고 시도할 경우 충돌이 발생할 수 있음. 시스템 불안정의 원인이 됨. |
| 호환성 | 일부 오래된 프로그램이나 장치는 상위 메모리 영역을 제대로 지원하지 않을 수 있음. 호환성 문제를 야기할 수 있음. |
| 현대 운영체제에서의 역할 | |
| 보호 모드 | 보호 모드에서는 상위 메모리 영역의 중요성이 감소. 가상 메모리 및 32비트/64비트 주소 공간을 활용하여 메모리 관리의 유연성을 높임. |
| 레거시 시스템 | 여전히 일부 레거시 시스템이나 임베디드 시스템에서 제한적인 형태로 사용될 수 있음. 과거의 기술과의 호환성을 유지하기 위한 목적. |
| 참고 자료 | |
| 관련 기술 | EMS (Expanded Memory Specification) XMS (Extended Memory Specification) UMB (Upper Memory Block) |
| 관련 운영체제 | DOS |
2. 예약된 메모리 공간
IBM은 PC의 메모리 맵 상위 주소 영역을 ROM, 주변 장치 내의 RAM, 메모리 맵된 입출력(I/O) 용도로 예약했다. 이 영역은 상위 메모리 영역(UMA, Upper Memory Area)이라고 불리며, 컨벤셔널 메모리의 상한선인 640KB[2]와 초기 8088 CPU의 주소 지정 한계인 1MB[2] 사이에 위치했다.
이 384KB 크기의 UMA에는 시스템 BIOS ROM, 그래픽 카드의 VRAM (예: 흑백 비디오 메모리는 0xB0000부터 0xB7FFF)[2], 기타 확장 카드의 ROM이나 입출력 포트 등이 배치되었다. 그러나 이러한 장치들을 모두 배치하더라도 UMA의 상당 부분은 활용되지 않고 비어 있는 경우가 많았다. 이후 EMS에서 뱅크 전환을 위해 64KB 크기의 페이지 프레임을 이 영역에 설정하기도 했지만, 여전히 많은 공간이 사용되지 않은 채 남아 있었다.
2. 1. 흑백/컬러 비디오 메모리 영역
IBM은 PC의 메모리 맵 상위 주소 영역인 UMA(Upper Memory Area)를 ROM, 주변 장치 내의 RAM, 메모리 맵된 입출력(I/O) 용도로 예약했다. 이 UMA는 컨벤셔널 메모리보다 상위 주소인 640KB[2]와 최초 PC의 8088 CPU 주소 상한인 1MB[2] 사이에 위치했다.이 UMA 내에서, 흑백 비디오 메모리 영역은 0xB0000부터 0xB7FFF (704KB - 736KB)까지의 주소 공간을 차지했다.[2]
2. 2. 확장 카드 ROM 및 BIOS
IBM PC의 메모리 맵에서 UMA(Upper Memory Area)는 컨벤셔널 메모리 상한선인 640KB와 초기 CPU (8088)의 주소 지정 한계인 1MB 사이의 영역이다.[2] 이 영역은 시스템 ROM, 주변 장치 내의 RAM, 그리고 메모리 맵된 입출력(I/O)을 위해 예약되었다.[2] 시스템의 기본적인 펌웨어인 BIOS는 이 UMA 영역의 ROM에 저장되었다. 또한, 그래픽 카드와 같은 다양한 확장 카드들도 자체적인 ROM이나 RAM, 입출력 영역을 이 UMA 공간에 배치하여 사용했다. 예를 들어, 흑백 비디오 카드의 VRAM은 0xB0000부터 0xB7FFF 주소에 위치했다. 하지만 BIOS ROM, VRAM, 기타 장치들의 I/O 포트 등을 모두 배치하더라도 총 384KB 크기의 UMA 중 상당 부분은 활용되지 않고 비어있는 경우가 많았다. 이는 EMS에서 뱅크 전환용 페이지 프레임(64KB)을 설정한 후에도 마찬가지였다.2. 3. 뱅크 전환 (EMS)
IBM PC의 초기 메모리 구조에서 컨벤셔널 메모리보다 상위 주소인 640KB[2]와 8088 CPU의 주소 상한인 1MB[2] 사이의 영역은 상위 메모리 영역(UMA, Upper Memory Area)으로 불리며, ROM, 주변 장치 내의 RAM, 메모리 맵된 입출력(I/O) 등을 위해 예약되었다. 예를 들어, 흑백 비디오 메모리 영역은 0xB0000부터 0xB7FFF (704 - 736 KB)에 위치했다.그러나 VRAM이나 BIOS ROM, 입출력 포트 등을 배치하더라도 이 384KB 크기의 UMA 영역 대부분은 활용되지 않고 비어 있었다. 이러한 미사용 공간을 활용하기 위해 EMS(Expanded Memory Specification)에서는 뱅크 전환 기법을 도입했다. EMS는 UMA 내에 64KB 크기의 페이지 프레임(page frame)을 확보하여, 이 프레임을 통해 더 많은 확장 메모리에 접근할 수 있도록 했다. 하지만 64KB의 페이지 프레임을 사용하더라도 UMA의 상당 부분은 여전히 비어 있는 상태로 남게 되었다.
3. DOS에서의 활용
DOS 운영체제가 발전하면서 상위 메모리 블록(UMB)과 고 메모리 영역(HMA)을 직접 활용하는 단계에 이르렀다. 이러한 변화는 1990년 DR DOS 5.0이 출시되면서 본격적으로 시작되었다. DR DOS는 내장된 메모리 관리자를 통해 운영체제 커널과 주요 데이터 구조를 고 메모리 영역으로 이동시키고, 각종 드라이버나 TSR 프로그램 등을 상위 메모리 블록에 적재함으로써 기본 메모리 공간을 이전보다 훨씬 많이 확보할 수 있는 가능성을 열었다.
하지만 초창기에는 이러한 메모리 활용 설정이 자동으로 이루어지지 않아, 사용자가 직접 UMB 영역을 찾아 지정하고 관련 파일들을 수정하는 등 다소 복잡한 수동 최적화 과정을 거쳐야 했다. 마이크로소프트는 1991년 6월 MS-DOS 5.0을 출시하며 DR DOS의 이러한 기능을 도입했고, 이후 버전에서는 메모리 최적화를 돕는 유틸리티를 포함시키기도 했다. 이처럼 DOS 환경에서 상위 메모리 영역을 적극적으로 활용하게 되면서, 제한된 기본 메모리를 최대한 확보하여 더 큰 응용 프로그램을 실행하기 위한 다양한 메모리 관리 및 최적화 기술이 중요하게 부각되었다.
3. 1. DR-DOS의 혁신 (1990년)
DOS의 다음 단계 발전은 운영 체제 자체에서 상위 메모리 블록(UMB)과 고 메모리 영역(HMA)을 활용하는 것이었다. 이는 1990년 DR DOS 5.0이 출시되면서 처음으로 실현되었다. DR DOS에 내장된 메모리 관리자인 EMM386.EXE는 당시 널리 사용되던 상용 메모리 관리자 QEMM이나 유사 프로그램들의 핵심 기능을 상당 부분 수행할 수 있었다.DR DOS 5.0이 기존 DOS와 QEMM 등을 조합하는 것보다 우월했던 점은, DR DOS의 커널 자체와 운영 체제가 사용하는 대부분의 데이터 구조를 고 메모리 영역(HMA)으로 옮길 수 있었다는 것이다. 또한, 장치 드라이버나 종료 후 상주 프로그램(TSR) 등을 상위 메모리 블록(UMB)에 로드할 수 있게 지원했다. 이로 인해 기본 메모리(Conventional Memory)가 거의 전부 비어, 설정에 따라 640KB 중 620KB까지 응용 프로그램에서 사용할 수 있게 되었다.
하지만 이러한 설정 과정은 자동으로 이루어지지 않았다. 사용자는 비어 있는 UMB 영역을 직접 찾아내어 CONFIG.SYS 파일 내 EMM386.EXE 로드 명령어에 수동으로 지정해야 했고, 각종 드라이버나 프로그램들을 UMB로 로드하도록 CONFIG.SYS나 AUTOEXEC.BAT 파일을 직접 수정해야 했다. 이는 간단한 작업이 아니었다. 반면, QEMM은 설치 과정에서 이러한 최적화 작업을 상당 부분 자동화해주었기 때문에, DR DOS 5.0 출시 이후에도 여전히 시장에서 살아남았고, 실제로 DR DOS 자체의 메모리 관리 기능과 잘 작동하여 PC용 유틸리티로 가장 많이 팔린 제품 중 하나가 되었다.
이러한 DR DOS의 혁신적인 메모리 관리 기능은 1991년 6월, 마이크로소프트(Microsoft)가 MS-DOS 5.0을 출시하면서 모방했다.
3. 2. MS-DOS의 대응 (1991년)
1990년 DR DOS 5.0이 출시되면서 상위 메모리 블록 (UMB)과 고 메모리 영역 (HMA)을 활용하는 기능이 도입되었다. DR DOS는 내장된 EMM386.EXE를 통해 QEMM과 같은 기존 메모리 관리 프로그램의 주요 기능을 제공했으며, 운영 체제 커널과 데이터 구조 대부분을 고 메모리에 적재하여 기본 메모리를 최대 620KB까지 확보할 수 있었다.이러한 DR DOS의 기능은 1991년 6월, 마이크로소프트 (Microsoft)가 MS-DOS 5.0을 출시하면서 도입되었다. MS-DOS 역시 UMB와 HMA를 지원하게 되면서 더 많은 데이터 구조를 기본 메모리에서 옮겨, 사용 가능한 기본 메모리 공간을 최대 631KB까지 늘릴 수 있었다. 이후 MS-DOS 6.0 버전부터는 MEMMAKER라는 유틸리티 프로그램을 포함시켜, 사용자가 TSR 프로그램을 상위 메모리로 자동으로 이동시키고 기본 메모리 사용을 최적화하는 과정을 더 쉽게 수행할 수 있도록 지원했다.
3. 3. 메모리 최적화 기술
1990년대 초반, 응용 프로그램의 규모가 커지고 PC 구성이 복잡해짐에 따라, 제한된 기본 메모리를 최대한 확보하기 위한 DOS 메모리 맵 최적화는 매우 중요한 기술이 되었다. 이를 통해 가장 복잡한 PC 구성에서도 대형 응용 프로그램을 실행할 수 있었다.최적화의 핵심은 운영체제가 사용하지 않는 상위 메모리 블록(UMB)을 활용하는 것이었다. 1990년 DR DOS 5.0은 EMM386.EXE라는 내장 메모리 관리자를 통해 UMB와 고위 메모리 영역(HMA)을 활용하는 기능을 처음 도입했다. DR DOS는 커널과 데이터 구조 상당 부분을 고위 메모리로 옮겨, 설정에 따라 최대 640KB의 기본 메모리 중 620KB까지 사용 가능하게 만들었다.
하지만 이 설정은 자동이 아니었다. 사용자는 직접 사용 가능한 UMB를 찾아 CONFIG.SYS 파일에서 EMM386.EXE를 로드하는 설정에 포함시켜야 했고, 이후 각종 드라이버나 TSR 프로그램 등을 CONFIG.SYS나 AUTOEXEC.BAT 파일에서 UMB로 로드하도록 수동으로 지정해야 했다. 이는 결코 간단한 과정이 아니었다. 상용 프로그램인 QEMM은 이 과정의 상당 부분을 자동화해주었기 때문에 시장에서 인기를 얻었으며, DR DOS의 메모리 관리 기능과도 잘 호환되었다.
마이크로소프트는 1991년 6월 MS-DOS 5.0을 출시하며 이 기능을 도입했고, 이후 MS-DOS 6.0부터는 MEMMAKER라는 유틸리티를 포함하여 TSR 프로그램을 상위 메모리로 옮겨 기본 메모리를 자동으로 최적화하는 기능을 제공했다.
구체적인 수동 최적화 기술은 다음과 같았다.
- UMB 확보: 컬러 디스플레이 카드의 흑백 비디오 메모리 영역처럼 할당되었지만 사용되지 않는 메모리 영역의 매핑을 변경하여 최대한 많은 UMB를 확보했다.
- UMB 로딩: DOS의 여러 구성 요소를 UMB에 로드하되, 메모리 블록을 효율적으로 사용하도록 올바른 순서를 고려해야 했다. 일부 TSR 프로그램은 로드 과정에서 추가 메모리를 사용했다가 로드 완료 후 반환하기도 했다.
- 로드 순서: 다행히 대부분의 모듈은 로드 순서에 크게 구애받지 않았지만, 예외적으로 CD-ROM 드라이버를 로드한 후에 디스크 캐시를 로드해야 했고, 네트워크 관련 모듈들은 OSI 모델 계층 순서에 따라 로드해야 하는 경우가 있었다.
기본적이면서 효과적인 최적화 방법 중 하나는 CONFIG.SYS에서 HIMEM.SYS를 먼저 로드한 뒤, EMM386.EXE를 "RAM AUTO" 옵션과 함께 로드하는 것이었다. 이 방법을 사용하면 `devicehigh` 같은 명령어로 장치 드라이버나 MSCDEX처럼 기본 메모리를 많이 차지하는 프로그램을 상위 메모리 영역(UMA)으로 로드하여 상당량의 기본 메모리를 확보할 수 있었다.
4. 멀티태스킹 환경에서의 활용
쿼터덱(Quarterdeck)의 DESQview와 같은 DOS 멀티태스킹 소프트웨어는 여러 응용 프로그램을 동시에 실행할 수 있게 해주었다. 각 응용 프로그램은 약 600KB 정도의 메모리를 사용하면서 DOS의 기능이나 드라이버에 접근할 수 있었다.
5. Windows 환경에서의 변화
윈도우 3.0과 윈도우 95가 등장하면서 상위 메모리 영역 관리의 중요성은 점차 줄어들었다. 윈도우 환경에서는 응용 프로그램이 DOS의 기본 메모리 제한에 직접적인 영향을 덜 받게 되었기 때문이다. 특히 윈도우 95는 CD, 네트워크, 사운드 등 다양한 장치 지원 기능을 자체적으로 제공하고, 윈도우 내에서 실행되는 DOS 프로그램 환경의 메모리를 자동으로 최적화하여 상위 메모리 영역 설정의 필요성을 크게 낮추었다. 하지만 이러한 변화에도 불구하고, 특정 방식으로 메모리 모드를 전환하려 하거나 특정 메모리 관리 인터페이스(VCPI)를 사용하는 일부 DOS 프로그램은 윈도우 환경에서 실행되지 않는 등 호환성 문제가 남아 있었다.
5. 1. Windows 3.x
윈도우 3.0의 인기가 높아짐에 따라 상위 메모리 영역의 필요성은 이전보다 줄어들었다. 윈도우 응용 프로그램은 DOS의 기본 메모리 제한에 직접적인 영향을 받지 않았기 때문이다. 그러나 윈도우 환경에서 실행되는 DOS 프로그램은 여전히 상위 메모리 영역 관리의 영향을 받았다. 윈도우 자체가 멀티태스킹 관리자 역할을 하면서 DOS 프로그램을 실행했기 때문이다.윈도우 95가 출시되면서 상위 메모리 영역의 중요성은 더욱 감소했다. 윈도우 95는 CD, 네트워크, 사운드 지원 등 기존에 DOS 장치 드라이버가 제공하던 많은 기능을 윈도우에서 실행되는 DOS 응용 프로그램에 직접 제공할 수 있게 되었다. 또한 윈도우 95의 DOS 박스(DOS 프로그램을 실행하는 환경)는 메모리 관리가 자동으로 최적화되었다.
하지만 모든 DOS 프로그램이 윈도우 95 환경에서 문제없이 실행될 수 있었던 것은 아니었다. 특히, 리얼 모드에서 보호 모드로 직접 전환하려는 프로그램은 윈도우 95의 가상 86 모드 환경에서는 허용되지 않아 작동하지 않았다. 또한, 가상 제어 프로그램 인터페이스(VCPI) API를 사용하여 보호 모드로 전환하려던 프로그램도 윈도우 95에서는 작동하지 않았다. 윈도우 95는 보호 모드 전환을 위해 DOS 보호 모드 인터페이스(DPMI) API만을 지원했다.
5. 2. Windows 95
윈도우 95가 출시되면서 상위 메모리 영역 관리의 중요성은 더욱 줄어들었다. 윈도우 95는 CD, 네트워크, 사운드 지원 등 기존에 DOS 장치 드라이버가 제공하던 많은 기능을 직접 지원하여, 윈도우 95 환경에서 실행되는 DOS 응용 프로그램에 필요한 별도의 드라이버 로드를 줄였다. 또한 윈도우 95의 DOS 박스(DOS 가상 머신)는 메모리 구성을 자동으로 최적화했다.그러나 모든 DOS 프로그램이 윈도우 95 환경에서 완벽하게 실행될 수 있는 것은 아니었다. 특히, 프로그램이 직접 리얼 모드에서 보호 모드로 전환하려고 시도하는 경우, 윈도우 95가 사용하는 가상 8086 모드의 제약 때문에 작동하지 않았다. 또한, 가상 제어 프로그램 인터페이스(VCPI) API를 사용하여 보호 모드로 전환하려던 프로그램들도 윈도우 95에서는 지원되지 않아 실행되지 않았다. 윈도우 95는 보호 모드 전환을 위해 DOS 보호 모드 인터페이스(DPMI) API만을 지원했다.
6. 구현 방식
상위 메모리 영역은 여러 가지 기술적 방법을 통해 구현될 수 있었다. 대표적으로 확장 메모리 관리자가 확장 메모리를 가상 8086 모드를 이용하여 상위 메모리 영역에 매핑하는 방식이 있다. 또한, 시스템 칩셋이 확장 카드 ROM을 위해 예약해 둔 RAM 영역(Shadow RAM)을 활용하거나, 초기 PC 호환기종인 IBM XT 등에서는 하드웨어 개조나 특수한 메모리 확장 카드를 통해 상위 메모리 영역을 확보하기도 했다.
6. 1. 가상 8086 모드
상위 메모리 블록은 가상 8086 모드에서 실행될 때 확장 메모리를 상위 메모리 영역에 매핑하여 생성할 수 있다. 이는 확장 메모리를 사용하여 확장 메모리를 에뮬레이트하는 방식과 유사하므로, 이러한 상위 메모리 블록 제공 방식은 일반적으로 확장 메모리 관리자(예: EMM386)에 의해 제공된다. 상위 메모리 블록 관리를 위한 응용 프로그래밍 인터페이스는 확장 메모리 사양에 명시되어 있다.6. 2. Shadow RAM
최신 시스템을 포함한 많은 시스템에서는 확장 카드 ROM을 섀도잉하기 위해 예약된 메모리를 상위 메모리로 사용할 수 있다. 많은 칩셋은 이러한 목적으로 최대 384KB의 RAM을 예약하는데, 이 RAM은 일반적으로 사용되지 않는다. 따라서 UMBPCI와 같은 사용자 지정 장치 드라이버를 사용하여 리얼 모드 상위 메모리로 활용할 수 있다.6. 3. IBM XT
IBM XT 컴퓨터에서는 마더보드에 메모리를 더 추가하고, 맞춤형 주소 디코더 PROM을 사용하여 이 메모리가 상위 메모리 영역에 나타나도록 할 수 있었다. 이렇게 추가된 RAM은 386 기반 컴퓨터의 상위 메모리처럼 TSR 파일을 로드하거나 램 디스크로 사용하는 것이 가능했다.또한, XT급 컴퓨터용 애드온 메모리 관리 장치인 AllCard를 이용하는 방법도 있었다. AllCard는 일반 메모리를 0xA0000부터 0xEFFFF까지의 주소 범위에 매핑하여, DOS 프로그램이 최대 952KB까지 메모리를 사용할 수 있게 했다. 하지만 Lotus 1-2-3처럼 비디오 메모리에 직접 접근하는 프로그램들은 이러한 메모리 구성을 사용하기 위해 소프트웨어 패치가 필요했다. 즉, 소프트웨어 호환성을 일부 포기하는 대신 640KB 장벽을 넘어설 수 있었다. 이는 단순히 장치 드라이버나 TSR을 1 MB 주소 공간의 상위 384KB(상위 메모리 블록, UMB)로 옮겨 기본 메모리를 확보하는 방식과는 다른 개념이었다.
참조
[1]
웹사이트
Memory Map (x86) - OSDev Wiki
https://wiki.osdev.o[...]
2020-12-20
[2]
문서
[3]
웹인용
Memory Map (x86) - OSDev Wiki
https://wiki.osdev.o[...]
2020-12-20
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com