Bu yarışma sayesinde basic'in bazı buglarını da bulmuş oldum. Onları da tecrübe olarak paylaşmak isterim.
Bir çok dilde floating point math problemleri klasiktir. Örneğin 0.1 ile 0.2'yi topladığınızda 0.3 elde edemezsiniz. Bunun yerine 0.30000000000000004 gibi bir şey elde edersiniz. Bu bug değil "by design" olarak açıklanabilecek bir durumdur. CBM basic değişkenleri daha düşük bit kapasitesinde tuttuğu için bu tür bazı problemler daha bile az görülebiliyor. Örneğin CBM basic'de .1+.2 tam olarak .3 olarak ekrana yansıyor. Ama arkaplanda daha ciddi problemler var.
Aşağıdaki javascript örneğini ele alalım.
https://jsfiddle.net/v2syq3ev/0.1=0.1
0.2=0.2
0.1+0.2=0.30000000000000004
cos(0)=1
int(cos(0))=1
Görüldüğü gibi 0.1 ve 0.2 ayrı ayrı düzgün yazılırken toplamlarında küsürat hatası oluşuyor. Ama cos(0) gibi sonucun 1 olması gerektiğini bildiğimiz değerler 1 olarak yazılıyorlar ki değeri integer'a cast ettiğimizde de sonuç olması gerektiği gibi 1 çıkıyor.
CBM basic'de ise sonuçlar aşağıdaki screenshotlardaki gibi.
Özetle CBM basic'de küsürat hassasiyeti düşüklüğünden dolayı .1+.2 tam olarak .3 olarak ekrana yazılırken ekrana normalde sonucu 1 olarak yansıyan cos(0) ya da sin(PI/2) gibi değerler integer'a cast edildiklerinde değerleri 0 oluyor. Yani aslında ekrana yazdırılan değerler ile floating point olarak hafızada tutulan bit değerleri tam örtüşmüyor. int() fonksiyonu hatalı kodlanmış olsa bile 0 ile orladığımız takdirde bit tabanlı işlemden sonucun 1 çıkması gerekirdi.
Bir diğer sorun goto, gosub gibi komutların değişken parametre alamaması. Zamanında Simon's Basic'i incelediğimde "cgoto" komutunu görüp anlam verememiş, farkını anlamamıştım. Meğer o baştaki "c" "calculated"den geliyormuş. Basic dilinin normal goto komutuna bu özelliği kazandıran bir program buldum.
10 for x=0 to 94:read a:poke 832+x,a:c=c+a:next
20 if c<>10356 then print "bad checksum":end
30 sys832
40 data 169,75,162,3,141,8,3,142,9,3,96,32,115,0,201,137,240
50 data 10,201,141,240,18,32,121,0,76,231,167,32,142,3,169,167,72
60 data 169,174,72,76,163,168,169,167,72,169,174,72,169,3,32,251,163
70 data 165,123,72,165,122,72,165,58,72,165,57,72,169,141,72,32,121
80 data 0,32,142,3,32,163,168,76,174,167,32,115,0,32,138,173,32
90 data 247,183,201,250,176,1,96,76,8,175
Bu program goto'nun hesaplanmış parametre alabilmesini sağlıyor. Aşağıdaki programı bir commodore'u ilk açtığınız gibi, bir de yukarıdaki programı çalıştırdıktan sonra deneyin.
10 print"cgoto test":a=40:b=4
20 gotoa/b
Bu yarışma boyunca bir diğer karşımıza çıkan problem ASC("") komutunun 0 yerine ?illegal quantity error vermesiydi. Bu böyle mi olmalı derseniz hayır, diğer basiclerde böyle bir hata vermiyor, 0 döndürüyor. Peki bunu nasıl fixleyebiliriz. ROM'u fixleyemediğimiz için basic ROM'unu RAM'a aktarıp, sonra bu durumu fixlemek mümkün. Aşağıdaki tek satırlık kod bu işi yapıyor.
0 fori=40960to49151:pokei,peek(i):next:poke1,54:poke46991,5
Bu kodu çalıştırmadan önce ve çalıştırdıktan sonra aşağıdaki satırı çalıştırmayı deneyin.
printasc("")
Zaten bu tür buglar, eksikler biliniyor, sonraki CBM basic versiyonlarında bir kısmı fixlenmiş durumda. C64 için de basic'deki çeşitli bugları fixleyen patchler mevcut. Ben bu örnekleri bu yarışma süresince gözüme çarpan basic buglarından birkaçı olarak burada paylaşıyorum.
Mesajları Göster
sanırım bu 640x480 256 renk modunu tamaman uçurmuşlar. son commitlerde böyle bir değişiklik de göremedim ama bir biçimde patlamış gibi gözüküyor.
Assembly karşılığı ise %0.03 yani on binde üç yiyor. Arada 500 kat falan hız farkı var. Projenin amacını ben de tam anlayamadım ama işin içinde "veri transferi" lafı geçiyorsa basic o konuya helper tool olarak bile yaklaşmamalı. Basic'in tek görevi bir adet SYS ile sınırlı kalmalı.