Batas memori dalam sistem 16, 32 dan 64 bit


17

Batas memori teoretis dalam mesin 16, 32 dan 64 bit adalah sebagai berikut:

  • 16 bit = 65.536 byte (64 Kilobyte)

  • 32 bit = 4.294.967.296 byte (4 Gigabytes)

  • 64 bit = 18.446.744.073.709.551.616 (16 Exabytes)

Saya ingat dari DOS / Windows 3,11 hari, bahwa memori 16 bit dapat dipisahkan menjadi segmen, sehingga mesin 16 bit dapat mengakses jumlah memori yang lebih besar daripada 64 Kilobyte.

Saya memiliki mesin dengan 16GB memori, dan saya dual boot sistem operasi 32bit dan sistem operasi 64bit. Saya dapat mengakses semua 16GB dari 64bit, tetapi hanya 3,21GB dalam 32bit.

Jadi, pertanyaan saya adalah, jika sistem operasi 16bit memungkinkan lebih besar dari akses memori 64KB karena segmentasi memori, mengapa mesin 32bit tidak mengikuti prinsip yang sama?

Jawaban:


15

Mereka melakukannya, sistem ini disebut Extension Alamat Fisik (PAE) . Berikut adalah daftar OS windows dan memori maksnya, sistem 32 bit apa saja yang memungkinkan lebih dari 4GB RAM menggunakan PAE untuk mengakses memori (Misalnya Windows 2003 R2 Datacenter 32 bit memungkinkan 128GB ram).


Sebenarnya Windows 8 membutuhkan CPU yang mampu PAE dalam persyaratan minimum itu .


Untuk menjawab pertanyaan "tanpa diminta" tentang mengapa OS 32 bit Anda tidak dapat mengakses ram jika ada: Lisensi. Mereka memilih untuk tidak membiarkan RAM berada di atas 4GB untuk OS 32 bit mereka kecuali jika Anda membayar untuk edisi pusat data (itulah sebabnya mereka menjual edisi pusat data, jika Anda membutuhkan ram sebanyak itu, Anda mungkin bisa mengeluarkan lebih banyak uang pada OS).


Ah saya pernah mendengar tentang PAE sebelumnya tetapi tidak pernah menyelidikinya. Tampaknya sebagian besar digunakan dalam arsitektur server, jadi sepertinya tidak berlaku untuk instalasi Windows 7 32bit, karena daftar menetapkan bahwa W7x86 hanya memungkinkan hingga 4GB
Matthew Layton

1
@ 0xC0000022L agar adil, saya menambahkan bagian lisensi sebagai edit setelah komentarnya, tetapi karena jendela edit 4 menit sepertinya saya mempostingnya sebelum dia mengirim komentar.
Scott Chamberlain

1
PAE mengharuskan switcheroo tabel halaman berfungsi, dan itu mahal dalam hal kinerja.
vonbrand

3
Itu hanya mitos. Biaya overhead karena PAE kecil. Dan jika Anda tidak menyukai PAE Anda harus benar-benar membenci x64, karena struktur tabel halaman pada x64 terlihat seperti PAE, hanya dengan level tabel yang ditambahkan di atas dan lebih banyak bit untuk PFN di PxE.
Jamie Hanrahan

1
PAE tidak "dihapus di Windows 7 karena tidak lagi diperlukan", itu masih ada di Windows 7 x86 - itu hanya ada secara default daripada harus dipilih.
Jamie Hanrahan

13

Alih-alih menjelaskannya sendiri, saya akan membiarkan seseorang yang harus memelihara kernel dengan dukungan PAE berbicara dengan cara yang menawan, Linus Torvalds

Juga perlu diingat bahwa dukungan PAE dalam versi Windows 32bit datang untuk banyak uang. XP bahkan tidak akan dapat menggunakan RAM 4 GiB penuh secara normal, karena MS memilih untuk tidak mengaktifkan fitur PAE di dalamnya. Kernel yang terkait erat, Windows 2003 Server, mendukung PAE. Namun, bahkan di sana "Edisi standar" Anda hanya akan mendukung hingga 4 GiB (tetapi bekerja di sekitar lubang memori BIOS), sedangkan edisi yang lebih mahal akan memungkinkan hingga 64 GiB RAM. Hal yang sama berlaku untuk Vista 32-bit .

Namun, tidak semua pembatasan ini diberlakukan oleh Windows. Jika ya, mem-boot kernel Linux yang mendukung PAE masih akan memungkinkan Anda untuk menggunakan 4 GiB penuh (atau lebih). Tidak demikian, beberapa produsen perangkat keras memilih untuk menerapkan batasan ini pada tingkat BIOS, meskipun CPU dan chipset akan mampu menangani PAE.


Hanya catatan tambahan: tidak ada prosesor 64bit berbasis x86 saat ini yang bahkan dapat menangani seluruh ruang alamat 64bit secara fisik (untuk referensi lihat pertanyaan dan jawaban ini).


Hmm, mengapa saya mendapat kesan bahwa Linus benar-benar membenci HIGHMEM.SYS dan PAE? : P
Karan

2
Saya mengerti bahwa PAE akan menjadi gangguan untuk kode apa pun yang membutuhkan lebih dari beberapa pertunjukan set kerja, dan untuk kode tingkat sistem yang perlu mengelola beberapa tugas masing-masing 2 pertunjukan, tetapi kecuali satu aplikasi membutuhkan lebih dari 2 pertunjukan. gigs Saya harapkan PAE transparan. Lebih jauh, saya akan berpikir PAE juga akan lebih baik daripada penggunaan global 64-bit pointer dalam kasus yang membutuhkan 3 gigs RAM untuk keperluan umum ditambah cache disk yang besar atau drive penyimpanan temp.
supercat

Komentar Linus aneh. Tidak ada hubungan antara cara kerja himem.sys dan cara kerja PAE. Sangat menyenangkan melihat orang-orang berdebat untuk x64 dan menentang pengalamatan PAE ... ketika mode lama x64 hanya mengambil skema PAE dan menambahkan satu tingkat lagi dari tabel halaman!
Jamie Hanrahan

@JamieHanrahan: ... setidaknya dua pada sistem yang lebih baru (karena virtualisasi), yang membuka beberapa kemungkinan menarik. Perbandingannya (Linus ') tidak sepenuhnya benar, tetapi jika itu adalah konsep asing, metafora dapat membantu :) ... Saya kira itu sebabnya ia memilihnya untuk menyampaikan maksudnya.
0xC0000022L

2

CPU 8-bit biasanya memiliki bus alamat 16-bit. (Motorola memiliki bus alamat terpadu, RAM dan perangkat I / O berbagi ruang alamat yang sama, Intel memilih untuk membagi keduanya. Dalam kasus Intel, batas alamat IO dari 8088 dan 8086 membawa batas lebih dari 8080 & 8085 CPU.)

Intel 8088 dan 8086 memiliki bus alamat memori 20-bit (1MB), sedangkan Motorola 68000 memiliki bus alamat 24-bit (16 MB). IIRC, [80] 286 melompat ke bus alamat 24-bit. Keduanya kemudian diperluas ke bus alamat 32-bit dengan [80] 386 dan 68020 masing-masing.) Dengan chip Pentium, bus alamat diperluas menjadi 64-bit. (Saya pikir chip PowerPC Motorola / IBM juga menggunakan bus alamat 64-bit.)

Memori yang tersedia di bawah ini dan hingga maksimum yang dapat langsung diakses oleh CPU hanya dibatasi oleh chip perangkat keras pendukung (chipset) dan OS. Bill Gates terkenal di masa lalu karena menyatakan bahwa tidak ada yang membutuhkan lebih dari 640K RAM, sehingga DOS tidak pernah berevolusi untuk secara langsung mengakses lebih banyak RAM. Dengan HiMem.sys dan EMM386, DOS diperluas untuk mengakses lebih banyak memori "atas", dengan EMM386 digunakan untuk secara langsung mengakses semua RAM yang tersedia. HiMem.sys memiliki fleksibilitas yang lebih rendah dan pada dasarnya dapat menggunakan RAM tambahan untuk penyimpanan.

Memori yang melebihi batas itu membutuhkan MMU (Memory Management Unit) untuk memecah memori menjadi segmen-segmen dan memetakannya ke ruang memori yang dapat dialamatkan dari CPU. Begitulah cara CoCo 3, Commodore 128, dan komputer 8-bit lainnya dapat mengakses lebih dari 64 ribu RAM.

Lebih menguntungkan sekarang adalah menggunakan memori virtual untuk memperpanjang batas memori fisik masa lalu, meskipun dengan batas yang ditentukan oleh OS.


1

Karena tidak ada alasan praktis untuk melakukannya. Ekstensi Alamat Fisik memungkinkan banyak fungsi yang sama dan penggunaannya masih sangat terbatas di antara pengguna. Di Windows 3.1 hari ada kendala yang tidak hadir hari ini.


1
Ini benar-benar tidak memiliki informasi yang cukup untuk membuat cadangan pernyataan Anda. Windows 3.1 adalah sistem operasi 16-bit. Kita harus ingat bahwa pada tahun 1992 memori 2MB adalah lebih dari $ 300.
Ramhound

Anda 22 Februari komentar, dan penjelasan Scott Chamberlin cukup banyak membahas apa yang saya kendarai. Mereka tidak memberikan deskripsi mengapa pagination tersegmentasi yang dapat diperluas digunakan dalam DOS / Win16, tetapi tidak pada Windows yang lebih baru. Saya tidak memasukkan itu, karena itu tidak akan berkontribusi langsung untuk menjawab pertanyaan OP.
OCDtech

Pandangan saya bahwa jawaban harus berdiri sendiri. Komentar Anda menambahkan informasi yang cukup untuk menyelesaikan masalah saya dengan jawaban Anda.
Ramhound

1
@OCDtech: Model tersegmentasi 8086 akan memungkinkan bahasa berorientasi objek menggunakan referensi objek 2-byte untuk mengidentifikasi objek yang diluruskan pada batas 16-byte, tetapi bahasa tidak dilengkapi dengan baik untuk menggunakan segmen secara efektif. Model 80286 memaksakan overhead yang sangat besar untuk program seperti itu, dan cara itu diperluas pada 80386 akan membuat skema segmen per objek sama sekali tidak berguna.
supercat

0

Batas memori teoretis dalam mesin 16, 32 dan 64 bit adalah sebagai berikut ...

Kelemahan mendasar di sini adalah anggapan bahwa "lebar bit" prosesor, yang biasanya berukuran register tujuan umum mesin, harus sama dengan lebar alamat RAM.

Di x86 dengan paging diaktifkan, tetapi tanpa PAE, alamat yang menggunakan program dan kode OS disebut "alamat linear" oleh Intel - kami biasanya menyebutnya "alamat virtual". Mereka lebar 32 bit. Ini memungkinkan ruang alamat virtual 4 GiB.

Tapi ini lebih atau kurang kebetulan, hanya sebuah artefak dari format entri tabel halaman yang ukuran alamat fisik (RAM) juga 32 bit.

Dengan PAE yang terakhir adalah 36 bit (pada awalnya ... lebih luas dalam implementasi selanjutnya). Jadi, hanya karena, misalnya, "mesin 32 bit" tidak berarti alamat memori fisik dibatasi hingga 32 bit.

Industri ini memiliki sejarah panjang mesin yang "lebar bit" tidak cocok dengan ukuran alamat fisik maksimumnya. Sebagai contoh, arsitektur VAX mendefinisikan mesin 32-bit, dan alamat virtual (yang merupakan alamat yang digunakan oleh kode setelah terjemahan alamat dihidupkan) memang lebar 32 bit ... tetapi alamat fisik VAX hanya memiliki lebar 30 bit - dan setengah dari ruang alamat fisik dikhususkan untuk register perangkat I / O, sehingga RAM maksimum hanya 512 MiB.

Bahkan tanpa perangkat keras terjemahan alamat, belum tentu bahwa "bit lebar" mesin menentukan alamat RAM maksimum. Contoh: Seri CDC "3000 atas" adalah mesin 36-bit. Apakah Anda pikir mereka dapat mengatasi 64 GiB RAM? Tidak sulit! Mesin-mesin itu keluar di pertengahan 60-an! Heck, kita bahkan tidak bisa memiliki 64 GB ruang disk pada hari-hari. (Seri CDC 6000 adalah mesin 60-bit. Perlu saya lanjutkan?)


Dan jangan lupa tentang sistem yang tidak menggunakan 8-bit per sel RAM. (EG: 16/16 = Maks 128K, 32/32 = Maks 16G, Maks 32/64 = 32G)
SkyCharger
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.