Systems Programming

05 Dec 2010 Systems Programming

Karena himpunan program komputer untuk suatu aplikasi sering disebut application system, maka kita sering jumpai kelatahan pengertian tentang systems programming dianggap programming untuk sistem aplikasi. Programming untuk membangun, mengembangkan dan/atau merawat sistem aplikasi perbankan, pendidikan, inventori, akuntansi dll bukanlah systems programming. Tetapi programming untuk sistem aplikasi otomasi, pemantauan kinerja komputer/network, pengamanan data dll disebut systems programming. Jadi… apa itu systems programming?


Systems programming atau system-level programming adalah programming yang menyentuh langsung logik arsitektur mesin komputer. Lihat gambar sebelah. Kata “system” berasal dari operating system (OS) karena logik arsitektur adalah wilayah OS yang berisi mekanisme kendali (control). Sehingga systems programming melibatkan satu atau lebih instruksi pengendalian mesin. Misalnya otomasi. Maaf jangan rancu dengan office automation-nya Microsoft atau Linux. Kata “automation” pada office automation sama sekali bukan otomasi sistem. Otomasi tersebut maknanya hanya mengkomputerisasikan.

Jika kita membuat program otomasi, mau tidak mau kita harus bekerja dengan system-event, yang bersumber dari interrupsi mesin dan kehadirannya asinkron dengan alur logik program kita. Misalkita kita akan membuat program otomasi khusus untuk mencegah siapa saja men-disable sejumlah sambungan komunikasi. Disini tergantung kecerdasan kita dalam mendisain program. Supaya benar-benar “mencegah”, kita harus mengetahui berbagai cara orang men-disable sambungan. Jika caranya hanya dengan command, baik langsung dari keyboard maupun melalui program, maka yang kita harus cegat komponen OS yang mengelola command. Setiap kali muncul command “disable” ditangkap dulu oleh program kita sebelum diproses oleh OS dan jika targetnya sesuai dengan yang kita maksud, jangan disampaikan ke OS atau dirubah menjadi command yang salah sebelum disampaikan. Cara ini menuntut kita untuk membuat program yang mampu berinteraksi dengan komponen OS yang membidangi command processing.

Logik di atas sebenarnya logik biasa, hanya sekedar filter sederhana, bukan systems programming. Lantas systems programming-nya dimananya? Nah.. itu dia! Bagaimana kita bisa memasang filter sederhana tersebut di depan command handler sebuah OS? Disitulah kita dituntut melakukan systems programming. Teknisnya tergantung OS yang kita oprek. Adalah sebuah anugrah jika OS yg kita garap menyediakan prologue exit point untuk command handler. Filter bisa dicangkokkan sebagai prolog-exit routine. Untuk OS yang umum dipakai dalam bisnis, exitpoint ini seharusnya ada, karena untuk keperluan security. Tetapi mungkin dokumentasinya dirahasiakan hanya untuk kalangan terbatas (seperti kebanyakan IBM), sehingga kita harus mencari sendiri. Beruntung bagi kita yang bekerja dengan open source, tentu sangat mudah untuk melakukan ini semua meskipun tidak ada dokumentasi. Karena bisa langsung “metani” source codes OS.

Tetapi jika tidak tersedia prolog-exitpoint, kita harus kerja extra keras. Karena harus membelokkan paksa setiap exekusi command handler ke routine kita untuk difilter. Pembelokan paksa ini harus pada posisi yang sangat tepat setepat exitpoint. Karena bisa jadi setiap komponen memiliki lebih dari satu gerbang masuk (entrypoint address atau EPA). Pembelokan harus tepat pada gerbang masuk yang paling umum agar jangan ada yang kelewat.

Terlepas disediakan prolog exitpoint atau tidak, yang paling mutlak kita harus tahu adalah peta memori yang digunakan OS. Bukan peta lokasi saja, tetapi juga peta proteksi. Semua wilayah OS di memori tentu di proteksi. Untuk mesin komputer yang proteksi memorinya didukung hardware seperti pada komputer mainframe (MF), proteksinya bisa beragam. Memang ada kunci master, yaitu key 0. Tetapi akan sangat berbahaya jika kita kurang jitu mengendalikannya.

Masih pada contoh otomasi… Setelah filter dipasang, kita masih punya PR satu lagi, yaitu menjalankan aksi sebagai respon atas event yang telah tertangkap filter. Contoh di atas terlalu sederhana seperti security, hanya menolak atau mengabaikan command disable, bisa dilakukan sekaligus oleh filter. Tetapi jika ada aksi tambahan, misalnya tampilkan message peringatan (masih seperti security) atau exekusi script tertentu, maka filternya menjadi tidak sederhana. Aksi semacam itu tidak mungkin dilakukan langsung secara sinkron oleh filter. Biasanya komponen OS memiliki aturan yang sangat ketat, tidak boleh merubah state. Minimal tidak boleh mengexekusi instruksi yang menyebabkan komponen tersebut memasuki wait-state (misal instruksi I/O). Sehingga cara yang paling aman adalah mengirim signal ke program lain yang aktif di luar command handler. Tentu program tersebut harus kita siapkan. Algoritma program tersebut harus menganut konsep concurrent server (tentu multitasking) agar bisa menangani beberapa signal yang datang bersamaan. Main routinenya selamanya dalam kondisi wait-state menunggu signal dari berbagai filter yang telah kita pasang di berbagai sudut OS. Pada saat ada signal datang, segera melimpahkannya pada anak-program yang telah disiapkan dan dia segera kembali menunggu yang lain.

Sulitkah Belajar Systems Programming?

Seperti telah dijelaskan di atas, dalam programming umum, kita hanya berhadapan dengan aritmetika dan manipulasi karakter dimana logiknya umumnya sinkron. Kalaupun ada yang asinkron, si programmer tidak perlu merekayasanya sendiri, karena disana ada middleware seperti CICS, Oracle, FoxPro yang menanganinya. Middleware mana yang dipilih tergantung jenis aplikasinya dan faktor bisnis lainnya. Sedangkan dalam systems programming, selain aritmetika dan manipulasi karakter, kita juga berhadapan dengan sinyal event, interruption, virtualisasi, peralihan state (state switching), locking dan berbagai jenis kendali (control) lainnya yg logiknya tidak selalu sinkron. Untuk mesin dg prosesor tunggal logiknya pipelining atau interleaving, sehingga tampak asinkron. Untuk prosesor ganda bahkan benar-benar asinkron atau paralel. Baik tunggal maupun ganda, untuk interaksi dengan device bisa paralel atau asinkron jika dikoneksi melalui channel yg berbeda. Hanya saja, penanganannya untuk prosesor tunggal dilakukan secara pipelining.

Sebenarnya systems programming tidak sulit. Tidak sesulit matematika atau fisika. Namun di kampus-kampus tertentu, pelajaran ini bisa menjadi sangat sulit dipahami, Ini pasti karena yang dipaparkan hanya teori saja. Pelajaran ini menuntut porsi praktek lebih banyak. Sehingga akan lebih sulit lagi jika pengajarnya belum pernah mempraktekannya sendiri. Tentu cara menjelaskannya pun sulit dicerna. Membawakan pelajaran ini hanya dengan bercerita dan menampilkan gambar-gambar tentu saja membosankan. Mirip dengan ustad atau pendeta bercerita tentang surga dan neraka. Sulit membayangkan karena yg menjelaskan maupun yg mendengarkan sama-sama belum pernah mengalami.

Dasar utama belajar IT adalah programming. Kata orang kampung, jangan ngaku sebagai orang IT jika tidak ngerti programming. Belajar programming tidak cukup dengan otak-atik logika awam saja. Karena logika programming sangat matematis. Kurang menguasai logika matematis bisa berakibat fatal. Bagaimana seseorang bisa menyusun pernyataan


if ((x=a AND y=b) OR (x=p AND y=q)) AND z=c {...}

jika dia tidak tahu aljabar logika? Tentu programnya akan rentan “salah keputusan”. Apesnya, pemeriksanya (Quality Control) kurang teliti atau bahkan sama-sama tidak tahu. Untuk yang pengaruhnya tidak signifikan, bisa jadi selamanya bisnisnya digrogoti kesalahan.

Ternyata menguasai logika matematis saja tidak cukup. Selain bermain logika matematis, programming juga menuntut ketrampilan menggunakan bahasa komputer tertentu untuk menuangkan program tersebut di komputer yang ditanganinya. Kadang harus menguasai lebih dari satu bahasa komputer. Mau tidak mau harus dilakukan. Sepinter apapun seseorang bermain logika matematis, tetap harus melalui bahasa komputer untuk membuktikan dia mampu programming.

Demikian pula systems programming, harus mampu programming. Namun itu saja tidak cukup. Karena yang digarap tidak hanya logik dan aritmetik saja, tetapi juga kendali yang sangat erat dengan arsitektur dan teknologi komputer yang dipakainya. Maka dia harus benar-benar menguasai hal tersebut. Selain itu, untuk menuangkannya dalam komputer, tidak sembarang bahasa komputer bisa digunakan. Untuk sejumlah mesin komputer tertentu, mungkin cukup dengan bahasa C. Cukup primitif tetapi masih termasuk bahasa komputer. Namun untuk jenis-jenis komputer tertentu, bahasa C kadang tidak cukup dan menuntut harus dengan assembly, himpunan kode-kode mnemonic yang sama sekali tidak mirip bahasa. Bahkan ada jenis-jenis komputer khusus yang tidak menyediakan mnemonic, sehingga harus langsung dengan kode mesin.

Nah.. biasanya assembly atau kode mesin inilah yang bikin orang alergi. Sangat beralasan, selain rumitnya menyusun logika ketengan primitif, juga tidak berlaku umum. Beda arsitektur beda pula assembly-nya. Seseorang yang sudah menguasai systems programming di mesin Intel, boleh jadi tidak tahu apa-apa di mesin mainframe. Demikian pula sebaliknya.

Untuk memulai, bagi generasi sekarang, mungkin yang paling tepat adalah mengikuti dunia open source. Selain bahasa yang digunakan C, juga disediakan source-codes lengkap hingga OS-nya. Asal jangan terjerumus mengabdikan seluruh umurnya untuk open-source. Hanya akan menyenangkan kelompok vendor kelas kakap untuk menangkap ide-ide karya kita untuk diolah menjadi produk komersil di luar open-source. Disana sebaiknya untuk belajar saja. Setelah terampil, tentu harus segera nyadar bahwa dunia komersil lebih menjanjikan.

Apa Manfaat Systems Programming?

Systems programming bermanfaat untuk merekayasa system-level atau OS-level atau machine-level software. Produknya dinamakan system program atau system software. Artinya, software yg berfungsi mendukung langsung fungsi-fungsi hardware, seperti OS, driver, automation, security dll. System-level SW bisa berupa sebuah produk utuh seperti z/OS (OS dari IBM), OPS/MVS (otomasi dari CA), Windows (OS dari Microsoft) dll. Ada pula yg tidak utuh sebuah produk, misalnya sejumlah interface dalam SW aplikasi. Metoda dan algoritma yg digunakan mirip dengan programming pada umumnya. Bedanya, logiknya sangat erat kaitannya dengan arsitektur mesin komputer, sehingga sering disebut juga sebagai machine-level programming. Oleh karena itu tidak semua bahasa programming bisa digunakan. Systems programming biasanya menggunakan bahasa assembly. Ada beberapa mesin yg bisa menggunakan bahasa C/C++.

Apa Masadepan Systems Programming?

Inilah yang sering disesatkan oleh pihak-pihak produsen IT. Kadang kita jumpai kata-kata yang sepertinya nasihat bagus. Untuk apa mikirin OS dan internalnya? Untuk apa buang waktu mempelajari assembly yang primitif? Mau menampilkan pesan “Selamat Pagi” saja bisa habis waktu seharian bikin program. Padahal menulis semenit sudah bisa menampilkan apa saja. Biar saja yang gitu-gitu urusannya sono yang bikin komputer. Lagian kan semua sudah ada. Apa lagi sih yang kurang? Kita bisa ngisi yang sebelah mananya?

Mereka sengaja menyebartkan kata-kata pesimis seperti itu guna mencegah tumbuhnya pesaing baru. Di bidang programming biasa (user-level programming), sudah muncul jutaan industri. Hampir di setiap kota di setiap negara ada software house. Yang diproduksi tidak lain user-level software seperti aplikasi penggajian, akuntansi, web dll, baik dalam bentuk produk komersil ataupun sekedar jasa layanan programming sesuai pesanan. Sehingga satu-satunya wilayah yang belum dijamah banyak orang adalah systems programming. Hingga hari ini pemainnya hanya sekitar 300an perusahaan di seluruh dunia. Jadi pantas saja jika mereka khawatir wilayah inipun akan menjadi milik umum.

Pentingkah Systems Programming di Situs Pengguna?

Secara umum tentu tidak. Pengguna umumnya tidak memerlukan perekayasaan software tingkat sistem atau mesin, karena cukup menggunakan paket-paket dari vendor. Bahkan software aplikasinya pun kadang mereka pilih beli paket jadi dari vendor. Karena dengan produk-produk vendor, mereka bisa mendapatkan fungsi sekaligus dukungan teknisnya. Jika ada masalah, tidak perlu menanganinya sendiri, cukup kontak vendor terkait. Pendalaman teknis di tingkat pengguna cukup hanya sampai systems administration dan technical support untuk mendukung operasi sehari-hari.

Namun demikian ada juga situs pengguna yang memerlukan ketrampilan systems programming, yaitu di situs-situs yang menyelenggarakan aplikasi yang bersifat business-critical (atau lebih populer disebut mission-critical) seperti sistem perbankan, pemerintahan dan reservasi transportasi udara. Situs semacam ini sangat mengutamakan stabilitas sistem yang nyaris tanpa toleransi. Ibaratnya, jangankan sistem sampai jatuh… berkedip saja bisa merusak bisnis. Sehingga selain vendor support, juga harus memiliki tim support sendiri yang cukup handal. Di dalam tim, umumnya tidak cukup hanya teknisi (technical support) saja, tetapi juga insinyur sistem (systems engineer) yang mampu mengkaji kapasitas dan kinerja sistem, menyelenggarakan administrasi sistem sesuai konsep bisnis dan konsep arsitektur sistemnya, serta mampu menelusuri masalah (troubleshooting) sesuai arsitektur dan teknologi sistemnya, bahkan diharapkan mampu merekayasa solusi-solusi sederhana dengan cepat baik dalam rangka mengatasi masalah maupun inovasi penyederhanaan operasi. Nah untuk itulah para insinyur sistem wajib memiliki ketrampilan systems programming di samping metoda analitik kuantitatif yang handal.

Assembly

Ada baiknya kita menyimak posting tentang mengenal assembly sebelum membaca bagian ini. Ketrampilan assembly adalah wajib dalam lingkup systems programming. Terlepas apakah bahasa C bisa menggantikan, tetap saja ada hal-hal yang tak tergantikan. Contohnya dalam penugasan register, bahasa C tidak explisit menunjuk register yang mana. Padahal dalam systems programming kadang kita dituntut untuk mengelola register dengan cermat. Maka assembly adalah satu-satunya pilihan jika kita tidak mau menggunakan kode mesin langsung yang harus ditulis dalam hexadecimal tanpa jeda dan sulit dibaca. Keharusan penggunaan argumen dari satu modul ke modul lain membuat bahasa C kurang efisien dalam mekanisme memory sharing dan register sharing. Sedangkan dengan assembly, dalam state yang sama, semua isi register otomatis shared selama tidak kita rubah. Hilir mudik call maupun go to antar modul tidak perlu memasang argumen. Dengan demikian, memory sharing sangat dipermudah. Selama address-nya sudah dipegang oleh salah satu register, semua modul dalam rangkaian call atau go to bisa mengakses langsung tanpa tahapan apapun, seperti contoh berikut ini.


Module01 csect
         basr  *,r12
         storage OBTAIN,length=COMMON_size
         lr    r5,r1
         using COMMON,r5 
         ...
         (mendapatkan nilai X di reg 1)
         st    r1,data01
         l     r15,=v(Module02)
         basr  r14,r15 
         (data02 dan data03 sudah terisi y dan x+y) 
         COMMON
         end

Module02 csect
         using Module02,r15
         ...
         using COMMON,r5 
         (mendapatkan nilai Y di reg 1)
         st    r1,data02
         a     r1,data01
         st    r1,data03
         ...
         br    r14
         ...
         COMMON
         end

         macro
COMMON   dsect
data01   ds    f
data02   ds    f
data03   ds    f
         ...       
COMMON_size equ *-COMMON
         mend

Contoh di atas menggambarkan Module01 dan Module2 sharing memori COMMON yang berisi data01, data02 dan data03. Memori COMMON dialokasikan oleh Module01 dan dipetakan dengan register 5 dan data01 diisi dengan sebuah nilai integer X. Lantas Module01 call Module02 dengan instruksi BASR. Selama register 5 tidak diutak-utik oleh Module01 maupun Module02, peta memori COMMON akan tetap dipegang oleh register 5. Module02 bisa langsung mendapat address COMMON tanpa harus melakukan tahapan upacara apapun. Itulah kelebihan assembly dibandingkan bahasa C.

Debugging dengan membaca memory dump juga wajib harus memahami assembly. Tidaklah mungkin seseorang mampu melakukannya tanpa pengetahuan assembly. Bagaimana mungkin? Data memori yang sebenarnya binary tidak mungkin ditampilkan dalam bentuk text apalagi dalam bahasa C atau Java atau yang lainnya. Lagi pula tool manapun tidak akan tahu mana yang data mana yang program. Sehingga satu-satunya cara yang dicurahkan (dump) apa adanya. Hanya saja agar lebih ringkas dikonversi ke hexadecimal.

Data hexadecimal tersebut lantas harus kita telusur untuk menemukan titik awalnya sesuai dengan pointer yang terekam dalam register khusus yang berfungsi sebagai execution control status (dalam terminologi mainframe dinamakan program status word atau PSW). Dari sana baru kita bisa telusur satu-per-satu kode mesin untuk mendapatkan logiknya. Selain panjang tiap instruksi mesin tidak sama, kita juga harus mengikuti memory alignment. Semua ini tidak mungkin dilakukan oleh orang secerdas Einstein sekalipun tanpa memahami assembly.

Padahal, kenyataannya di lapangan sangat langka yang menguasai assembly. Tetapi banyak yang menjabat sebagai insinyur sistem dan banyak pula yang dianggap berprestasi. Jadi… siapakah mereka sebenarnya? Apa pekerjaan mereka? Memang kadang enak jadi tentara tidak pernah perang. Tapi itu bukan salah mereka. Yang salah yang mau membayarnya

Bersambung ke Sysprog #2

Topik-topik terkait

  1. Mengenal Assembly
  2. Memanfaatkan kesalahan dalam Assembly
  3. Systems programming #2 (lanjutan)
mm
Deru Sudibyo
deru.sudibyo@gmail.com
1Comment
  • Muhammad Ilham
    Posted at 23:41h, 08 May Reply

    Rumit kyaknya ..

Post A Comment