Ide Sampah 9-bit Byte

sampah Mengapa disebut ide sampah? Karena ide byte mulai dari 6 s/d 9 bit sudah ada sejak dulu. Sejarahlah yang bicara, bahwa 1 byte = 8 bit lebih diterima khalayak. Pengusungnya adalah RW Bemer, di majalah Communication ACM 2, No. 9, September 1959. Komputer IBM STRETCH tercatat menggunakan karakter 8-bit yang pertama kali. Publik lebih mengenal komputer IBM 360, yang juga menggunakan karakter 8-bit.

Bernaridho I. Hutabarat (BIH) mencoba mengusung kembali ide sampah ini, melalui tulisannya di majalah PC Media 01/2012. Seperti biasanya, BIH hanya suka mengobrak-abrik tatanan yang ada, tanpa manfaat sama sekali. Salah satu karya BIH adalah bahasa Nusaptel, yang tidak pernah secara nyata dipakai di manapun. Dengan argumen ortogonalitas, dia mengklaim Nusaptel lebih irit dalam penulisan program. Bahasa baru hanya untuk mengirit source code? What a joke!

Salah satu kata kunci dari Bob Bemer, pencetus 8-bit byte: "Powers of 2 are still magic!". Tentu mudah dipahami, karena komputer beroperasi secara biner, berbasis 2. Bila menggunakan 9-bit byte, maka ini menyimpang dari basis, karena 9 itu bukan pangkat dari 2. Perancang sistem akan terbiasa memecah unit-unit ke dalam kelipatan dua, seperti halnya deretan 1, 2, 4, 8, 16, dst. Berpikir hanya secara parsial, tentu lebih condong merusak sistem daripada membetulkannya.

Dalam tulisan, BIH menyebut unicode adalah "spesifikasi karakter 16-bit". Rupanya dia hanya membaca versi jadul dari implementasi unicode, atau dia ingin menyelewengkan arti unicode demi tujuannya sendiri. Implementasi unicode di Windows, awalnya dari UCS-2, lalu berubah jadi UTF-16. Namun pada dasarnya atau seharusnya, ini adalah variable length 2 s/d 4 byte. Encoding unicode di web mayoritas berupa UTF-8, mulai dari 1 byte s/d 4 byte. Jadi tidak valid unicode disebut hanya 16-bit. UTF-8 dan UTF-16 memiliki sejutaan karakter. Tidak perlu 9-bit byte.

Lalu mengenai Base64. Entah apa yang ada di kepala BIH, sehingga mengaitkan encoding ini dengan perubahan yang sangat fundamental. Encoding Base64 hanya banyak dipakai dalam transmisi e-mail, karena SMTP server tidak dirancang 8-bit clean. Sangat tidak beralasan bila karena ini perlu 9-bit byte. Apalagi unicode seperti di atas, tidak selalu berwujud 16-bit. Solusi yang lebih baik adalah mengubah SMTP server itu sendiri, karena keterbatasan ini akibat legacy sejarah yang tidak perlu.

Disinggung soal warna terkait 9-bit byte, yang sebenarnya masalah sangat remeh. Soal color depth, Windows pun menyediakan 16-bit bila ingin lebih ‘efisien’. HDMI malah menyediakan 30 s/d 48 bit warna. Pemecahan warna menjadi RGB atau CMYK, bukanlah masalah besar, akan selalu ada cara. Apalagi graphics processing unit (GPU) mempunyai daya komputasi luar biasa, yang malah bisa mengalahkan kompleksitas CPU. Mengenai manfaat warna pada mode teks, ini seperti mengutak-atik dinosaurus pada zaman modern. Buat apa?

Mengenai encoding heksadesimal, juga diulas secara tidak tepat. Penyajian bilangan di komputer, dapat dilakukan dalam berbagai cara. Bisa biner, oktal, desimal, dan juga heksadesimal. Apa hubungannya dengan kemampuan hardware 2 pangkat n? Pengalamatan memory tidak selalu sebesar register alamat (IP/EIP). Bisa lebih kecil atau malah lebih besar. Contoh, x86 yang 32 bit bisa mengakses > 4 GB. Lalu siapa yang menciptakan ilusi hardware harus 2 pangkat 16, 32, atau 64 ? Itu memang besaran register alamat, tapi dalam kondisi virtual tentu cakupan IP/EIP yang ada tergantung konteksnya. Lagipula, apa hubungannya dengan 9-bit byte?

Pada akhirnya, semakin tidak jelas apa yang BIH inginkan dari 9-bit byte, kecuali mengejar kontroversial semata. Perlu diingat, ada ‘data structure alignment‘ dalam mengakses memory. Jadi bicara efisien tidak selalu hasilnya bagus. Boolean yang 1-bit pun bila ingin optimal perlu dibuat menjadi 32-bit dalam prosesor 32-bit. Ini hal mendasar, dan sudah berlaku sejak lama di dunia programming. Kenapa malah mundur dengan ide sampah 9-bit? Tatanan dunia komputasi sudah matang dengan 8-bit, 16-bit, 32-bit, dan 64-bit. Ada istilah dalam dunia rekayasa, "if it ain’t broke, don’t fix it". Bila tidak rusak, janganlah diperbaiki.

Link terkait:

http://www.bobbemer.com/BYTE.HTM
http://en.wikipedia.org/wiki/Color_depth
http://en.wikipedia.org/wiki/Unicode
http://en.wikipedia.org/wiki/UTF-8
http://en.wikipedia.org/wiki/UTF-16
http://en.wikibooks.org/wiki/Windows_Programming/Unicode
http://en.wikipedia.org/wiki/Physical_Address_Extension
http://en.wikipedia.org/wiki/Data_structure_alignment

10 Komentar »

  1. Saya sendiri menganggap ide ini tidak bagus, tapi sebenarnya kalau memang menganggap ide mengenai 1 byte = 9 bit ini baik, sekarang ini kan siapa saja bisa membuat sendiri CPU 9 bit dengan FPGA (bahkan berapa bit pun bisa dicoba sendiri). Harga sebuah development kit FPGA bisa didapat mulai 39 USD (misalnya XuLA-50). Software compiler yang dimiliki bisa diubah supaya mendukung byte yang ukurannya 9 bit.

    Dengan mengimplementasikan menggunakan VHDL/Verilog, bisa tahu efisiensi implementasi low level. Mungkin setelah melihat low level, baru akan terlihat mengapa kelipatan 2 dan pangkat 2 itu bagus. Misalnya secara fisik menempatkan benda yang ganjil akan lebih susah dibanding jika bendanya genap.

    Tapi ya pertama harus mampu dari hal-hal dasar, misalnya mampu mengimplementasikan compiler sendiri.

    • oguds said

      Buat CPU sendiri? Ribetlah, mana sanggup BIH mikir sejauh itu. Bikin Nusa saja numpang gcc ya. Coba saja, dangkal sekali alasannya tentang 9-bit byte. Misalnya Unicode dan Base64. Kalau bit-nya kurang, tambahkanlah ke 16 atau 32, jangan malah jadi 9. Memang rada sableng. 🙂

    • Oguds said

      bbci> Agak gila itu sudah sama dengan gila. Tidak ada kewajiban saya
      bbci> menjawab komentar-komentar ada di webpage itu. Anda tidak merasa bersalah menuduh saya gila.

      Ada keberatan dari sdr BIH via e-mail seperti tertulis di atas. Perlu saya perjelas, ‘agak sableng’ di atas jangan dibaca kaku sehingga menuduh seseorang gila dalam arti sebenarnya. Saya hanya menganggap ide 9-bit byte cukup nyeleneh, pemikiran atau ide yang ‘agak gila’. Tidak lebih dari itu. Saya sependapat, bahwa kita tidak boleh merendahkan siapapun melalui media apapun. Namun perlu diingat, ide yang kontroversial akan mendapat tanggapan yg sama kontroversialnya. Ini sudah menjadi realitas kehidupan.

      Semoga menjadi jelas. Silakan ditanggapi tulisan di blog ini seperlunya. Tks.

  2. Bernaridho said

    Berbeda pendapat itu satu hal. Menuduh orang lain sebagai orang gila itu hal lain.

    Anda pengecut, tidak memakai nama asli Anda: MAYKADA HARJONO.

    Anda pengecut, tidak mencantumkan bahwa Anda juga PENULIS di PC Media. Jadi, ini adalah kecaman terhadap penulis di media yang sama, tapi tidak memberitahukan kepada publik identitas sebenarnya.

    Anda manfaatkan kelemahan PC Media yang belum memiliki kode etik tentang saling mengecam di antara penulisnya.

    Sebagai pembaca, saya kecewa kepada PC Media bila terus mengizinkan seseorang sebagai kontributor, padahal orang tersebut menuduh kontributor lain sebagai orang gila. Itu tuduhan yang serius.

    Sebagai pembaca, saya berharap PC Media tidak memakai kontributor yang menyebut kontributor lain sebagai orang gila.

    Saya meminta PC Media segera mengharuskan setiap penulis untuk memakai nama pribadi dan menyertakan info peran mereka sebagai penulis di PC Media saat menyerang penulis lain di PC Media.

  3. Bernaridho said

    Saya pikir seseorang tidak layak menjadi kontributor majalah sebesar PC Media bila kontributor tersebut menyebut kontributor lain sebagai orang gila. Orang seperti itu tidak layak disebut kontributor, lebih layak disebut preman.

    • Oguds said

      Di blog ini ada kategori tulisan ‘pc media’, berasal dari beberapa artikel yang dimuat di PC Media. Kecuali tiga artikel terakhir, dibawahnya disebut ‘Dimuat di PC Media edisi xxx’. Itu sudah cukup. Menurut saya tidak penting menjadi kontributor di PC Media dibesar-besarkan.

      Terserah anda sendiri, menyebut diri sendiri gila. Saya sudah menjelaskan maksud ‘rada sableng’ seperti di atas. Bila anda merasa lebih gila dari penjelasan saya, itu masalah anda sendiri. Malah sekarang saya dituduh preman. Makanya, kalau tidak siap dikritik, jangan membuat tulisan yang nyeleneh. Introspeksi diri, silakan baca komentar-komentar yang lain di sini, dari posting-posting saya sebelumnya. Bereaksilah sebagai orang dewasa, menjawab kritik dengan baik. Tidak malah ngomel seperti anak-anak.

  4. Setelah membaca artikel di PC Media, ada yang ingin saya tambahkan

    1. Unicode menggunakan representasi 9-Bit/18 Bit sudah dicoba, dan tidak lebih efisien dari UTF-8. Silakan cek di: http://en.wikipedia.org/wiki/UTF-9_and_UTF-18

    Perlu diketahui bahwa UNICODE bukan hanay daftar karakter dalam urutan tertentu. UNICODE dibagi dalam berbagai “plane” (17 plane x 65536 karakter) supaya jika ada simbol baru, bisa ditambahkan di plane yang sesuai dan terkelompokkan dengan baik (misalnya ketika eropa memperkenalkan simbol mata uang Euro, maka karakter tersebut tidak muncul di dekat karakter bahasa lain, misalnya jepang atau korea).

    Untuk merepresentasikan 17 plane x 65536 karakter/plane, butuh setidaknya: 5 + 16 bit = 21 bit.

    2. Perhitungan bahwa 9 bit akan lebih efisien diencode jadi base64 tidak benar. Yang benar adalah bahwa butuh lebih banyak karakter untuk mengencode byte dengan ukuran 9 bit. Efisiensi konversi dalam 9 bit:

    1 karakter dalam base64 selalu 6 bit.

    untuk setiap 2 byte (9-bit) menjadi 3 karakter:

    Hitungannya: 2 x 9 bit = 18 bit = 3 karakter base64,

    untuk setiap 3 byte (9-bit) menjadi 4 karakter:

    Hitungannya: 3 x 8 bit = 24 bit = 4 karakter base 64

    Jika punya file teks 3000 byte, maka jika 1 byte = 8 bit, hasilnya kan menjadi 4000 karakter base64, sedangkan untuk 1 byte = 9 bit hasilnya 4500 karakter base64.

    Untuk hitungan ini, jika masih belum percaya juga, silakan dibuktikan langsung di mesin dengan 9 bit byte. Silakan kunjungi ke http://twenex.org, di situ kita bisa minta account gratis ke sistem TOPS20 yang menggunakan memori 36 bit word, dan char 9 bit. Kita bisa mengcompile program C di situ, dan menjalankannya. (saya sudah mencoba membuat program encoder ini, sekedar iseng untuk berlatih 9 bit, untuk tutorial saya di http://cintaprogramming.com).

    3. Saat ini attribut teks seperti yang dijelaskan dalam artikel (pendekaan DOS) sudah tidak dipakai lagi (ini ditinggalkan kira-kira sejak windows 95, yaitu 17 tahun yang lalu).

    Windows masih mendukung terminal teks, tapi menggunakan attribut 16 bit (bukan 8 bit), karena selain warna, , ada attribut lain, seperti “underscore”, “bold”, dsb. Silakan lihat API-nya:

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms682088(v=vs.85).aspx#_win32_character_attributes

    Sedangkan dari dulu UNIX menggunakan ANSI Escape Sequence yang tidak bergantung pada jumlah bit dalam byte:

    http://en.wikipedia.org/wiki/ANSI_escape_code#Colors

    4. Meski tidak ada hubungannya dengan 9 bit untuk 1 byte, sebagai catatan, sampai saat ini pun ada banyak hardware yang tidak menggunakan ukuran yang selalu pangkat 2. Chip-chip DSP saat ini banyak yang menggunakan 12 bit. Beberapa Microcontroller PIC menggunakan instruksi yang besarnya 14 bit.

    • oguds said

      Jangan lupa juga, representasi 9-bit dalam prakteknya akan lebih boros. Bila dikelompokkan per 3-bit, misalnya 0n777, butuh 3 karakter. 8-bit byte mengenal nibble, yaitu 4-bit high dan low, sehingga bisa ditulis dengan notasi heksadesimal. Ini lebih kompak, hemat tempat, misal 0xFF. Bahkan IPv6 juga menggunakan notasi hexa.

      • Masih terkait dengan masalah warna dan hexa. Saat ini representasi warna yang sangat sering dipakai adalah representasi heksadesimal untuk warna (misalnya CSS yang dipakai di semua halaman web), sedangkan pemakaian warna di console sepertinya sudah sangat jarang sekali.

        Dengan mengurangi jumlah byte untuk merepresentasikan warna, maka halaman web jadi lebih kecil, download lebih cepat.

    • Sedikit salah ketik:

      tertulis:

      untuk setiap 3 byte (9-bit) menjadi 4 karakter:

      seharusnya:

      untuk setiap 3 byte (8-bit) menjadi 4 karakter:

RSS feed for comments on this post · TrackBack URI

Tinggalkan Balasan ke Bernaridho Batalkan balasan