Mengapa pengidentifikasi pendek samar masih sangat umum dalam pemrograman tingkat rendah?


64

Dulu ada alasan yang sangat baik untuk menjaga instruksi / daftar nama pendek. Alasan itu tidak lagi berlaku, tetapi nama samar pendek masih sangat umum dalam pemrograman tingkat rendah.

Kenapa ini? Apakah hanya karena kebiasaan lama sulit dihilangkan, atau adakah alasan yang lebih baik?

Sebagai contoh:

  • Atmel ATMEGA32U2 (2010?): TIFR1(Bukan TimerCounter1InterruptFlag), ICR1H(bukan InputCapture1High), DDRB(bukan DataDirectionPortB), dll.
  • Set instruksi NET CLR (2002): bge.s(bukan branch-if-greater-or-equal.short), dll.

Bukankah lebih lama, nama non-samar lebih mudah untuk digunakan?


Saat menjawab dan memberikan suara, harap pertimbangkan yang berikut ini. Banyak penjelasan yang mungkin disarankan di sini berlaku sama untuk pemrograman tingkat tinggi, namun konsensus, pada umumnya, adalah menggunakan nama-nama non-rahasia yang terdiri dari satu atau dua kata (akronim yang dipahami secara umum dikecualikan).

Juga, jika argumen utama Anda adalah tentang ruang fisik pada diagram kertas , harap pertimbangkan bahwa ini benar-benar tidak berlaku untuk bahasa assembly atau CIL, plus saya akan sangat menghargai jika Anda menunjukkan kepada saya diagram di mana nama-nama singkat cocok tetapi yang mudah dibaca membuat diagram lebih buruk . Dari pengalaman pribadi di perusahaan semikonduktor yang luar biasa, nama yang dapat dibaca cocok dengan baik, dan menghasilkan diagram yang lebih mudah dibaca.

Apa hal inti yang berbeda tentang pemrograman tingkat rendah sebagai lawan dari bahasa tingkat tinggi yang membuat nama samar samar diinginkan dalam pemrograman tingkat rendah tetapi tidak pemrograman tingkat tinggi?


82
Jawaban: Untuk membuatnya terasa seperti Anda memprogram dalam bahasa tingkat rendah.
Thomas Eding

5
Cryptic bersifat relatif. JSRadalah tiga kali lebih lama dari opcode yang diwakilinya ( $20pada 6502) dan jauh lebih mudah dipahami sekilas.
Blrfl

4
Saya sedikit kecewa, karena jawaban yang benar ada di sana, tetapi jawaban itu jelas bukan jawaban yang diterima. Dengan diagram sirkuit dan interupsi seperti itu biasanya dinamai sesuai garis yang terkait dengannya, dan pada diagram sirkuit Anda tidak ingin verbose, itu bukan praktik yang baik atau praktis. Kedua, karena Anda tidak menyukai jawabannya tidak berarti jawabannya salah.
Jeff Langemeier

4
@gnat: Coba set Accumulator32 to BaseIndex32? Cukup memperluas singkatan tradisional bukanlah satu-satunya cara untuk membuat sesuatu lebih mudah dibaca.
Timwi

1
"Jika argumen utama Anda adalah tentang ruang fisik pada diagram kertas", tidak itu tentang fakta bahwa penamaan yang baik mempertimbangkan hal-hal lain selain hanya kejelasan nama (saya berikan beberapa jawaban, diagram - termasuk yang digambar di papan tulis - hanyalah salah satu dari hal-hal lain ini) dan klarifikasi adalah hal yang relatif (keakraban cenderung membantu kejelasan apapun pilihannya misalnya).
Pemrogram

Jawaban:


106

Alasan perangkat lunak menggunakan nama-nama itu adalah karena lembar data menggunakan nama-nama itu. Karena kode pada tingkat itu sangat sulit untuk dipahami tanpa lembar data, membuat nama variabel yang tidak dapat Anda cari sangat tidak membantu.

Itu memunculkan pertanyaan mengapa lembar data menggunakan nama pendek. Itu mungkin karena Anda sering perlu menyajikan nama-nama dalam tabel seperti ini di mana Anda tidak memiliki ruang untuk pengidentifikasi 25 karakter:

Tabel TIFR1 dari lembar data

Juga, hal-hal seperti skema, pin diagram, dan PCB silkscreens sering sangat sempit untuk ruang.


7
Juga, jawaban ini tidak benar-benar membahas sisi perangkat lunak murni, misalnya CLR, JVM, x86, dll. :)
Timwi

12
@romkyns: Ini sedikit lebih jelas mengapa mereka menggunakan nama pendek ini ketika Anda benar-benar membaca lembar data ini. Lembar data untuk mikrokontroler yang saya miliki adalah sekitar 500 halaman bahkan ketika menggunakan nama-nama pendek di seluruh . Lebar tabel akan menjangkau beberapa halaman / layar jika kita menggunakan nama yang lebih panjang, membuatnya sangat tidak nyaman untuk menggunakan referensi.
Dalam silico

27
@romkyns: Nama yang lebih panjang sama-sama dapat dicari, tetapi mereka "bukan asli". Jika Anda mendengarkan insinyur yang disematkan, mereka sebenarnya mengatakan "tiffer zero", bukan "flag interrupt timer zero". Saya ragu bahwa pengembang web memperluas HTTP, HTML, atau JSON dalam nama metode mereka.
TMN

6
@KarlBielefeldt er, apa? :) Jelas saya tidak akan menemukannya di datasheet saat ini karena mereka menggunakan nama pendek saja. Itu tidak mendukung klaim bahwa nama-nama pendek lebih mudah dicari dalam ...
Roman Starkov

5
Bukan hanya lembar data yang dibatasi oleh ruang, tapi juga skemanya. Semua komponen logis tersebut memiliki arahan yang perlu dihubungkan ke komponen lain. "TimerCounter1InteruptFlag.clear" tidak cocok di atas representasi kawat kecil hampir juga "TCIF.C"
AShelly

60

Hukum Zipf

Anda sendiri dapat mengamati dengan melihat pada teks ini bahwa panjang kata dan frekuensi penggunaan, secara umum, berhubungan terbalik. Kata-kata yang digunakan sangat sering, seperti it, a, but, you, dan andsangat pendek, sementara kata-kata yang kurang sering digunakan seperti observe, comprehension, dan verbositylebih panjang. Hubungan yang diamati antara frekuensi dan panjang ini disebut Hukum Zipf .

Jumlah instruksi dalam set instruksi untuk mikroprosesor yang diberikan biasanya nomor dalam puluhan atau ratusan. Sebagai contoh, set instruksi Atmel AVR tampaknya berisi sekitar seratus instruksi berbeda (saya tidak menghitung), tetapi banyak dari mereka adalah variasi pada tema umum dan memiliki mnemonik yang sangat mirip. Sebagai contoh, instruksi multiplikasi termasuk MUL, MUL, MULSU, FMUL, FMULS, dan FMULSU. Anda tidak harus melihat daftar instruksi untuk waktu yang lama sebelum Anda mendapatkan ide umum bahwa instruksi yang dimulai dengan "BR" adalah cabang, instruksi yang dimulai dengan "LD" adalah beban, dll. Hal yang sama berlaku untuk variabel: bahkan prosesor yang kompleks hanya menyediakan sejumlah tempat terbatas untuk menyimpan nilai: register kondisi, register tujuan umum, dll.

Karena ada begitu sedikit instruksi, dan karena nama yang panjang membutuhkan waktu lebih lama untuk dibaca, masuk akal untuk memberi mereka nama pendek. Sebaliknya, bahasa tingkat yang lebih tinggi memungkinkan pemrogram untuk membuat sejumlah besar fungsi, metode, kelas, variabel, dan sebagainya. Masing-masing akan digunakan jauh lebih jarang daripada kebanyakan instruksi perakitan, dan lebih lama, nama yang lebih deskriptif semakin penting untuk memberi pembaca (dan penulis) informasi yang cukup untuk memahami apa itu dan apa yang mereka lakukan.

Selain itu, set instruksi untuk prosesor yang berbeda sering menggunakan nama yang mirip untuk operasi yang sama. Sebagian besar set instruksi termasuk operasi untuk ADD, MUL, SUB, LD, ST, BR, NOP, dan jika mereka tidak menggunakan nama-nama persis mereka biasanya menggunakan nama yang sangat dekat. Setelah Anda mempelajari mnemonik untuk satu set instruksi, tidak perlu waktu lama untuk beradaptasi dengan set instruksi untuk perangkat lain. Jadi nama-nama yang mungkin tampak "samar" kepada Anda adalah tentang akrab sebagai kata-kata seperti and, or, dan notuntuk programmer yang terampil dalam seni pemrograman tingkat rendah. Saya pikir sebagian besar orang yang bekerja di tingkat majelis akan memberi tahu Anda bahwa belajar membaca kode bukanlah salah satu tantangan besar dalam pemrograman tingkat rendah.


2
terima kasih Caleb! Bagi saya, jawaban yang luar biasa ini menyelamatkan sebuah pertanyaan yang entah bagaimana berhasil mengumpulkan empat penilaian nilai dalam satu judul: "samar", "pendek", "masih", "sangat umum"
nyamuk

1
Terima kasih, @gnat, atas komentar dan bonus murah hati Anda.
Caleb

37

Secara umum

Kualitas penamaan bukan hanya tentang memiliki nama deskriptif tetapi juga harus mempertimbangkan aspek-aspek lain, dan itu mengarah pada rekomendasi seperti:

  • semakin global cakupannya, semakin deskriptif namanya
  • semakin sering digunakan, semakin pendek nama seharusnya
  • nama yang sama harus digunakan dalam semua konteks untuk hal yang sama
  • hal yang berbeda harus memiliki nama yang berbeda walaupun konteksnya berbeda
  • variasi harus mudah dideteksi
  • ...

Perhatikan bahwa rekomendasi ini saling bertentangan.

Instruksi mnemonik

Sebagai programmer bahasa assembly, menggunakan short-branch-if-greater-or-equalfor bge.smemberi saya kesan yang sama daripada ketika saya melihat, sebagai programmer Algol melakukan geometri komputasi, SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSbukan dx := p2.x - p1.x. Saya hanya tidak setuju bahwa yang pertama lebih mudah dibaca dalam konteks yang saya pedulikan.

Daftarkan nama

Anda memilih nama resmi dari dokumentasi. Dokumentasi mengambil nama dari desain. Desain menggunakan banyak format grafis di mana nama yang panjang tidak memadai dan tim desain akan hidup dengan nama-nama itu selama berbulan-bulan, jika tidak bertahun-tahun. Untuk kedua alasan, mereka tidak akan menggunakan "Bendera interupsi penghitung waktu pertama", mereka akan menyingkatnya dalam skema mereka serta ketika mereka berbicara. Mereka mengetahuinya dan mereka menggunakan singkatan sistematis seperti TIFR1sehingga ada sedikit kemungkinan kebingungan. Satu hal di sini adalah bahwa TIFR1itu bukan singkatan acak, itu adalah hasil dari skema penamaan.


4
Apakah TIFR1benar-benar skema penamaan yang lebih baik daripada itu InterruptFlag1, atau IptFlag1jika Anda benar-benar harus pendek?
Timwi

4
@Timwi, InterruptFlagdan IptFlaglebih baik daripada IFdengan cara yang sama EnumerableInterfacedan ItfcEnumerablelebih baik daripada IEnumerable.
Pemrogram

@AProgrammer: Saya menganggap jawaban Anda dan komentar Anda yang terbaik dan saya akan menandainya sebagai diterima jika saya bisa. Mereka yang percaya bahwa hanya batasan fisik yang menentukan nama pendek yang salah. Diskusi ini akan menarik untuk Anda: 37signals.com/svn/posts/…
alpav

5
@alpav Apakah Anda menyadari bahwa tautan Anda menentang apa yang dikatakan jawaban ini? Jika ada, itu sepenuhnya mendukung InterruptFlag1untuk alasan kejelasan yang lebih baik.
Roman Starkov

24

Terlepas dari alasan "kebiasaan lama", kode Legacy yang ditulis 30 tahun yang lalu dan masih digunakan sangat umum. Terlepas dari apa yang dipikirkan oleh beberapa orang yang kurang berpengalaman, refactoring sistem ini sehingga mereka terlihat cantik datang dengan biaya yang sangat tinggi untuk keuntungan kecil dan tidak layak secara komersial.

Sistem tertanam yang dekat dengan perangkat keras - dan mengakses register, cenderung menggunakan label yang sama atau serupa dengan yang digunakan dalam lembar data Perangkat Keras, untuk alasan yang sangat baik. Jika register disebut XYZZY1 dalam lembar data perangkat keras, masuk akal Variabel yang mewakili kemungkinan XYZZY1, atau jika programmer sedang bersenang-senang, RegXYZZY1.

Sejauh ini bge.s, ini mirip dengan assembler - untuk beberapa orang yang perlu mengetahuinya nama yang lebih panjang kurang dapat dibaca. Jika Anda tidak dapat mengarahkan Anda bge.sdan berpikir branch-if-greater-or-equal.shortakan membuat perbedaan - Anda hanya bermain dengan CLR dan tidak mengetahuinya.

Alasan lain Anda akan melihat nama variabel pendek adalah karena kami menyebarkan singkatan dalam domain yang ditargetkan oleh perangkat lunak.

Singkatnya - diharapkan nama variabel pendek yang mencerminkan pengaruh eksternal seperti norma industri dan lembar data perangkat keras. Nama variabel pendek yang bersifat internal untuk perangkat lunak biasanya kurang diinginkan.


Jika saya mengerti argumen yang Anda gunakan untuk membela "bge.s", TIFR1apakah lebih mudah dibaca oleh mereka yang perlu mengetahuinya, bukan TimerCounter1InterruptFlag?
Roman Starkov

2
@romkyns: Tentu saja - dalam hal ini kurang lebih .... Tidak seperti CNTR yang bisa berarti "Counter", "Control", "Can Not Trace Route" dll, T1FR1 Arti yang didefinisikan dengan tepat.
mattnz

"Jika Anda tidak dapat membuat Anda berkeliling bge.s dan berpikir cabang-jika-lebih besar atau sama. Singkatnya akan membuat perbedaan - Anda hanya bermain dengan CLR dan tidak mengetahuinya." Saya tidak tahu tentang itu. Saya mengerti perakitan x86 dengan cukup baik, tetapi setiap kali saya menulis satu loop, saya harus mencari tahu apa semua j?instruksi yang dimaksud . Memiliki instruksi yang lebih jelas namanya pasti akan membantu saya. Tapi mungkin aku pengecualian daripada aturannya. Saya kesulitan mengingat detail yang sepele.
Cody Gray

11

Ada begitu banyak ide berbeda di sini. Saya tidak bisa menerima salah satu jawaban yang ada sebagai yang jawabannya: pertama, ada kemungkinan banyak faktor yang berkontribusi terhadap ini, dan kedua, saya tidak mungkin tahu mana yang paling signifikan.

Jadi, inilah ringkasan jawaban yang diposting oleh orang lain di sini. Saya memposting ini sebagai CW dan niat saya adalah untuk akhirnya menandainya diterima. Harap edit jika saya melewatkan sesuatu. Saya mencoba untuk mengulangi setiap ide untuk mengungkapkannya dengan singkat namun jelas.

Jadi mengapa pengidentifikasi pendek samar begitu umum dalam pemrograman tingkat rendah?

  • Karena banyak dari mereka cukup umum di domain masing-masing untuk menjamin nama yang sangat pendek. Ini memperburuk kurva belajar, tetapi merupakan tradeoff yang berharga mengingat frekuensi penggunaannya.
  • Karena biasanya ada satu set kecil kemungkinan yang diperbaiki (programmer tidak dapat menambah set).
  • Karena keterbacaan adalah masalah kebiasaan dan praktik. branch-if-greater-than-or-equal.shortadalah awalnya lebih mudah dibaca daripada bge.s, tetapi dengan beberapa latihan situasi menjadi terbalik.
  • Karena mereka sering harus diketik secara penuh, dengan tangan, karena bahasa tingkat rendah sering tidak disertai dengan IDE yang kuat yang memiliki pelengkapan otomatis yang baik, atau a / c tidak dapat diandalkan.
  • Karena kadang-kadang diinginkan untuk mengemas banyak informasi ke dalam pengidentifikasi, dan nama yang dapat dibaca akan terlalu panjang bahkan oleh standar tingkat tinggi.
  • Karena seperti itulah lingkungan tingkat rendah secara historis. Menghentikan kebiasaan membutuhkan upaya sadar, berisiko mengganggu orang-orang yang menyukai cara lama, dan harus dibenarkan sebagai orang yang berharga. Tetap dengan cara yang mapan adalah "default".
  • Karena banyak dari mereka berasal dari tempat lain, seperti skema dan lembar data. Mereka, pada gilirannya, dipengaruhi oleh kendala ruang.
  • Karena orang-orang yang bertanggung jawab atas penamaan hal-hal bahkan tidak pernah dianggap mudah dibaca, atau tidak menyadari bahwa mereka menciptakan masalah, atau malas.
  • Karena dalam beberapa kasus nama-nama telah menjadi bagian dari protokol untuk pertukaran data, seperti penggunaan bahasa assembly sebagai representasi perantara oleh beberapa kompiler.
  • Karena gaya ini langsung dikenali sebagai level rendah dan dengan demikian terlihat keren untuk Geeks.

Saya pribadi merasa bahwa beberapa di antaranya tidak benar-benar berkontribusi pada alasan mengapa sistem yang baru dikembangkan akan memilih gaya penamaan ini, tetapi saya merasa akan salah untuk menyaring beberapa ide dalam jenis jawaban ini.


10

Aku akan melemparkan topiku ke dalam kekacauan ini.

Konvensi dan standar pengkodean tingkat tinggi tidak sama dengan standar dan praktik pengkodean tingkat rendah. Sayangnya, sebagian besar dari mereka adalah peninggalan dari kode lama dan proses pemikiran lama.

Namun, beberapa di antaranya memang memiliki tujuan. Tentu BranchGreaterThan akan jauh lebih mudah dibaca daripada BGT , tetapi ada konvensi di sana sekarang, itu adalah instruksi dan karena itu telah mendapatkan sedikit daya tarik dalam 30 tahun terakhir digunakan sebagai standar. Mengapa mereka mulai dengan itu, mungkin beberapa batas lebar karakter acak untuk instruksi, variabel dan semacamnya; mengapa mereka menyimpannya, itu standar. Standar ini sama dengan menggunakan int sebagai pengenal, akan lebih mudah dibaca untuk menggunakan Integer dalam semua kasus, tetapi apakah perlu bagi siapa saja yang telah memprogram lebih dari beberapa minggu ... tidak. Mengapa? Karena ini adalah praktik standar.

Kedua, seperti yang saya katakan dalam komentar saya, banyak interupsi dinamai INTG1 dan nama-nama samar lainnya, ini melayani tujuan juga. Dalam diagram sirkuit, itu BUKAN konvensi yang baik untuk memberi nama baris Anda dan secara lisan itu mengacaukan diagram dan merusak keterbacaan. Semua verboseness ditangani dalam dokumentasi. Dan karena semua diagram pengkabelan / sirkuit memiliki nama-nama pendek untuk garis interupsi, interupsi itu sendiri juga mendapatkan nama yang sama untuk menjaga konsistensi bagi desainer yang disematkan dari diagram sirkuit hingga kode untuk memprogramnya.

Seorang desainer memiliki kontrol atas hal ini, tetapi seperti bidang / bahasa baru, ada konvensi yang mengikuti dari perangkat keras ke perangkat keras, dan dengan demikian harus tetap sama di setiap bahasa assembly. Saya dapat melihat potongan perakitan dan bisa mendapatkan inti dari kode tanpa menggunakan set instruksi karena mereka tetap pada konvensi, LDA atau beberapa hubungan dengannya mungkin memuat register. MV mungkin memindahkan sesuatu dari suatu tempat ke tempat lain. di tempat lain, ini bukan tentang apa yang Anda anggap baik atau merupakan praktik tingkat tinggi, itu adalah bahasa tersendiri dan karena itu memiliki standar sendiri dan berarti bahwa Anda sebagai perancang harus mengikuti, ini sering tidak hampir sewenang-wenang seperti mereka sepertinya.

Saya akan meninggalkan Anda dengan ini: Meminta komunitas tertanam untuk menggunakan praktik tingkat tinggi verbose adalah seperti meminta ahli kimia untuk selalu menulis senyawa kimia. Ahli kimia menulisnya singkat untuk diri mereka sendiri dan siapa pun di lapangan akan memahaminya, tetapi mungkin butuh pendatang baru sedikit waktu untuk menyesuaikan diri.


1
Saya merasa bahwa "kami akan menggunakan nama samar karena itulah yang membuat pemrograman tingkat rendah terasa seperti itu" dan "kami akan menggunakan nama samar karena itu adalah konvensi untuk pemrograman tingkat rendah" hampir sama, jadi +1 dari saya dan saya akan berpikir tentang menerima ini sebagai varian yang tidak terlalu meradang dari yang saya terima pada awalnya .
Roman Starkov

6
+1 untuk referensi ahli kimia karena menghasilkan analogi yang baik untuk berbagai bidang pemrograman.

4
+1 Saya juga tidak pernah mengerti mengapa orang menggunakan nama pendek dan samar seperti "air" jika ada "DiHydrogenOxyde" yang jauh lebih mudah dibaca
Ingo

6

Salah satu alasan mereka menggunakan pengidentifikasi pendek samar adalah karena mereka tidak samar untuk pengembang. Anda harus menyadari bahwa mereka bekerja dengannya setiap hari dan nama-nama itu benar-benar nama domain. Jadi mereka hafal apa sebenarnya arti TIFR1.

Jika pengembang baru datang ke tim, ia harus membaca lembar data (seperti yang dijelaskan oleh @KarlBielefeldt) sehingga mereka akan merasa nyaman dengan itu.

Saya percaya pertanyaan Anda menggunakan contoh buruk karena memang pada kode sumber semacam itu Anda biasanya melihat banyak pengidentifikasi crypt yang tidak perlu untuk hal-hal non-domain.

Saya akan mengatakan sebagian besar mereka melakukan itu karena kebiasaan buruk yang ada ketika kompiler tidak secara otomatis melengkapi semua yang Anda ketik.


5

Ringkasan

Initialism adalah fenomena yang meluas di banyak kalangan teknis dan non-teknis. Karena itu tidak terbatas pada pemrograman tingkat rendah. Untuk diskusi umum, lihat artikel Wikipedia tentang Akronim . Jawaban saya khusus untuk pemrograman tingkat rendah.

Penyebab nama samar:

  1. Instruksi tingkat rendah sangat diketik
  2. Perlu mengemas banyak jenis informasi ke dalam nama instruksi tingkat rendah
  3. Secara historis, kode satu karakter disukai untuk mengemas informasi jenis.

Solusi dan kelemahannya:

  1. Ada skema penamaan tingkat rendah modern yang lebih konsisten daripada yang historis.
    • LLVM
  2. Namun, kebutuhan untuk mengemas banyak jenis informasi masih ada.
    • Dengan demikian, singkatan samar masih dapat ditemukan di mana-mana.
  3. Pembacaan garis-ke-garis yang ditingkatkan akan membantu programmer tingkat rendah pemula mengambil bahasa lebih cepat, tetapi tidak akan membantu memahami potongan besar kode tingkat rendah.

Jawaban penuh

(A) Nama yang lebih panjang dimungkinkan. Sebagai contoh, nama-nama intrinsik C ++ SSE2 rata-rata 12 karakter dibandingkan dengan 7 karakter dalam majelis mnemonik. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) Pertanyaan kemudian beralih ke: Berapa lama / non-samar seseorang perlu dapatkan dari instruksi tingkat rendah?

(C) Sekarang kami menganalisis komposisi skema penamaan tersebut. Berikut ini adalah dua skema penamaan untuk instruksi tingkat rendah yang sama :

  • Skema penamaan # 1: CVTSI2SD
  • Skema penamaan # 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) Instruksi tingkat rendah selalu diketik dengan kuat. Tidak boleh ada ambiguitas, inferensi jenis, konversi tipe otomatis, atau kelebihan muatan (penggunaan kembali nama instruksi berarti operasi yang serupa tetapi tidak setara).

(C.2) Setiap instruksi tingkat rendah harus menyandikan banyak jenis informasi ke dalam namanya. Contoh informasi:

  • Keluarga Arsitektur
  • Operasi
  • Argumen (Input) dan Output
  • Jenis (Integer Masuk, Integer Tanpa Tanda, Float)
  • Presisi (Lebar Bit)

(C.3) Jika setiap informasi dijabarkan, program akan lebih bertele-tele.

(C.4) Skema pengkodean tipe yang digunakan oleh berbagai vendor memiliki akar sejarah yang panjang. Sebagai contoh, dalam set instruksi x86:

  • B berarti byte (8-bit)
  • W berarti kata (16-bit)
  • D berarti dword "kata ganda" (32-bit)
  • Q berarti qword "quad-word" (64-bit)
  • DQ berarti dqword "double-quad-word" (128-bit)

Referensi sejarah ini tidak memiliki makna modern apa pun, tetapi masih ada. Skema yang lebih konsisten akan memasukkan nilai bit-width (8, 16, 32, 64, 128) ke dalam namanya.

Sebaliknya, LLVM adalah langkah yang tepat dalam arah konsistensi dalam instruksi tingkat rendah: http://llvm.org/docs/LangRef.html#functions

(D) Terlepas dari skema penamaan instruksi, program tingkat rendah sudah verbose dan sulit dimengerti karena mereka fokus pada detail menit pelaksanaan. Mengubah skema penamaan instruksi akan meningkatkan keterbacaan pada level line-to-line, tetapi tidak akan menghilangkan kesulitan memahami operasi dari sepotong kode besar.


1
Keterbacaan garis-ke-garis yang diperbaiki tentu akan berdampak pada memahami semuanya, tetapi penamaan saja tidak bisa membuatnya sepele, tentu saja.
Roman Starkov

3
Juga, agak di luar topik, tetapi CVTSI2SDtidak membawa informasi lebih dari ConvertDword2Doubleatau ConvInt32ToFloat64, tetapi yang terakhir, sementara lebih lama, langsung dikenali, sedangkan yang pertama harus diuraikan ...
Roman Starkov

2

Manusia kadang-kadang membaca dan menulis majelis, dan sebagian besar itu hanyalah protokol komunikasi. Yaitu, ini paling sering digunakan sebagai representasi berbasis teks serial antara antara kompiler dan assembler. Semakin jelas representasi ini, semakin banyak overhead yang tidak perlu dalam protokol ini.

Dalam kasus opcode dan mendaftarkan nama, nama panjang sebenarnya membahayakan keterbacaan. Mnemonik pendek lebih baik untuk protokol komunikasi (antara kompiler dan assember), dan bahasa assembly adalah protokol komunikasi hampir sepanjang waktu. Mnemonik pendek lebih baik untuk programmer, karena kode kompiler lebih mudah dibaca.


Jika Anda perlu menghemat ruang, cukup gzip! ... Jika Anda tidak memerlukan overhead, gunakan format biner! Jika Anda menggunakan teks, Anda bertujuan untuk keterbacaan - lalu mengapa tidak melangkah jauh dan membuatnya dapat dibaca dengan baik?
Roman Starkov

2
@romkyns, mengompresi protokol komunikasi berbasis teks antara dua proses lokal? Itu sesuatu yang baru. Protokol biner jauh lebih kuat. Ini cara unix - protokol berbasis teks tersedia untuk keterbacaan sesekali . Mereka cukup mudah dibaca.
SK-logic

Baik. Premis Anda adalah bahwa saya membaca dan menulis nama-nama register ini atau instruksi CIL cukup sedikit untuk masalah overhead. Tetapi pikirkanlah itu; mereka digunakan sesering metode aneh atau nama variabel dalam bahasa pemrograman lain saat Anda pemrograman . Apakah itu sangat jarang sehingga beberapa byte tambahan penting?
Roman Starkov

1
Saya menghargai hak Anda untuk memiliki rasa yang berbeda dalam berapa panjang nama seharusnya, tetapi apakah Anda benar-benar menyebutkan metode dan penduduk lokal dalam penyusun Anda seperti TIFR, atau, apakah mereka cenderung mengandung kata-kata penuh?
Roman Starkov

1
Saya melihat tidak ada perbedaan yang relevan dengan trade-off yang dapat dibaca vs pendek. Saya melihat mereka berbeda, tentu saja, sama seperti variabel berbeda dengan fungsi yang berbeda dengan tipe. Saya hanya tidak mengerti mengapa opcode dan daftar nama diuntungkan karena terlalu pendek sampai harus berkonsultasi dengan dokumentasi untuk setiap yang baru ditemukan sebelum Anda tahu apa fungsinya. Satu-satunya argumen Anda sejauh ini adalah penyimpanan yang efisien, jika saya tidak salah. Apakah Anda benar - benar bersungguh - sungguh? ... Atau Anda punya alasan lain?
Roman Starkov

1

Sebagian besar idiom. Seperti @TMN katakan di tempat lain, sama seperti Anda tidak menulis import JavaScriptObjectNotationatau import HypertextTransferProtocolLibrarydengan Python, Anda tidak menulis Timer1LowerHalf = 0xFFFFdalam C. Itu terlihat sama konyolnya dalam konteks. Semua orang yang perlu tahu sudah tahu.

Perlawanan terhadap perubahan mungkin timbul, sebagian, dari kenyataan bahwa beberapa vendor kompiler C untuk sistem embedded menyimpang dari standar bahasa dan sintaks untuk mengimplementasikan fitur yang lebih berguna untuk pemrograman tertanam. Ini berarti bahwa Anda tidak dapat selalu menggunakan fitur autocomplete dari IDE atau editor teks favorit Anda saat menulis kode tingkat rendah, karena penyesuaian ini mengalahkan kemampuan mereka untuk menganalisis kode. Karenanya utilitas nama register pendek, makro dan konstanta.

Sebagai contoh, kompiler C HiTech menyertakan sintaks khusus untuk variabel yang perlu memiliki posisi yang ditentukan pengguna dalam memori. Anda mungkin menyatakan:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Sekarang satu-satunya IDE yang ada yang akan menguraikan ini adalah HiTech's IDE sendiri ( HiTide ). Di editor lain mana pun, Anda harus mengetiknya secara manual, dari memori, setiap kali. Ini menjadi tua dengan sangat cepat.

Lalu ada juga fakta bahwa ketika Anda menggunakan alat pengembangan untuk memeriksa register, Anda akan sering memiliki tabel yang ditampilkan dengan beberapa kolom (nama register, nilai dalam hex, nilai dalam biner, nilai terakhir dalam hex, dll). Nama panjang berarti Anda harus memperluas kolom nama menjadi 13 karakter untuk melihat perbedaan antara dua register, dan bermain "spot the difference" di puluhan baris kata yang diulang.

Ini mungkin kedengarannya seperti quibbles kecil yang konyol, tetapi tidakkah setiap konvensi pengkodean dirancang untuk mengurangi ketegangan mata, mengurangi pengetikan berlebihan atau mengatasi salah satu dari sejuta keluhan kecil lainnya?


2
Semua argumen Anda masuk akal. Saya sepenuhnya memahami semua poin itu. Namun, tidakkah Anda berpikir hal yang sama persis berlaku untuk kode tingkat tinggi? Anda juga perlu melihat tabel penduduk setempat dalam fungsi C #. Konteksnya subyektif dan File.ReadAllBytesmungkin juga terlihat sangat panjang untuk seseorang yang dulu fread. Jadi ... mengapa memperlakukan kode level tinggi dan level rendah secara berbeda ?
Roman Starkov

@romkyns - Saya mengerti maksud Anda, tetapi saya rasa kami tidak memperlakukan kode tingkat tinggi dengan sangat berbeda. Singkatan baik-baik saja dalam banyak konteks tingkat tinggi, kami hanya tidak menyadarinya karena kami lebih terbiasa dengan singkatan atau skema apa pun yang menyertainya. Ketika saya benar-benar menulis fungsi atau membuat variabel dalam kode tingkat rendah, saya menggunakan nama deskriptif yang bagus. Tetapi ketika saya merujuk pada register, saya senang bahwa saya dapat melihat sekumpulan huruf dan angka dan dengan cepat berpikir "T = timer, IF = interrupt flag, 1 = first register". Ini hampir seperti kimia organik dalam hal itu: P
detly

@romkyns - Juga, dalam arti murni praktis, saya pikir perbedaan antara tabel register di IDE dan pengembangan aplikasi beberapa mikroprosesor dalam C # adalah ini: tabel register uP akan terlihat seperti: Timer1InterruptFlag, Timer2InterruptFlag, ..., Timer9InterruptFlag, IOPortAToggleMask, IOPortBToggleMask, dll x100. Dalam bahasa tingkat yang lebih tinggi Anda akan menggunakan variabel yang jauh lebih berbeda ... atau Anda akan menggunakan lebih banyak struktur. Timer1InterruptFlagadalah 75% kebisingan irrelevent dibandingkan dengan T1IF. Saya tidak berpikir Anda akan membuat daftar variabel dalam C # yang hampir tidak berbeda seperti itu.
Detly

1
@romkyns - Apa yang Anda mungkin tidak menyadari adalah kenyataan bahwa ada telah terjadi pergeseran ke arah apa yang Anda gambarkan. Kompiler Microchip baru-baru ini datang dengan perpustakaan yang jauh lebih verbose dan deskriptif daripada register misalnya saja. UARTEnable(UART1, BITS_8, PARITY_N, STOP_1, BAUD_115200). Tapi mereka masih sangat kikuk, dan melibatkan banyak tipuan dan inefisiensi. Saya mencoba menggunakannya jika mungkin, tetapi sebagian besar waktu, saya membungkus manipulasi register di fungsi saya sendiri dan menyebutnya dari logika tingkat yang lebih tinggi.
Detly

@detly: Kompilator CCS memiliki metode seperti itu, dan beberapa prosesor lain melakukannya. Saya biasanya tidak menyukai mereka. Spesifikasi register cukup untuk menulis kode yang menggunakan register dan itu cukup untuk membiarkan seseorang membaca kode yang menggunakan register untuk melihat apa yang register lakukan. Jika tindakan menulis nilai N ke prescalar perangkat keras menetapkan periode ke N + 1 (sangat umum), arti yang tepat set_prescalar(TMR4,13);adalah IMHO jauh lebih jelas daripada yang seharusnya TMR4->PSREG=12;. Bahkan jika seseorang melihat manual kompiler untuk mengetahui apa yang dilakukan oleh kode pertama, seseorang kemungkinan masih harus ...
supercat

1

Saya terkejut bahwa tidak ada yang menyebutkan kemalasan dan bahwa ilmu-ilmu lain tidak dibahas. Pekerjaan saya sehari-hari sebagai programmer menunjukkan kepada saya bahwa konvensi penamaan untuk segala jenis variabel dalam suatu program dipengaruhi oleh tiga aspek berbeda:

  1. Latar belakang ilmiah programmer.
  2. Keterampilan pemrograman programmer.
  3. Lingkungan programmer.

Saya pikir tidak ada gunanya membahas tentang pemrograman tingkat rendah atau tingkat tinggi. Pada akhirnya itu selalu bisa dijabarkan ke tiga aspek sebelumnya.


Penjelasan tentang aspek pertama: Banyak "programmer" bukan programmer di tempat pertama. Mereka adalah ahli matematika, ahli fisika, ahli biologi atau bahkan psikolog atau ekonom tetapi banyak dari mereka bukan ilmuwan komputer. Sebagian besar dari mereka memiliki kata kunci dan singkatan khusus domain khusus yang dapat Anda lihat di "konvensi" penamaan mereka. Mereka sering terjebak dalam domain mereka dan menggunakan singkatan yang dikenal tanpa memikirkan pembacaan atau panduan pengkodean.

Penjelasan tentang aspek kedua: Karena sebagian besar programmer bukan ilmuwan komputer, keterampilan pemrograman mereka terbatas. Itulah sebabnya mereka sering tidak peduli tentang konvensi pengkodean tetapi lebih pada konvensi khusus domain sebagaimana dinyatakan sebagai aspek pertama. Juga jika Anda tidak memiliki keterampilan seorang programmer Anda tidak memiliki pemahaman tentang aturan pengkodean. Saya pikir sebagian besar dari mereka tidak melihat kebutuhan mendesak untuk menulis kode yang dapat dimengerti. Seperti api dan lupakan.

Penjelasan tentang aspek ketiga: Tidak mungkin untuk rem dengan konvensi lingkungan Anda yang bisa menjadi kode lama yang Anda harus mendukung, standar pengkodean perusahaan Anda (dijalankan oleh ekonom yang tidak peduli tentang pengkodean) atau domain tempat Anda berada. Jika seseorang mulai menggunakan nama samar dan Anda harus mendukungnya atau kode-kodenya, Anda tidak mungkin mengubah nama samar itu. Jika tidak ada standar pengkodean di perusahaan Anda, saya yakin hampir setiap programmer akan menulis standar mereka sendiri. Dan terakhir jika Anda dikelilingi oleh pengguna domain Anda tidak akan mulai menulis bahasa lain daripada yang mereka gunakan.


belum ada yang menyebutkan kemalasan - mungkin itu karena ini tidak relevan di sini. Dan ilmu-ilmu lain itu tidak dibahas oh itu mudah: situs ini bukan untuk diskusi . Ini untuk pertanyaan dan jawaban
nyamuk

Kemalasan adalah alasan yang sah. Hampir semua programmer adalah orang yang malas (kalau tidak kita akan melakukan semuanya secara manual ooo!).
Thomas Eding
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.