Bagaimana cara komputer menentukan tipe data byte?


31

Misalnya, jika komputer telah 10111100disimpan pada satu byte tertentu dari RAM, bagaimana komputer tahu untuk menafsirkan byte ini sebagai integer, karakter ASCII, atau yang lainnya? Apakah tipe data disimpan dalam byte yang berdekatan? (Saya tidak berpikir ini akan terjadi karena ini akan menghasilkan penggunaan dua kali jumlah ruang untuk satu byte.)

Saya menduga bahwa mungkin sebuah komputer bahkan tidak tahu tipe data, bahwa hanya program yang menggunakannya yang tahu. Dugaan saya adalah bahwa karena RAM adalah R AM dan karena itu tidak membaca secara berurutan, bahwa program tertentu hanya memberitahu CPU untuk mengambil info dari alamat tertentu dan program mendefinisikan bagaimana mengobatinya. Ini sepertinya cocok dengan pemrograman hal-hal seperti kebutuhan untuk typecasting.

Apakah saya di jalur yang benar?


4
Sebagai catatan: Jika Anda berbicara tentang jenis, Anda harus melakukannya dalam konteks bahasa. Terserah kepada kompiler untuk menangani hal semacam itu (simbol, jenis cek, operasi, casting, ram alamat, dll). CPU dan RAM hanya tahu byte
jean

4
Tipe data byte adalah byte. Di luar itu, komputer tidak tahu apa-apa. Suatu program mungkin menginterpretasikan satu byte atau sekelompok byte sebagai tipe data tertentu, dan mencoba melakukan operasi pada mereka, tetapi tidak ada batasan di sana. Kelompok byte yang sama dapat diinterpretasikan sebagai lebih dari satu tipe data (mis. Casting pointer ke tipe nilai, C-like unions, dll.). Bahwa RAM tidak dibaca secara berurutan tidak benar-benar relevan. - Ini lebih karena RAM adalah tujuan umum. - Register misalnya juga tidak dibaca secara berurutan, tetapi mereka diketik.
BrainSlugs83

5
Plug shameless untuk saya sendiri, tetapi pertanyaan ini pada dasarnya ditanyakan pada programmer SE sekitar sebulan yang lalu. Inilah jawaban saya untuk itu . Agak lama pada titik ini, tetapi menyerang dari beberapa sudut yang berbeda.
Shaz

2
Salah satu konsekuensi yang berguna dari fakta bahwa perangkat keras adalah datatype-agnostik adalah bahwa satu byte (atau kata, dll.) Dapat ditafsirkan berbagai cara oleh suatu program. Khususnya, menginterpretasikan sementara angka floating-point sebagai integer digunakan untuk menghitung root kuadrat terbalik cepat .
Aoeuid

@ BrainSlugs83, dapatkah Anda mempertimbangkan untuk mengubahnya menjadi jawaban?
DW

Jawaban:


38

Kecurigaan Anda benar. CPU tidak peduli dengan semantik data Anda. Namun, terkadang itu membuat perbedaan. Misalnya, beberapa operasi aritmatika menghasilkan hasil yang berbeda ketika argumen ditandatangani atau tidak ditandatangani secara semantik. Dalam hal ini Anda perlu memberi tahu CPU interpretasi mana yang Anda maksudkan.

Terserah programmer untuk memahami datanya. CPU hanya mematuhi perintah, tidak menyadari arti atau tujuan mereka.


1
Mengenai "ketika argumen secara semantik ditandatangani atau tidak ditandatangani", bagaimana CPU akan tahu? Operasi CPU hanya melihat byte parameter dan tidak memiliki kesadaran konteks tipe data semacam itu. Anda menyiratkan tipe data dengan memilih operasi CPU yang sesuai (atau kompiler Anda tidak).
Shiv

4
@ Shiv Dalam kasus seperti itu, CPU sebenarnya mengeluarkan instruksi berbeda untuk memproses angka yang ditandatangani dengan angka yang tidak ditandatangani. Seperti dalam kecurigaan OP, program ini berkewajiban untuk memberikan detail tersebut, karena CPU tidak mengetahui.
Cort Ammon - Reinstate Monica

2
Saya telah bekerja dengan komputer selama saya mengingat diri saya sendiri, dan meskipun saya tahu CPU tidak peduli dengan konstruksi tingkat tinggi yang kami gunakan pada pemrograman tingkat tinggi, tetapi pemisahan konsep ini masih membuat saya takut dari waktu ke waktu.
Loupax

1
@Loupax Yah, bekerja dengan perakitan tingkat rendah benar-benar membantu sedikit - bahkan mov al, 42semacam tingkat tinggi - sudah jelas hanya ada satu instruksi yang mungkin bisa dipanggil, tapi masih agak abstrak. Namun, menggunakan mov.8 al, 42secara eksplisit membuat ini sangat menyakitkan :)
Luaan

1
@ Shiv: Saya ingin mencatat bahwa ada mesin di mana data dalam memori diketik. Ini disebut arsitektur memori yang ditandai (atau arsitektur yang hanya ditandai) tetapi mereka belum sesukses secara komersial seperti arsitektur biasa sebagian karena kami sekarang memprogram sebagian besar dalam bahasa yang dikompilasi alih-alih perakitan dan kompiler menangani pengetikan. Lihat: en.wikipedia.org/wiki/Tagged_architecture
slebetman

14

Seperti yang sudah dijawab oleh orang lain, CPU umum saat ini tidak tahu isi posisi memori yang diberikan; perangkat lunak memutuskan.

Namun, ada kemungkinan lain. Mesin Lisp misalnya menggunakan arsitektur yang ditandai yang menyimpan jenis setiap posisi memori; dengan cara itu perangkat keras itu sendiri dapat melakukan beberapa pekerjaan bahasa tingkat tinggi.

Dan bahkan sekarang, saya kira Anda dapat mempertimbangkan bit NX di Intel, AMD, ARM dan arsitektur lainnya untuk mengikuti prinsip yang sama: bedakan pada tingkat perangkat keras apakah zona memori yang diberikan berisi data atau instruksi.

Juga, hanya untuk kelengkapan, dalam arsitektur Harvard (seperti beberapa mikrokontroler) data dan instruksi dipisahkan secara fisik, sehingga CPU memiliki beberapa gagasan tentang apa yang dibaca.

Dalam pertanyaan Quora ini ada beberapa komentar tentang bagaimana memori yang ditandai bekerja, implikasi kinerja dan kehancurannya, dan banyak lagi.


Arsitektur tagged adalah catatan yang menarik. Apakah ini akan jauh lebih cepat?
Bassinator

4

Iya nih. Program hanya mendapatkan byte dari memori dan dapat menafsirkannya seperti yang diinginkan.


3

Tidak ada penjelasan jenis.
RAM menyimpan data murni, dan kemudian program menentukan apa yang harus dilakukan.

Dengan register CPU sedikit lebih sulit, jika Anda memiliki register tipe tertentu (seperti FPU), Anda tahu apa yang ada di dalamnya.
Operasi pada register titik apung secara eksplisit menggunakan data yang diketik. Anda atau kompiler Anda memberi tahu apa dan kapan harus diletakkan di sana, sehingga Anda tidak memiliki kebebasan seperti itu.
Komputer tidak membuat asumsi apa pun tentang data yang mendasarinya dalam RAM, dan dalam register dengan satu pengecualian - register yang diketik dalam CPU adalah tipe yang dikenal, dioptimalkan untuk menghadapinya. Ini hanya untuk menunjukkan bahwa ada tempat-tempat di mana data harus dari tipe yang diharapkan, tetapi tidak ada yang menghentikan Anda dari casting string ke float dan mengalikannya.

Dalam bahasa pemrograman Anda menentukan jenis, atau dalam bahasa tingkat yang lebih tinggi data bersifat umum dan kompiler / juru bahasa / VM mengkodekan apa yang ada di dalam dengan overhead.
Misalnya di C, jenis penunjuk Anda memberi tahu apa yang harus dilakukan dengan data, cara mengaksesnya.

Tentu saja Anda dapat membaca string (karakter) dan memperlakukannya sebagai nilai floating point, bilangan bulat dan mencampurnya.


Bahkan bit dalam register FPU tidak selalu mewakili nilai floating point. Di masa lalu (mungkin tidak begitu banyak lagi?), Optimasi umum adalah dengan menggunakan register floating point (64-bit atau lebih besar) untuk menyalin data lebih cepat daripada register tujuan umum / integer (32-bit), menjadi dua kali lebih besar, mereka umumnya dapat menyalin data dua kali lebih cepat.
Seth

1
Saya sangat setuju dengan Anda, itu sebabnya saya menulis seseorang mungkin mendorong string di sana. Dan pada saat yang sama orang melakukan operasi floating point pada bilangan bulat, karena lebih cepat. Itu intinya!
Evil

@HCBPshenanigans ada instruksi yang memanipulasi nilai floating-point. Jika FADD digunakan hanya masuk akal bahwa kelompok memori (4,8, atau 10) -by memegang angka floating-point. Itu benar untuk beberapa jenis instruksi: kalikan dua bilangan bulat hanya masuk akal jika bilangan bulat, lompat hanya masuk akal jika itu adalah alamat.
JDługosz

@seth dan evilJS yang tidak dianggap sebagai kasus untuk legacy floating point ditumpuk 8087 instruksi, tetapi adalah kasus untuk register CIMD baru yang dapat digunakan hanya untuk memuat / menyimpan tanpa interpretasi (meskipun mereka harus disejajarkan), dan peringatan bahwa jika register CIMD tidak pernah digunakan daripada mereka tidak perlu disimpan dalam saklar konteks. Jika Anda (hanya) memindahkan 8 byte melalui register XMM, ini merupakan kerugian bersih karena seluruh set perlu disimpan.
JDługosz

3

CPU tidak peduli, ia mengeksekusi kode perakitan, yang hanya memindahkan data, memindahkannya, menambah atau mengalikannya ...

Tipe Data adalah konsep bahasa tingkat yang lebih tinggi: dalam C atau C ++ Anda perlu menentukan Tipe untuk setiap bagian data yang Anda manipulasi; C / C ++ Compiler menangani transformasi bagian data ini menjadi perintah yang tepat untuk diproses oleh CPU (kompiler menulis kode perakitan)

Dalam beberapa bahasa tingkat yang lebih tinggi, Jenis dapat disimpulkan: dalam Python atau Javascript, misalnya, seseorang tidak harus menentukan tipe data, namun data memiliki tipe dan Anda tidak dapat menambahkan string dengan integer, tetapi Anda dapat menambahkan float dengan integer: 'compiler' (yang dalam kasus Javascript adalah JIT (Just in Time) Compiler. Javascript sering disebut bahasa 'ditafsirkan' karena secara historis browser menafsirkan kode Javascript, tetapi saat ini mesin Javascript adalah kompiler.

Kode, selalu berakhir dikompilasi ke kode mesin, tetapi jelas format kode mesin tergantung pada mesin yang Anda targetkan (kode x86 64bit tidak akan berfungsi pada mesin x86 32 bit atau prosesor ARM misalnya)

Jadi sebenarnya ada banyak lapisan yang terlibat dalam menjalankan kode yang ditafsirkan.

Java dan C # adalah yang menarik lainnya, karena kode Java atau C # secara teknis 'dikompilasi' ke biner Java (bytecode), tetapi kode itu sendiri kemudian ditafsirkan oleh Java Runtime, yang khusus untuk perangkat keras yang mendasarinya (orang perlu menginstal JRE menargetkan mesin yang tepat untuk menjalankan Java binaries (Jars))


Kompiler mengkompilasi, apakah itu JIT atau tidak; dan seorang juru bahasa menafsirkan tanpa kompilasi (karena jika tidak itu akan menjadi kompiler!). Mereka adalah hal yang sangat berbeda. Dan mengenai "Java lucu" karena interpretasi bytecode, pertimbangkan bahwa bahkan kode mesin x86 benar-benar akan ditafsirkan (atau bahkan dikompilasi?) Oleh mikroprosesor menjadi mikrokode .
hmijail

Terima kasih atas klarifikasi ... Setuju: kompiler menyusun, dan penerjemah juru bahasa. Dalam kasus Javascript, ceritanya agak rumit karena beberapa peramban yang lebih lama menafsirkan kode, sementara peramban yang lebih modern sebenarnya mengkompilasi just-in-time, yang mungkin mengapa itu masih disebut sebagai bahasa 'ditafsirkan' meskipun itu secara teknis tidak lagi.
MrE

Tapi AFAIK, JS mulai ditafsirkan, dan kemudian mungkin dikompilasi sesuai kebutuhan. Dan JIT dapat beralih dari ditafsirkan ke dikompilasi ke ditafsirkan lagi, tergantung pada banyak hal. Misalnya, sepotong kode dapat dikompilasi untuk variabel yang memiliki tipe tertentu; tetapi kemudian kode dijalankan lagi dengan variabel yang memiliki tipe yang berbeda, sehingga kode yang dikompilasi yang ada tidak dapat digunakan sehingga penerjemah melompat - sampai kode tersebut dikompilasi lagi untuk tipe baru ...
hmijail

Anda mengutip saya pada sesuatu yang tidak saya katakan, tolong hapus karena itu benar-benar salah. Microcode tidak ada hubungannya dengan OS; itu adalah sesuatu yang internal untuk mikroprosesor. 32 bit atau 64 bit juga tidak ada hubungannya dengan itu.
hmijail

3

Datatypes bukan fitur perangkat keras. CPU tahu beberapa (well, banyak) perintah yang berbeda. Itu disebut set instruksi CPU.

Salah satu yang paling dikenal adalah set instruksi x86 . Jika Anda mencari "multiply" di halaman ini, Anda mendapatkan 50 hasil. MULPDdan MULSDuntuk perkalian ganda, FIMULuntuk perkalian bilangan bulat, ...

Perintah-perintah itu berfungsi pada register. Register adalah slot memori yang dapat berisi jumlah bit tetap (seringkali 32 atau 64, tergantung pada arsitektur yang digunakan CPU Anda), tidak peduli apa yang diwakili bit ini. Oleh karena itu instruksi CPU menginterpretasikan nilai register dengan cara yang berbeda, tetapi nilai itu sendiri tidak memiliki tipe.

Contoh diberikan di PyCon 2017 oleh Stuart Williams :

masukkan deskripsi gambar di sini


1
Perhatikan bahwa ini tidak sepenuhnya benar: ada register tujuan khusus yang tidak dapat berisi nilai arbitrer (misalnya, register pointer yang bukan sembarang alamat dan tidak memungkinkan penambahan sewenang-wenang, atau register floating point di mana Anda bisa dapat menyimpan nilai yang tidak dinormalisasi). Tetapi jawaban Anda benar untuk register tujuan umum pada sebagian besar arsitektur.
Gilles 'SANGAT berhenti menjadi jahat'

2

... bahwa program tertentu hanya memberi tahu CPU untuk mengambil info dari alamat tertentu dan program menentukan cara mengobatinya.

Persis. Tetapi RAM tidak dibaca "secara berurutan", dan itu adalah singkatan dari Random Access Memory yang justru sebaliknya.

Selain mengetahui apa byte adalah , Anda bahkan tidak tahu apakah itu byte , atau sebuah fragmen dari item yang lebih besar seperti angka floating-point.

Saya ingin menambahkan jawaban lain dengan memberikan beberapa contoh spesifik.

Pertimbangkan 01000001. Program dapat menyalinnya dari satu tempat ke tempat lain sebagai bagian dari paket besar data tanpa memperhatikan artinya. Tetapi menyalin itu ke alamat yang digunakan oleh buffer video mode teks akan menyebabkan surat itu Amuncul di beberapa posisi di layar. Tindakan yang sama persis ketika kartu berada dalam mode grafis CGA akan menampilkan piksel merah dan piksel biru.

Dalam register, bisa jadi nomor 65 sebagai bilangan bulat. Melakukan aritmatika untuk mengatur bit 32-an bisa berarti apa saja tanpa konteks, tetapi mungkin secara khusus mengubah huruf menjadi huruf kecil.

CPU 8086 (masih) memiliki instruksi khusus yang disebut DAA yang digunakan ketika register memiliki 2 angka desimal, jadi jika Anda hanya menggunakan instruksi itu Anda menafsirkannya sebagai dua digit 41.

Program macet karena kata memori dibaca berpikir itu adalah pointer ketika sesuatu yang lain disimpan di sana.

Menggunakan debugger, memeriksa memori, peta digunakan untuk memandu interpretasi untuk tampilan. Tanpa informasi simbol ini, debugger tingkat rendah memungkinkan Anda menentukan: menunjukkan alamat ini sebagai kata 16-bit, menunjukkan alamat ini sebagai titik mengambang yang panjang, sebagai string ... apa pun. Melihat dump paket jaringan atau format file yang tidak dikenal, membingungkan itu adalah sebuah tantangan.

Itu adalah sumber utama kekuatan dan fleksibilitas dalam arsitektur komputer modern: sel memori dapat berarti apa saja , data atau instruksi, tersirat hanya dalam apa yang "berarti" untuk program dengan apa yang dilakukannya dengan nilai dan bagaimana hal itu mempengaruhi operasi selanjutnya. artinya lebih dalam dari lebar integer: apakah karakter ini ... karakter dalam ascii atau ebcdic? Membentuk kata dalam bahasa Inggris atau kode produk SQU? Alamat tujuan pengiriman atau alamat pengirimnya? Interpretasi level terendah (bit logis; bilangan bulat, ditandatangani atau tidak ditandatangani; float; bcd; pointer) kontekstual pada level set instruksi, tetapi Anda melihat bahwa itu semua konteks pada beberapa level: the toalamat adalah apa itu karena lokasi itu tercetak di amplop. Itu kontekstual dengan aturan tukang pos, bukan CPU. Konteksnya adalah satu kontinum besar, dengan bit di satu ujungnya.


※ Catatan Kaki: Instruksi DAA dikodekan sebagai byte 00100111. Jadi byte itu adalah instruksi yang disebutkan sebelumnya jika dibaca dalam aliran instruksi, dan digit 27jika ditafsirkan sebagai digit bcd, dan 0x27 = 39 sebagai bilangan bulat, yang merupakan angka 9 dalam ASCII, dan bagian dari tabel interrupt (setengah dari INT 13 Alamat 2-byte, digunakan untuk rutinitas layanan BIOS).


1

Satu-satunya cara komputer mengetahui bahwa lokasi memori adalah instruksi adalah bahwa register dengan tujuan khusus yang disebut penunjuk instruksi menunjuk ke mereka pada satu titik atau lainnya. Jika penunjuk instruksi menunjuk ke kata memori, itu dimuat sebagai instruksi. Selain itu, komputer tidak memiliki cara untuk mengetahui perbedaan antara program dan tipe data lainnya.

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.