Bölüm 2:Temeller

Bu kitabı yazarken beni tekrar tekrar şaşırtan şey, bilgisayarların ne kadar basit olduğuydu. İnsanın aklı bilgisayarların içinde, gerçekte olduğundan daha karmaşık ve daha soyut bir yapı arıyor; öyle bir yapı yok. Devam etmeden önce aklına kazımanı istediğim tek bir şey varsa o da şu: basit görünen birçok şey gerçekten de basittir. Bu sadelik hem çok güzel hem de zaman zaman epey lanetlidir.

Bilgisayarının özünde nasıl çalıştığına dair temel resimle başlayalım.

Bu bölümde neyi çözüyoruz?

• CPU’nun talimatları nasıl okuyup yürüttüğünü göreceğiz.
• RAM, disk, register ve instruction pointer arasındaki farkı netleştireceğiz.
• “Program” ile “process” arasındaki farkı yerine oturtacağız.
• Bilgisayar açıldığında ilk talimatın nereden geldiğini çözeceğiz.

Bilgisayarlar Nasıl Tasarlanır?

Bir bilgisayarın merkezi işlem birimi (CPU), bütün hesaplamalardan sorumludur. İşin patronu odur. Makine açıldığı anda çalışmaya başlar ve talimat üstüne talimat yürüterek durmadan devam eder.

Bir programı başlatmadan önce o programın dosyası kalıcı depoda durur: sabit diskte ya da SSD’de. Kernel onu çalıştırmaya karar verdiğinde dosyanın gerekli parçalarını RAM’e taşır. Şimdilik temel resmi şöyle tut: disk kalıcı depo, RAM çalışma masası, CPU da masadaki talimatları uygulayan motor.

Bu resmin ileride iki yerinden inceleceğini şimdiden söyleyeyim. Birincisi, CPU talimatları çoğu zaman RAM’e hiç gitmeden, ona çok daha yakın duran küçük ara depolardan alır. İkincisi, bir programın gördüğü adresler ile RAM’deki gerçek adresler aynı şey değildir. İkisini de yeri geldiğinde ayrı ayrı açacağız; şimdilik basit resim yeterli.

Bu fikrin ne kadar eski olduğunu görmek için bir örnek vereyim: Intel’in Kasım 1971’de duyurduğu Intel 4004. Ne kadar küçük olduğunu bir rakamla anlatayım — 4004 aynı anda yalnızca 4 bit işleyebiliyordu, yani senin bugün kullandığın işlemcinin tek hamlede çevirdiği verinin on altıda birini. Ama içindeki fikir bugünküyle birebir aynıydı: programlanabilir bir çip, talimatları sırayla yürütür. Bu kitapta anlatacağım her şey o tek fikrin üstüne kuruldu.

CPU’nun yürüttüğü “talimatlar” sadece ikili veridir: önce hangi talimatın çalıştırıldığını belirten bir ya da birkaç baytlık opcode gelir, ardından o talimatın ihtiyaç duyduğu veri yer alır. Makine kodu dediğimiz şey, aslında bu ikili talimatların art arda dizilmesinden ibarettir. Assembly, insanların ham bitlere göre çok daha rahat okuyup yazabildiği bir gösterimdir; ama sonuçta her zaman CPU’nun anlayacağı ikili biçime derlenir.

Bir not: Talimatlar makine kodunda her zaman yukarıdaki örnekteki gibi 1:1 görünmez. Örneğin add eax, 512, 05 00 02 00 00 şeklinde kodlanır.

İlk bayt (05), özellikle EAX register’ına 32-bit bir sayı ekleme işlemini ifade eden opcode’dur. Kalan baytlar ise little-endian sıra ile yazılmış 512 (0x200) değeridir.

Defuse Security, assembly ile makine kodu arasındaki çeviriyle oynamak için yararlı bir araç hazırlamış.

RAM, bilgisayarının ana belleğidir; çalışan programların kullandığı verilerin tutulduğu büyük ve genel amaçlı alan budur. Buna program kodunun kendisi de, işletim sisteminin kernel kodu da dahildir. CPU’nun yürüteceği talimatların RAM’de erişilebilir olması gerekir; yalnızca diskte duran bir dosya kendi kendine çalışmaz.

Burada, kitabın ilerleyen bölümlerinde birkaç kez karşımıza çıkacak bir ayrım var: RAM uçucudur, disk kalıcıdır.

Sebebi fizikte. RAM’in her biti, minik bir kondansatörde tutulan elektrik yüküdür ve o yük kendiliğinden boşalır — o kadar hızlı boşalır ki, makine çalışırken bile her hücrenin saniyede binlerce kez yeniden doldurulması gerekir. Buna refresh denir ve RAM’in “D”si (Dynamic) tam olarak buradan gelir. Elektrik kesildiği anda refresh durur, yükler kaçar, veri gider. Disk ise veriyi manyetik yönelim ya da hapsedilmiş elektron olarak saklar; elektriğe ihtiyaç duymaz.

Gündelik hayatta bunun iki tanıdık sonucu var. Birincisi, kaydetmediğin dosyanın elektrik kesintisinde uçup gitmesi. İkincisi, her açılışta bilgisayarın “yeniden yükleniyor” olması — çünkü RAM’de gerçekten hiçbir şey kalmamıştır ve her şeyin diskten baştan taşınması gerekir. Bölümün ilerleyen kısmında, “peki RAM boşsa ilk talimat nereden geliyor?” sorusuna da döneceğiz.

CPU, sıradaki talimatın nerede olduğunu takip etmek için instruction pointer adında bir gösterge tutar. Burada karıştırması çok kolay bir ayrım var, o yüzden baştan netleştirelim:

Göstergenin kendisi CPU’nun içindedir; gösterdiği adres RAM’dedir. İkisi aynı yerde değil. Bir kitap okurken parmağını satırların üzerinde gezdirmen gibi düşün — parmak sende, satırlar kitapta. CPU bir talimatı bitirince parmağını bir sonrakine kaydırır ve aynı işi baştan yapar. Buna fetch-execute cycle denir.

Bu ayrım küçük bir ayrıntı gibi görünüyor ama kitabın geri kalanının yarısı buradan çıkıyor. Göstergenin CPU’nun içinde olması, ona erişmenin bedava sayılacak kadar ucuz olması demek. Gösterdiği yerin RAM’de olması ise, oraya gitmenin pahalı olması demek. Aradaki bu uçurum, 5. bölümde göreceğimiz bütün bellek hiyerarşisinin ve 8. bölümdeki hız hilelerinin var olma sebebidir.

Bir talimat yürütüldükten sonra instruction pointer, RAM’de o talimatın hemen sonrasına ilerler; böylece sıradaki talimatı işaret eder. Kodun çalışması dediğimiz şey tam olarak budur. Talimatlar bellekte hangi sıradaysa CPU onları o sırayla yürütür. Bazı talimatlar ise instruction pointer’a başka bir adrese atlamasını söyler; böylece dallanma, koşullu mantık ve tekrar kullanılabilir kod mümkün olur.

Döngünün dört adımını tek tek izlemek istersen:

Pratikte CPU çekirdeği ile DRAM arasında L1 → L2 → L3 gibi cache katmanları bulunur. Programcıya görünen basit model “bellekten oku/yaz” olsa da donanım sık kullanılan veri ve talimatları CPU’ya yakın tutarak gecikmeyi azaltır; bu ayrıntı temel fetch-execute resmini değiştirmez.

Burada, fark etmesi kolay olmayan ama her şeyin üstünde durduğu bir tasarım kararı var: talimatlar ve veriler aynı bellekte duruyor. CPU’nun okuduğu makine kodu ile üzerinde çalıştığı sayılar aynı RAM’de, aynı adres uzayında, aynı byte’lardan yapılmış. Bir programın dosya olarak diskte durabilmesi, kopyalanabilmesi, indirilebilmesi tamamen bu karara bağlı.

Bu instruction pointer bir register içinde tutulur. Register’lar, CPU’nun çok hızlı okuyup yazabildiği küçük depolama alanlarıdır — ve “küçük” derken gerçekten küçük kastediyorum. Birkaç sayıyla bakalım:

• Sayı ve boyut. x86-64’te 16 genel amaçlı register vardır ve her biri 64 bit, yani 8 bayt tutar. Toplamı 128 bayt. Aynı makinede RAM gigabaytlarla ölçülüyor — arada milyarda bir mertebesinde bir oran var.
• Neden bu kadar hızlı? Çünkü register CPU’nun içinde, hesap yapan devrelerin hemen yanındadır; aynı silikon parçasının üzerinde. RAM ise anakart üzerinde ayrı bir yongadır ve oraya gidip gelmek, elektrik sinyalinin fiziksel olarak yol katetmesi demektir. Register erişimi bir saat çevrimi sürer, RAM erişimi yüzlerce.
• İsimler neden bu kadar tuhaf? rax, eax ve ax üç ayrı register değil; aynı register’ın farklı boylardaki görünümleridir. rax 64 bitin tamamı, eax alttaki 32 bit, ax alttaki 16 bit, al ise en alttaki 8 bit. Bu iç içe geçmişlik geriye uyumluluktan geliyor: 16-bit çağında yazılmış kod, 64-bit bir işlemcide hâlâ çalışsın diye.

Yukarıdaki assembly örneğinde gördüğün eax ve ebx gibi genel amaçlı register’lara makine kodundan doğrudan erişilebilir.

Bazı register’lar ise CPU tarafından daha içsel amaçlarla kullanılır; yine de çoğu zaman özel talimatlarla okunabilir veya güncellenebilirler. Instruction pointer buna iyi bir örnektir: doğrudan okunmaz ama örneğin bir jump talimatı ile değiştirilebilir.

İşlemciler Naiftir

Asıl soruya dönelim: Bilgisayarında çalıştırılabilir bir programı başlattığında ne oluyor? Önce onu çalıştırmaya hazırlamak için bir sürü kurulum yapılır, bunların hepsini birazdan göreceğiz, ama sonunda dosyanın içindeki makine kodu RAM’e yerleştirilir. Ardından işletim sistemi CPU’ya instruction pointer’ı o konuma ayarlamasını söyler. CPU da fetch-execute cycle’ı normal şekilde sürdürür ve program çalışmaya başlar.

Burada bir saniye durmanı istiyorum. Bu satırları okumak için kullandığın program da tam olarak böyle çalışıyor. Tarayıcının makine kodu şu anda RAM’de duruyor; CPU’n instruction pointer’ı o kodun üzerinde bir adım bir adım ilerletiyor ve okuduğun cümle, saniyede milyarlarca kez tekrarlanan bu tek döngünün çıktısı. Sihir yok; sadece çok hızlı tekrarlanan çok basit bir iş var.

Burada bir terimi de yerine oturtalım, çünkü kitabın geri kalanında sürekli kullanacağız. Program, diskte duran dosyadır; kimse çalıştırmadıkça hiçbir şey yapmaz. Process ise o dosyanın çalışan hâlidir: kendi belleği, kendi açık dosyaları ve kendi instruction pointer değeri olan canlı bir örnek. Aynı programı iki kez açtığında ortada tek bir dosya ama iki process olur.

Şimdi hükmü verebiliriz: CPU’ların dünya görüşü inanılmaz derecede dardır. Yalnızca o andaki instruction pointer’ı ve biraz da iç durumu görürler. Process tamamen bir işletim sistemi soyutlamasıdır; CPU’nun doğal olarak bildiği ya da takip ettiği bir kavram değildir.

process diye bir şey yok; işletim sistemi geliştiricileri daha çok bilgisayar satılsın diye uydurulmuş bir hikâye bu

Bu kadar dar bir dünya görüşü, hemen üç soru doğuruyor. Kitabın geri kalanı büyük ölçüde bunların cevabı:

1. CPU çoklu işlemeyi bilmiyorsa ve sadece talimatları sırayla yürütüyorsa, neden tek bir programın içinde sıkışıp kalmıyor? Birden fazla program aynı anda nasıl çalışabiliyor?
2. Programlar doğrudan CPU üzerinde çalışıyorsa ve CPU doğrudan RAM’e erişebiliyorsa, neden başka process’lerin belleğine, hele hele kernel belleğine erişemiyorlar?
3. Madem konu açıldı: Her process’in istediği talimatı çalıştırıp bilgisayarına istediğini yapmasını engelleyen şey ne? Ve syscall denen şey tam olarak nedir?

Bellek meselesi kendi bölümünü hak ediyor; onu Bölüm 13’da ele alacağız. Kısa versiyon şu: user-space programı kendi sanal adres alanına erişir; fiziksel RAM’e, kernel belleğine ve ayrıcalıklı donanım giriş/çıkışına doğrudan el uzatamaz. Şimdilik bellek koruması yokmuş ve bilgisayar aynı anda sadece tek bir process çalıştırıyormuş gibi sadeleştirelim. Bu varsayımların ikisini de birazdan bozacağız.

Şimdi ilk derin dalışımızın zamanı: syscall’lar ve ring’ler.

Bu arada kernel nedir?

Bilgisayarındaki macOS, Windows ya da Linux gibi işletim sistemi, temel işlerin yürümesini sağlayan bütün yazılım katmanıdır. “Temel işler” çok muğlak bir ifade ve “işletim sistemi” terimi de kime sorduğuna göre değişir; kimi insanlar buna varsayılan uygulamaları, font’ları ve ikonları da katar.

Ama kernel, işletim sisteminin çekirdeğidir. Bilgisayarı açtığında çalışan ilk şey kernel değildir: önce anakart üzerindeki firmware (BIOS ya da UEFI) donanımı ayağa kaldırır, sonra bir bootloader (GRUB gibi) kernel’ı diskten bulup RAM’e yükler ve kontrolü ona devreder. O andan sonra makinenin sahibi kernel’dır. Belleğe, çevre birimlerine ve sistem kaynaklarına neredeyse tam erişimi vardır ve user-space programlarını çalıştırmak onun işidir. Kitap boyunca kernel’ın bu erişime nasıl sahip olduğunu, programların neden olmadığını göreceğiz.

Linux tek başına bir kernel’dır; kullanılabilir bir sistem olması için shell’ler, görüntü sunucuları ve başka birçok user-space yazılımına ihtiyaç duyar. macOS’un kernel’ının adı XNU’dur ve Unix benzeridir; modern Windows kernel’ı ise NT Kernel olarak bilinir.

Bu boot zincirini okurken çoğu kişinin aklına çok yerinde bir itiraz gelir, o yüzden hemen cevaplayalım.

Bölümü kapatmadan elimizdekini toparlayalım.

Peki, ne öğrendik?

• CPU sonsuz bir fetch-execute cycle içinde çalışır: talimatı oku, yürüt, göstergeyi ilerlet, baştan başla.
• Instruction pointer CPU’nun içindedir, gösterdiği adres RAM’dedir. Aradaki bu uzaklık kitabın geri kalanının yarısını açıklar.
• Register’lar CPU’nun içindeki çok küçük ve çok hızlı depolardır; RAM ile aralarında yüzlerce kat gecikme farkı vardır.
• RAM uçucudur, disk kalıcıdır. Bilgisayarın her açılışta her şeyi baştan yüklemesinin sebebi budur.
• Program diskteki dosyadır, process onun çalışan hâlidir. CPU process diye bir şey bilmez; process tamamen bir işletim sistemi soyutlamasıdır.

Bölümü üç soruyla kapatmıştık. Birincisinin cevabı 7. bölümde bizi bekliyor. Diğer ikisi ise doğrudan bir sonraki bölümün konusu: aynı çip, aynı talimatı neden bazen çalıştırıp bazen reddediyor?