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

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?

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.

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.

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.

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.

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.

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).

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).

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