Apakah perlu untuk memahami apa yang terjadi pada tingkat perangkat keras untuk menjadi programmer yang baik?

24

Saya seorang programmer otodidak, kalau-kalau pertanyaan ini dijawab dalam CS 101. Saya telah belajar dan menggunakan banyak bahasa, kebanyakan untuk penggunaan pribadi saya, tetapi kadang-kadang untuk hal-hal profesional.

Sepertinya saya selalu berlari ke dinding yang sama ketika saya mengalami kesulitan pemrograman. Sebagai contoh, saya hanya mengajukan pertanyaan di forum lain tentang bagaimana menangani pointer-to-array yang dikembalikan oleh suatu fungsi. Awalnya saya berpikir bahwa saya tidak tahu teknik yang tepat yang dirancang oleh para perancang C ++ untuk menangani situasi tersebut. Tetapi dari jawaban dan diskusi yang mengikuti saya melihat bahwa saya tidak benar-benar mendapatkan apa yang terjadi ketika sesuatu 'dikembalikan'.

Seberapa dalam tingkat pemahaman proses pemrograman yang harus dicapai oleh seorang programmer yang baik?

bev
sumber
3
Saran saya: Pelajari beberapa perakitan x86 (DOS atau lainnya). Kemudian belajar membaca beberapa output assembler dari beberapa bagian kecil kode C. Ajukan pertanyaan jika Anda tidak mengerti hasilnya. Ulangi. Ini akan memaksa Anda untuk memahami apa yang terjadi di tingkat CPU
Earlz
Earlz - Apakah maksud Anda saya harus belajar memprogram menggunakan set instruksi x86? Apakah itu 'level CPU'?
bev
Ayub - thx, itu menyenangkan. Dia sebenarnya membuat beberapa kesalahan, hanya FYI.
bev

Jawaban:

33

Tidak. Tidak ada yang mengerti apa yang terjadi di tingkat perangkat keras.

Sistem komputer seperti bawang - ada banyak lapisan, dan masing-masing tergantung pada lapisan di bawahnya untuk dukungan. Jika Anda adalah orang yang mengerjakan salah satu lapisan luar, Anda tidak perlu terlalu peduli dengan apa yang terjadi di tengah bawang. Dan itu hal yang baik, karena bagian tengah bawang selalu berubah. Selama lapisan atau lapisan yang mendukung lapisan khusus Anda terus terlihat sama dan mendukung lapisan Anda, Anda baik.

Tapi sekali lagi ...

Iya nih. Maksud saya, Anda tidak perlu memahami apa yang sebenarnya terjadi di dalam bawang, tetapi sangat membantu untuk memiliki model mental seperti apa bagian dalam bawang itu. Mungkin bukan bagian terdalam, di mana Anda memiliki gerbang yang terdiri dari transistor dan semacamnya, atau satu atau dua lapisan berikutnya, di mana Anda punya mikrokode, jam, unit pengodean kode dll. Lapisan berikutnya, bagaimanapun, adalah tempat Anda Sudah punya register, tumpukan, dan tumpukan. Ini adalah lapisan terdalam di mana Anda memiliki banyak pengaruh atas apa yang terjadi - kompiler menerjemahkan kode Anda menjadi instruksi yang dijalankan pada level ini, dan jika Anda mau, Anda biasanya dapat melangkah melalui instruksi ini dan mencari tahu apa yang sebenarnya "terjadi".

Kebanyakan programmer yang berpengalaman memiliki versi lapisan dongeng di kepala mereka. Mereka membantu Anda memahami apa yang dibicarakan oleh kompiler ketika ia memberi tahu Anda bahwa ada "pengecualian alamat tidak valid" atau "stack overflow error" atau sesuatu seperti itu.

Jika Anda tertarik, baca buku tentang arsitektur komputer. Bahkan tidak perlu menjadi buku yang sangat baru - komputer digital telah bekerja dengan cara yang kira-kira sama untuk waktu yang lama. Semakin banyak Anda belajar tentang bagian dalam bawang, semakin mengejutkan Anda bahwa semua hal ini bekerja sama sekali! Mempelajari (kira-kira) apa yang terjadi di lapisan bawah membuat pemrograman kurang misterius dan, entah bagaimana, lebih ajaib. Dan sungguh, lebih menyenangkan.

Hal lain yang mungkin Anda perhatikan adalah bawang yang tertanam. Eh, maksud saya sistem tertanam. Ada sejumlah platform tertanam yang cukup mudah digunakan: Arduino dan BASIC Stamp adalah dua contoh. Ini pada dasarnya adalah mikroprosesor kecil dengan banyak fitur bawaan. Anda dapat menganggapnya sebagai bawang dengan lapisan lebih sedikit daripada PC desktop biasa, jadi mungkin untuk mendapatkan pemahaman yang cukup menyeluruh tentang apa yang terjadi di seluruh sistem, dari perangkat keras hingga perangkat lunak.

Caleb
sumber
2
Terima kasih. Ini pada dasarnya menjawab pertanyaan saya. Saya seorang EE yang telah melakukan desain register, adders, multiplexer, dan level chip (yaitu level transistor), jadi saya mendapatkan level terendah (kecuali kita berbicara mekanika kuantum). Saya juga bisa menggunakan bahasa yang saya kenal dengan baik. Saya hanya memiliki celah besar di tingkat menengah (tumpukan, tumpukan), di mana Anda mengatakan kompiler melakukan tugasnya. Karena, seperti yang Anda katakan, saya ingin pengalaman pemrograman saya menjadi "kurang misterius dan, ..., lebih ajaib." sepertinya saya harus mempelajari level yang masih belum saya ketahui.
bev
@ Bev: Dalam hal ini, Anda benar-benar harus memeriksa platform seperti Arduino.
Caleb
maaf kusam, tapi saya memeriksa Arduino, dan saya tidak bisa benar-benar melihat bagaimana menggunakannya akan membantu saya memahami bagaimana kompiler memperlakukan pointer dan array secara berbeda. Apa yang tidak saya lihat?
bev
@ Bev: Jika Anda hanya ingin mengetahui bagaimana fungsi dipanggil, Anda mungkin dapat menghabiskan 30 menit membaca tentang itu dan dilakukan. Jika Anda ingin mendapatkan pemahaman yang lebih baik tentang bagaimana semuanya bekerja bersama, itu akan lebih mudah dengan sistem kecil. Ini adalah cara terbaik untuk mendapatkan seluruh bawang di kepala Anda sekaligus. AVR, keluarga chip yang menjadi basis Arduino, adalah sistem yang bagus, tujuan umum, mudah digunakan dengan set instruksi yang cukup kecil untuk dipelajari tanpa terlalu banyak kesulitan.
Caleb
Ah, baiklah. Halaman beranda sedikit keruh pada aspek produk mereka. Saya akan melihat lagi.
bev
10

Anda tidak berbicara tentang tingkat perangkat keras, Anda berbicara tentang apa yang sebenarnya dilakukan oleh kompiler dengan apa yang Anda perintahkan.

Anda tentu membutuhkan tingkat pemahaman ini untuk mencari tahu apa yang salah ketika itu tidak jelas, terutama ketika berhadapan dengan situasi menginjak-injak ingatan.

Loren Pechtel
sumber
Loren - Ya! Terima kasih atas kebenarannya yang sederhana. Sekarang saya perlu mencari cara terbaik untuk mempelajari apa yang dilakukan kompiler c ++ dengan tipe data mereka. BTW, sebagai EE, saya tahu bahwa itu bukan tingkat perangkat keras secara harfiah. Saya hanya tidak tahu apa yang Anda sebut sebagai geek CS. (Masih tidak dalam hal ini. Level kompiler?)
bev
BTW - menginjak memori?
bev
@ Bri: Anda baru saja membuktikan maksud saya di sini - jika Anda bahkan tidak tahu apa memori stomp adalah Anda akan memiliki waktu yang buruk menemukan bug karena satu. Memory stomp adalah ketika sesuatu menulis ke lokasi yang tidak seharusnya dan menghapus (menginjak) apa pun yang terjadi di sana. Jika Anda beruntung, apa pun yang Anda pukul segera menjadi vital dan setidaknya meledak. Jika Anda kurang beruntung, program terus berjalan dengan beberapa lubang di data itu.
Loren Pechtel
terimakasih atas klarifikasinya. Ini juga menunjukkan kepada saya seberapa banyak saya tidak tahu, karena sejauh yang saya tahu saya hanya menulis ke tumpukan atau tumpukan, tanpa kontrol yang lebih baik.
bev
@ Bri: Masalahnya muncul ketika Anda menulis di suatu tempat Anda tidak berpikir Anda sedang menulis. Anda memiliki sesuatu di stack dan membuat pointer ke sana. Anda meninggalkan rutinitas - item hilang, pointer tidak. Sekarang apa yang terjadi ketika Anda menulis ke pointer itu ?? Atau Anda memiliki array 100 item - apa yang terjadi ketika Anda menulis ke item # 200?
Loren Pechtel
6

Memahami Memori Program! = Memahami Perangkat Keras

Memahami Hierarki Memori == Memahami Perangkat Keras


Untuk menjawab pertanyaan umum Anda: Itu tergantung. Tidak ada salahnya untuk memahami perangkat keras, tetapi memahaminya tidak akan membantu dalam semua kasus.

Berdasarkan contoh Anda, Anda hanya perlu memahami lebih lanjut tentang bagaimana memori dibagi dan bagaimana itu diatur ketika Anda menjalankan suatu program. Memahami perangkat keras tidak akan membantu Anda dalam hal ini, karena memori (seperti yang terlihat oleh suatu program) bahkan tidak benar-benar mewakili perangkat keras berkat keajaiban memori virtual.

Jika Anda ingin tahu tentang masalah kinerja berdasarkan urutan di mana Anda mengakses memori, SEKARANG Anda akan mendapat manfaat dari memahami perangkat keras, hirarki memori, kehilangan cache, kesalahan halaman, dan semua kebaikan luar biasa indah yang berasal dari perangkat keras.

riwalk
sumber
Stargazer - Saya belum pada titik di mana saya bisa khawatir tentang masalah kinerja. Semoga, segera. Terima kasih atas komentar Anda.
bev
5

Jika Anda tidak memutuskan untuk belajar sedikit assembler, Anda mungkin harus belajar sesuatu seperti 6502 assembler pada Commodore 64 (ditiru, tentu saja), atau 68000 pada Amiga.

Anda dapat mengetahui tentang Commodore 64 di sini ...

http://thepiratebay.org/torrent/4609238/Tag3-Saal2-Slot16_00--ID2874-the_ultimate_commodore_64_talk-Main

Buku klasik segalanya yang perlu Anda ketahui adalah yang dijelaskan di sini ...

http://reprog.wordpress.com/2010/03/12/programming-books-part-3-programming-the-omodore-64/

Anda mungkin dapat menemukan pemindaian PDF jika Anda melihat-lihat.

IMO, 6502 lebih mudah dari Z80, dan 68000 lebih mudah dari 8086 - set instruksi yang lebih teratur dll.

Tetapi CPU hanya satu aspek dari perangkat keras. Juga, CPU modern adalah binatang yang sangat berbeda, dan ia melakukan hal-hal yang transparan bahkan dari sudut pandang kompiler - seperti menghadirkan ruang alamat virtual.

Keuntungan khusus dari 6502 pada C64 adalah bahwa tidak hanya CPU yang sederhana, tetapi ada beberapa yang sangat mudah untuk diretas juga. Saya dulu sangat senang bermain-main dengan chip musik SID.

Jadi - ini mungkin latihan yang bermanfaat jika Anda tidak menghabiskan terlalu banyak waktu untuk itu. Saya belajar 6502 assembler sebagai bahasa kedua saya ketika saya berusia sekitar 14 tahun, tepat setelah Commodore Basic. Tetapi sebagian besar mendapatkan model kerja yang sangat sederhana sehingga Anda dapat menambahkan ide-ide yang lebih canggih dengan minimal kesalahpahaman.

Beberapa hal berguna yang dapat Anda pelajari saat bekerja di assembler ...

  • Cara register CPU bekerja.
  • Cara kerja pengalamatan memori, termasuk tipuan.
  • Cara kerja tumpukan CPU.
  • Cara kerja logika bitwise.
  • Bagaimana CPU mengontrol perangkat I / O.
  • Bagaimana interupsi bekerja.

Satu alasan khusus yang saya sarankan adalah untuk mendapatkan intuisi yang lebih baik tentang cara langkah-langkah sederhana beroperasi sepenuhnya secara deterministik dan mekanis dan sepenuhnya tanpa kecerdasan atau akal sehat. Pada dasarnya membiasakan diri dengan model eksekusi imperatif dalam bentuknya yang paling murni dan keras kepala.

Namun, betapa bermanfaatnya mengetahui sebagian besar dari hal-hal itu sekarang, merupakan pertanyaan yang sulit.

Satu hal yang tidak akan Anda pelajari adalah bagaimana bermain dengan baik dengan hirarki memori. Mesin-mesin lama sebagian besar memiliki model memori sederhana tanpa lapisan cache dan tidak ada memori virtual. Anda juga tidak akan belajar banyak tentang konkurensi - mereka memang cara untuk mengatasinya, tetapi itu sebagian besar berarti gangguan. Anda tidak perlu khawatir tentang mutexes dll.

Terkadang, model mental tentang bagaimana hal-hal ini pernah bekerja, atau tentang bagaimana assembler bekerja, bahkan dapat menyesatkan. Misalnya, memikirkan pointer C sebagai alamat dapat menyebabkan masalah perilaku yang tidak ditentukan. AC pointer biasanya diimplementasikan sebagai integer yang berisi alamat, tetapi tidak ada jaminan bahwa itu sepenuhnya benar. Misalnya, pada beberapa platform aneh, pointer yang berbeda dapat menunjuk ke ruang alamat yang berbeda. Ini menjadi penting ketika Anda ingin melakukan aritmatika atau logika bitwise dengan dua petunjuk.

Kecuali Anda memiliki salah satu dari platform aneh itu, Anda mungkin tidak berpikir Anda peduli tentang itu - tetapi para kompiler hari ini lebih dan lebih cenderung mengeksploitasi perilaku standar yang tidak ditentukan untuk optimasi.

Jadi model mental arsitektur sistem dapat berguna, tetapi masih penting untuk kode ke spesifikasi bahasa., Bukan untuk model hipotetis yang mungkin tidak dihormati oleh bahasa dan platform Anda.

Akhirnya, banyak hal mental model yang berguna datang dari mendapatkan ide tentang bagaimana kompiler menghasilkan kode - dan pembuatan kode untuk bahasa modern sangat berbeda dari kompiler yang cukup sepele yang tersedia saat itu.

Ini adalah buku favorit saya untuk itu ...

http://dickgrune.com/Books/MCD_1st_Edition/

Seiring dengan hal-hal tentang parsing dan AST dll, itu mencakup pembuatan kode untuk berbagai paradigma bahasa - imperatif, OOP, fungsional, logika, paralel dan didistribusikan - dan juga untuk manajemen memori. Jika Anda ingin tahu bagaimana panggilan metode polimorfik bekerja tanpa terjebak dalam detail set instruksi CPU, buku seperti ini adalah teman Anda - dan ada edisi baru yang segera keluar.

Steve314
sumber
Steve - wow. Saya hampir kehabisan kata-kata dengan kelengkapan dan fokus jawaban Anda untuk pertanyaan saya. Terima kasih banyak telah meluangkan waktu untuk menulis semua ini. Saya pasti akan menerima saran Anda.
bev
1
Saya akan menyarankan bahwa assembler PDP-11 sedikit lebih baik untuk dipelajari daripada yang lainnya. Apa yang diajarkan semua yang lain adalah keterbatasan yang dipaksakan oleh sumber daya perangkat keras yang lebih terbatas, dan / atau oleh desain perangkat keras yang lebih terbatas dan pemikiran ke depan. Sesuatu seperti salah satu dari keluarga 8.051 yang terlalu umum mengajarkan betapa anehnya model pemrograman dapat menggunakan perangkat keras yang terbatas (di mana Steve menyebutkan ruang alamat yang berbeda, misalnya, ikut bermain).
Greg A. Woods
@ Greg - Saya tidak pernah bermain dengan PDP-11, saya rasa. Juga bukan 8.051 - Saya melakukan beberapa pekerjaan tertanam untuk sementara waktu, tapi itu menggunakan chip keluarga 8.096. Saya hanya melihat-lihat di sini - menarik. Saya mendengar tentang arsitektur Harvard sebelum beberapa waktu, tetapi saya tidak tahu ada sesuatu seperti ini yang sangat populer dan masih digunakan.
Steve314
4

Dua puluh tahun yang lalu itu penting, tetapi tidak begitu banyak sekarang - ada lebih banyak lapisan abstraksi antara perangkat lunak dan perangkat keras modern.

Sangat berguna untuk mengetahui hal-hal seperti membutuhkan banyak utas untuk mengambil keuntungan dari banyak inti atau bahwa menggunakan lebih banyak memori daripada yang ada pada sistem adalah hal yang buruk, tetapi di luar itu Anda tidak benar-benar membutuhkannya kecuali itu adalah tugas Anda untuk menulis abstraksi tersebut. lapisan.

Sisa pertanyaan Anda menunjukkan bahwa Anda mungkin lebih peduli dengan kompiler daripada perangkat keras, yang sedikit berbeda. Anda mungkin mengalami kasus di mana itu penting, tetapi ini cenderung sepele (rekursi tak terbatas tidak bekerja dengan baik) atau jenis tepi kasus di mana Anda bisa merasa baik tentang menyelesaikannya tetapi kemungkinan tidak akan pernah mengalami masalah yang sama lagi.

Tom Clarkson
sumber
Ya, Anda benar, saya lebih peduli dengan kompiler. Juga, terima kasih atas saran Anda tentang banyak utas, beberapa inti, dll. Ini baru saja masuk ke file catatan toLearn saya.
bev
@ bev multithreading mudah dipelajari, hanya jangan lakukan itu kecuali Anda benar-benar harus dan bahkan kemudian jangan lakukan itu. lebih banyak masalah daripada nilainya dalam pengalaman saya.
Skeith
@Skeith - terima kasih atas tipnya. Saya akan mengingatnya.
bev
4

Ini sangat membantu untuk mengetahui dan memahami abstraksi yang disajikan oleh perangkat keras, dan sedikit gagasan umum tentang bagaimana ilusi itu diciptakan - tetapi mencoba untuk benar-benar memahami bagaimana perangkat keras modern benar-benar bekerja adalah sejumlah besar pekerjaan yang darinya Anda kemungkinan besar hanya melihat pengembalian minimal.

Jika Anda akan memaafkan pengalihan kecil: ini mengingatkan saya pada sesuatu yang saya catat beberapa tahun yang lalu. Puluhan tahun yang lalu (hingga akhir 1970-an atau lebih), kebanyakan orang berpikir komputer adalah satu langkah pendek dari magis - hampir tidak terpengaruh oleh hukum fisika, mampu segala macam hal yang masuk akal, dan sebagainya. Pada saat itu, saya menghabiskan cukup banyak waktu untuk mencoba (kebanyakan tidak berhasil) untuk meyakinkan orang bahwa tidak, mereka bukan sihir. Mereka benar-benar mesin biasa yang melakukan sejumlah hal dengan sangat cepat dan dapat diandalkan, tetapi sebaliknya sangat biasa.

Saat ini, pandangan kebanyakan orang tentang komputer telah berubah. Mereka sekarang cukup biasa - sampai-sampai beberapa orang yang sangat biasa memiliki pemahaman praktis tentang mereka. Sebagai contoh, beberapa waktu yang lalu ketika saya makan malam, saya melihat / mendengar seorang pelayan dan pelayan sedang istirahat mendiskusikan apa yang harus dia dapatkan di komputer barunya. Nasihat yang diberikannya sepenuhnya masuk akal dan realistis.

Pandangan saya tentang komputer telah berubah juga. Saya telah pergi ke Hot Chips, dan sebelum itu Forum Microprocessor akan kembali ke pertengahan 1990-an. Saya mungkin tahu lebih banyak tentang perangkat keras mikroprosesor daripada setidaknya 99% programmer - dan mengetahui apa yang saya lakukan, saya akan mengatakan ini: mereka tidak biasa lagi. Mereka melakukan hampir melanggar hukum fisika. Saya telah melakukan banyak pengujian tingkat rendah dan saya dapat mengatakan ini dengan pasti: melewati ilusi yang dibuat oleh CPU dan ke tingkat menunjukkan bagaimana perangkat keras benar-benar bekerja seringkali sangat sulit. Saya berharap saya dapat memposting gambar dari salah satu pengaturan kami dengan komputer yang terkubur di bawah kabel dari tidak kurang dari 4 analisa logika hanya untuk mengukur dengan benar satu aspek bagaimana caching bekerja pada CPU modern (belum lagi beberapa pemrograman yang benar-benar rewel untuk memastikan bahwa apa yang kami ukur adalah persis apa yang CPU lakukan, dan tidak ada yang lain).

Jerry Coffin
sumber
Jerry - terima kasih atas komentar Anda. Menjadi EE, saya lebih nyaman dengan level transistor daripada beberapa level abstraksi yang lebih tinggi. Saya benar-benar hanya ingin tahu apa yang perlu saya ketahui untuk menjadi programmer C ++ yang baik.
bev
Gambar itu terdengar menarik. Mengapa Anda tidak dapat mempostingnya?
Mason Wheeler
@ Bri: Anda tidak benar-benar perlu tahu apa pun di level transistor untuk menjadi programmer yang baik. Abstraksi-abstraksi itu ada karena suatu alasan, dan Anda hampir selalu dapat menganggap apa pun pada tingkat abstraksi di bawah kode mesin / perakitan sama sekali tidak relevan dan hanya menganggapnya berfungsi.
Mason Wheeler
@MasonWheeler: Saya membawanya ke tempat saya dulu bekerja, tetapi karena saya tidak bekerja di sana lagi, mendapatkan akses ke sana mungkin akan sedikit lebih sulit (mungkin bukan tidak mungkin - saya berhenti dengan baik, tetapi meskipun demikian. ..)
Jerry Coffin
1

Bahasa yang berbeda bekerja pada tingkat abstraksi yang berbeda dari perangkat keras. C dan C ++ adalah level yang sangat rendah. Bahasa scripting, di sisi lain, mengharuskan Anda untuk tahu lebih sedikit tentang detail yang mendasarinya.

Namun, saya masih akan mengatakan bahwa dalam semua kasus, semakin banyak Anda tahu, semakin baik seorang programmer. Bagian dari pemrograman adalah mampu menyulap berbagai tingkat abstraksi pada saat yang bersamaan.

Jika Anda memprogram dalam C ++, Anda harus memiliki pemahaman yang cukup baik tentang cara kerja CPU modern, setidaknya pada tingkat abstraksi tempat kompiler bekerja. (Ada hal-hal yang terjadi di dalam CPU yang transparan untuk kompiler juga).

Scott Whitlock
sumber
Scott - dengan "pemahaman yang cukup bagus tentang bagaimana CPU modern bekerja .." maksud Anda bagaimana logika digital bekerja (misalnya bagaimana peta karnaugh, tabel kebenaran, DAN / ATAU / NOR / XOR bekerja)? atau maksud Anda sumber daya apa yang digunakan kompiler secara langsung (yaitu register)?
bev
Mengetahui lebih banyak itu baik. Namun, trik sebenarnya adalah mengetahui "lebih" seperti apa yang akan memberikan keuntungan terbesar bagi uang Anda. Mengetahui waktu instruksi, misalnya, tidak akan banyak digunakan ketika hampir mustahil untuk memprediksi instruksi apa yang akan digunakan oleh kompiler Anda. Mempelajari cara menggunakan profiler mungkin akan memberikan rasio biaya / manfaat yang jauh lebih baik.
Steve314
1
@ Bev - Tidak, saya pikir Anda tidak perlu turun ke tingkat gerbang. Jika Anda hanya tahu arsitektur dasar (memori, bus, CPU), cara memuat instruksi, menjalankannya, menyimpan hasilnya, dll., Anda mungkin baik-baik saja. Anda juga perlu memahami bagaimana kompiler menjabarkan ruang memori program termasuk bagaimana ia menggunakan stack dan heap.
Scott Whitlock
@ScottWhitlock - Terima kasih - ini hanya semacam rekomendasi spesifik yang saya cari.
bev
0

Saya ingin menambahkan poin tentang desain menyeluruh bahasa tingkat tinggi seperti C.

Secara umum saya pikir aman untuk mengatakan bahwa bahasa-bahasa seperti itu dapat dipandang sebagai penerapan mesin abstrak, dan memang itulah yang dikatakan Dennis Ritchie sendiri tentang cara kerja C dan bagaimana desain khusus mesin abstrak C membuatnya menjadi bahasa yang lebih portabel. Karena itu memiliki pemahaman tentang arsitektur komputer dan fungsi tingkat mesin, dapat sangat membantu dalam memahami mesin abstrak bahasa.

Makalah DMR Portabilitas Program C dan Sistem UNIX adalah yang pertama kali saya ingat untuk membahas model mesin (abstrak) untuk C.

Saya pikir makalah DMR tentang sejarah dan pengembangan C juga sangat berguna dalam menunjukkan bagaimana perangkat keras nyata mempengaruhi desain bahasa, dan mungkin juga merupakan contoh desain bahasa pemrograman awal: Pengembangan Bahasa C

Greg A. Woods
sumber
Karena Anda baru di sini, Anda sepertinya berpikir ini adalah sebuah forum, yang jelas bukan. Jawaban Anda atas sebuah pertanyaan seharusnya tidak menjadi poin yang Anda tambahkan, yang harus diturunkan ke komentar, dan jawaban harus berusaha menjadi jawaban yang komprehensif langsung ke pertanyaan. Yang mengatakan Anda membuat poin yang baik dan ini sangat berharga pada informasi topik, mungkin jika Anda bisa memasukkan beberapa baris dalam jawaban itu pertanyaan langsung bersama dengan penjelasan ini akan bagus. Info keren yang Anda bagikan di sini. Selamat Datang di Programmer!
Jimmy Hoffa
komentar tidak berversi, dan tidak permanen, dan karenanya tidak berguna untuk menambah satu set jawaban. Sebagian besar poster juga cenderung mengabaikan penggunaan komentar untuk memperbarui jawaban mereka, dan sebagian besar jawaban tidak ditandai sebagai jawaban "komunitas wiki" dan karenanya tidak dapat diedit oleh orang lain sedemikian rupa untuk mempertahankan beberapa atribusi kepada kontributor berikutnya . Selain itu, pertanyaan khusus ini telah memulai diskusi sejati, dan suka atau tidak seperti itulah beberapa hal ini terjadi. Mencoba untuk memaksa setiap kontribusi menjadi satu cetakan adalah kegagalan utama dari konsep stackexchange.
Greg A. Woods
dan, btw, saya benar-benar menjawab, albiet secara implisit, satu pertanyaan sebenarnya dari OP: orang harus memiliki cukup pemahaman tentang perangkat keras untuk dapat memodelkan mesin abstrak pada inti desain bahasa.
Greg A. Woods