Çünkü C Compiler'ı her insandan daha iyi Assembly yazıyor.
Değerleyici değil, derleyici. Derleyiciler algoritmadaki hataları kontrol etmekle sorumlu değil zaten. Ek olarak aynı mantık assembly içinde geçerli. Assembler'da bulamayacak mantık hatalarını. Ayrıca anlattıklarının hiç biri hala bir insanın C derleyicisinden daha iyi Assembly yazabileceğini kanıtlamıyor.C/C++'da bu daha kolay. Değişkenleri işaretli (signed) yada işaretsiz (unsigned) tanımlayabiliriz. Uzunluğu Byte, Long, Double vs. Değerleyici bazı kontrolleri yapar, fakat algoritmada olan mantık hatalarını tespit edemez.
Ben tam tersini düşünüyorum.
Bir uydurma örnek:
İki sayı toplamak istiyoruz.
Assembly şu şekilde olabilir.
MOV A1, 12D
ADD. L A1, 22D
A1 operatöründe 12+22 = 34 yazar.
Programcı şuna dikkat etmeli: Bayraklarda (FLAGS) bir değişim var mı ya da ben işlem öncesi bayrakları atamam mı gerekiyor. Toplama işlemin toplamı negatif olabilir.
C/C++'da bu daha kolay. Değişkenleri işaretli (signed) ya da işaretsiz (unsigned) tanımlayabiliriz. Uzunluğu Byte, Long, Double vs. Değerleyici bazı kontrolleri yapar, fakat algoritmada olan mantık hatalarını tespit edemez.
Ayrıca değerleyici komutları alt rutin olarak işler. Mesela değerlerliyici toplama işlemini şu şekile dönüştürebilir.
MOV A1, 12D
PUSH A1
MOV A1, 22D
PUSH A1
PUSHF
JSR TOPLAMA
MOV A1,[SP-2]
POPF
RET
TOPLAMA:
MOV A1,[SP-6]
ADD A1,[SP-4]
MOV [SP-4],A1
POP A1
PUSHF
PUSH A1
RTS
Kod uzadığı için programın 'hızı' düşer. Her komut aynı hızda işlenmiyor. Bazı komutların hızı 1 clock olabilir, bazıları 4, 6, 12.. Clock olabilir.
Bazı kodlamaları Assembly dilinde yapmak zorundası. Mesela boot sektörün boyutu sınırlı ise.
int topla(int num1, int num2) {
return num1 + num2;
}
int t = topla(1,2);
topla(int, int): # @topla(int, int)
push rbp
mov rbp, rsp
mov dword ptr [rbp - 4], edi
mov dword ptr [rbp - 8], esi
mov eax, dword ptr [rbp - 4]
add eax, dword ptr [rbp - 8]
pop rbp
ret
__cxx_global_var_init: # @__cxx_global_var_init
push rbp
mov rbp, rsp
mov edi, 1
mov esi, 2
call topla(int, int)
mov dword ptr [rip + t], eax
pop rbp
ret
_GLOBAL__sub_I_example.cpp: # @_GLOBAL__sub_I_example.cpp
push rbp
mov rbp, rsp
call __cxx_global_var_init
pop rbp
ret
t:
.long 0 # 0x0
topla(int, int): # @topla(int, int)
lea eax, [rdi + rsi]
ret
t:
.long 3 # 0x3
Ancak optimizasyon ayarları ile verdiğimde insan doğasına aykırı bir şey yapacak:
Kod:topla(int, int): # @topla(int, int) lea eax, [rdi + rsi] ret t: .long 3 # 0x3
Büyük ölçekli projelerde kalkıp bunu bir insan yapar dersen biraz komik olur.
Değerleyici değil, derleyici. Derleyiciler algoritmadaki hataları kontrol etmekle sorumlu değil zaten. Ek olarak aynı mantık Assembly içinde geçerli. Assembler'da bulamayacak mantık hatalarını. Ayrıca anlattıklarının hiçbiri hala bir insanın C derleyicisinden daha iyi Assembly yazabileceğini kanıtlamıyor.
40Kb'lık oyun yapmak için C'de yeterli. NES uç bir örnek, profesyonel hayata uygulanabilirliği yok. NES çıktığı dönemde, C bu kadar yaygın değildi, compilerlar bu kadar gelişmiş değildi.Ve ayrıyeten NASA gibi yerlerdede bundan dolayı C yerine akıcı Assembly yazabilen developer aranmakta. 64 KB'lık bir belleğe C ile optimize çalışamazsınız.