ASSEMBLY, C, PicBasic, MicroC, E vs.

[hasangurlek]

z hocamın açtığı başlığı kirletmek istemediğim için konuyu bu bölüme yazmayı uygun gördüm.

Böyle bir oluşum, birliktelik söz konusu olmamakla birlikte cins gurup nedir ?
komodor kasetlerini teyplerde incelemeye çalışmış ,
ilk olarak 8086 işlemcili bilgisayarları görmüş,
IBM in Türkiyede cirit attığı dönemde 4-5 bin dolarlık 386SX33 makinelere "vay be bilgisayara bak" demiş,
Qwbasic in satır numaralı kodlaması ile programcılığa başlamış,
borlandın pascalı ile veritabanı tutmayı becermiş, fortran ıda kullanmış,
dos komut setindeki diskcopy komutunu devre dışı bırakmak için diskete özel yazdığımız format komutuyla 81. izi formatlamış ve program başladığında bu eksta 81. ize dallanması sağlanarak kopya disklerin çalışmamasını sağlamış, (Format komutu diskette 80 iz oluşturur ve diskcopy bu 80 izdeki bilgiyi diğer diskete kopyalardı)
bazı kodların yazıldığı dil nedeniyle derlenmeden interpreter kullanılarak çalıştırılması zorunluluğunu yaşamış,
VB ile PC tarafında rahatlığı görmüş, bu nedenle C++ yı rafa kaldırmış, .NET serileri ile tekrar C yi bilgisayarına kurmuş,
tersine mühendisliğin kaldırım versiyonunu icra etmiş bir guruptan bahsediyorum.

Bizim gurup için diller ve donanımlar birer araçtır, hiç bir zaman amaç olmamıştır. Bizler yazdığımız kodların içine feykler gömeriz ki dis edildiğinde çözümlemek için fazladan zaman harcansın veya projeyi geliştirip çalıştırdıktan, yatırımcısına para kazandırdıktan sonra sudan sebeblerle (50-100 lira daha az maliyetli eleman bulmak gibi) işten atıldığımızda değerimiz anlaşılsın. Ve hatta donanımı kullanmak yerine öncelikle ciğerini görmeyi isteriz. Çünkü her donanımın insanlar gibi hayatına devam edebilmesi için bir cigeri mutlaka vardır. Siz buna ister rom diyin, ister eeprom, ister CPU, ister gizli veya açık bios yazılımı. Bu konuya örnek olması açısından laptop bataryaları ile ilgili başlığa göz atabilirsiniz.

Hiç bir programcı gurup üyeleride dahil, derleyici geliştirici veya donanım geliştiricisi bizim bu cins gurubun düşünme mantığını, algoritma geliştirmesini, kod yazım mantığını hemen kavrayamaz. Ne yapıldığının çözülebilmesi için üzerinde uzun süre çalışılması gerekir. Yazdığımız program süresince içtiğimiz çay, kahve ve sigaradan yüzlerce kat daha fazla tüketilmesi, daha uzun süre aç ve uykusuz kalınması gerekir. Beyinlerimizin ORG 0x00 gibi bir start adresi, 0x18 gibi bir kesme adresi yoktur, düşünmeye tersten, ortadan herhangi bir yerden başlayabilir, herhangi bir anda kesme oluştuğunda yönü herhangi bir adrese dönebilir. İyilerimiz 3 kuruşa talim ederken, kötülerimiz köşedir.

Bir kaç örnek sorun ve cevap yazalım;

PIC18F4550, peki niye bu ?

Aslına bakarsanız bir Amerikan firması olması nedeniyle antipati duyduğum bir marka microchip. Ama üretim çeşitliliği ve gelişme hızı ile birlikte kısa zaman içinde dünya pazarında 2. sıraya yerleşmesi beni bu markaya ister istemez itiyor. Bu görüş sadece beni bağlar.

Örnek1 : Her MCU kodu mutlaka yazılımın kontrolü için kontrol bitleri tanımlayacaktır. Programcı assembly ile veya C, Basic vs. derleyicileri ne yapar ? Bir bayt değişken tanımlar, ardından bu değişkenin 8 bitini kontrol biti olarak tanımlar ve kullanır. Yetmiyorsa bir bayt daha ve yetmiyorsa bir bayt daha.

Cevap1: Biz ne yaparız ? Mesela USB kullanmıyorsak 16 tane 5 bit uzunluğunda kontrol bitimiz hazırdır UEPn(0-15) x 5 = 80 bit, her yazılıma yeter, Data belleği kullanımı = 0. Önemlisi ve işin güzeli ise bu bitlere her banktan ulaşmak. SFR lere her banktan ulaşabilirsiniz. Data belleğinin büyük bir çoğunluğu gibi değildir.

Örnek2 : Her MCU kodu mutlaka bekleme rutinine bir şekilde ihtiyaç duyar. Programcı assembly ile veya C, Basic vs. derleyicileri ne yapar ? Gerektiği kadar baytı bu iş için tanımlar ve kullanır.

Cevap2: Biz ne yaparız ? Kullanmaya hazır, EEADR, EEDATA, TMR0L, TMR0h vs. vs. o an için veya program boyunca kullanmadığımız bir sürü özel fonksiyon kaydedicilerinden bir kaçını seçer işimizi görürüz. Data belleği kullanımı = 0.

Örnek3 : Her programcı yazdığı kodlara geri dönüp bakma ihtiyacını hisseder. Bu ihtiyaç hata durumundada ortaya çıkabilir veya önceki yazdığı kodu tekrar kullanmak istediğindede kodları inceler durur.

Cevap 3 : Biz ne yaparız ? Yazdığımız her kodu kütüphane dosyaları içinde alt rutinler olarak saklar, gerektiğinde tek satırda projeye ekler ve kullanırız. Kullanmak istediğimizde sadece dosyayı projeye dahil edip etmediğimize bakarız. Eklediğimiz dosyalarda hata aramayız, çünkü kodları yazan zaten bizizdir.

Örnek4 : Ortaya yazılımsal bir hata çıktığında; komut kullanımlarından, mantık hatalarından, derleyici hatalarından herhangi biri sebep olmuş olabilir. Komut kullanımı ve mantık hatalarının kaynağı programcıdır ve kendi bir şekilde kısa veya uzun zaman harcar ve çözer. Ancak derleyicinin versiyonundan kaynaklanan bir ek dosya hatası ise çözmesi neredeyse imkansızdır. Başkalarının yazdığı, hayatında görmediği bu ek .h .c. inc veya başka uzantılı dosyalarının içinden çıkamaz. Ya hata olan kodu bulacak, ya eski derleyiciye dönecek, yada yeni versiyonu bekleyecek. Buna benzer bir proteus tanımlama hatası

Cevap4 : Bizim düşüncemize göre yazılan her kod ilk seferinde kesinlikle düzgün çalışmaz. Eğer çalıştıysa ilerde büyük bir sıkıntı çıkartabilir. Kod ilk seferinde çalışşada çalışmasada yazılan her kod kütüphaneye eklenmeden ilk yazımda didik didik edilir, hata varsa ilk aşamada bulunmuştur.

Örnek5 : Kod taşınabilirliği, ANSI C aslında ön plana çıkartılması gereken şeyler değildir. Hiç bir yazılımı üzerinde köklü oynamalar yapmadan başka bir ortama taşıyamazsınız. Başka bir ortama taşıma ihtiyacı ortaya çıkarsada bilinmelidirki bu ihtiyaç tamamen geliştiricilerin ve/veya yatırımcıların hatası sonucudur. Yatırımcı her zaman haklı çıkacağına göre tek sorumlu programcı olacaktır. Durduk yere kimse atmel işlemci kullanırken motorola ürünü kullanmaya kalkmaz.

Cevap 5 : Ne yapılmalıdır ? Şartlar sizi daha küçük kapasite kullanmaya zorluyorsa, başka bir üreticinin aynı fiyata sahip mesela daha çok porta sahip yada USB, CAN vs. gibi daha fazla özelliğe sahip daha gelişmiş bir işlemcisini seçebilirsiniz. Buda olmuyorsa kartınızı tasarlarken ileride geliştirilecek yazılımın sığmayacağı düşüncesiyle ilave edilecek kodları yerleştireceğiniz ve üzerinden çalıştırabileceğiniz yani ek rom olarak kullanabileceğiniz elemanlardan bir tanesini ve/veya 74HC259 gibi yüksek hızda port çoğullayabileceğiniz bir elemanı kullanabilecek şekilde tasarlayabilirsiniz. Devre çizimleri ve PCB başkaları tarafından tasarlansa bile hiç bir zaman programcıdan bağımsız çalışamazlar. Diyelimki ortam değişimi şart. Ne olacak ? Niye isimler TRISC, niye ADCON0 olsunki ? Hiç bir zaman .inc dosyalarındaki eşitlemeleri kullanmayın ! Mesela IOT3 EQU TRISC (veya TRISC nin direk adresi) tanımlaması size TRISC yi IOT3 (Input+Output+Tris) olarak veya sizin belirleyeceğiniz isimlerde kullanmanıza imkan tanır. Taşınırken eşitlemelerin karşısındaki TRISC yi veya adresi değiştirmek yeter. Sonuçta yazdığınız kod derlenirken hepsi sayısal değerlere döndürülecek. Komutları ise CTRL+H +"Tam Eşleşme" +"Tüm Proje" ile halleder geçersiniz.

Örnek6 : Efendim assembly çok az komuta sahip. Bunun için kullanımı ve öğrenmesi çok zor.

Cevap6 : Hayır efendim. Artık hiç kimse not defterinde assembly kodlamıyor, herkes MPLAB gibi bir editöre sahip. Her editör makro kullanımına izin veriyor, derleyiciler makroları istendiği gibi derliyor. Mesela 18 serilerinde MOVFF ile bir bellek alanındaki içeriği diğerine taşıyabiliyorsunuz. Ama sabiti bir bellek alanına atayacak bir komut yok. Çözüm çok kolay : Makro oluşturmak;

MOVLF Macro Degisken1, Degisken2
MOVLW Degisken1
MOVWF Degisken2
EndM

makrosunu tanımladıktan sonra işte size tek satırda kullanabileceğiniz bir komut daha;

MOVLF 0x55,PORTC

demeniz yeterli. Hatta olayı abartıp

LCD_YAZ Deg1,Deg2,Deg3,Deg4,Deg5

vb. makroları picbasic kullanır gibi kullanabilirsiniz. Makro kullanımında dikkat edilmesi gereken olay derleme esnasında her makro satırı altında kodların tekrar tekrar kullanılmasıdır. Bunun için makroyu oluştururken ortak kullanılan işlemler CALL ile çağrılmalıdır.

Örnek7: Degisken = 1/(((a+b)*c)/d) işlemi için assembly de işin içinden çıkamıyorum.

Cevap7: Eğer matematik işlemleri için kütüphaneye sahip değilseniz, öncelikle oluşturun. Olmadı MPLAB direktifleri size yeter. MPLAB yardımını açın ve inceleyin. Ayrıca ENGR2210.INC diye hazır bir makro dosyası var, netten bulun ve inceleyin. Karşılaştırmalarda makro kullanımına en iyi örnektir.

Assembly dedemden büyüktür, Basic babamla yaşıt C ise benden küçüktür. Babam ah keşke babam hayatta olsaydı der, ben Allaha şükür babam yaşıyor ama kıymetini değerince veremem. Kıymet bilenindir.

Bizler makinelere iyi davranmayı severiz, onlarda bize iyi davranır Çoğunlukla 50, 100, 1000 gibi sayıları kullanmak yerine 64, 128, 1024 gibi sayıları kullanırız. Bu sevgi hem bize kod yazma kolaylığı sağlar, hemde makineleri coşturur.

Diyelimki AD çevrimle veya başka bir kanaldan toplayacağınız uzun boyutlu bir veri girişinde toplamı 4 bayt kapasitede tutulabilecek bir işlem olsun. Girişlerin hepsi üst üste toplansın ve ortalaması alınsın. İşte aşağıdaki kod 65536 defa yapılmış bir ölçümün ortalamasını alıyor. Hemde hiç data belleği kullanmadan ve 114 komut saykılında. 48 mHz de çalışan bir MCU için sadece 9,5 mikro saniyelik (9500ns) bir süre.

BCF          STATUS,C
MOVLW     0x10
MOVWF     EEADR
RRCF        TMR3H
RRCF        TMR3L
RRCF        TMR1H
RRCF        TMR1L
DECFSZ    EEADR,F
BRA       $-0x0A

"Ya bu SFR olarak adlandırılan kaydedicileri kullanmayı bugüne kadar niye düşünmedik" demeyin, zaten kullandığınız MCU yeterince data belleğine sahiptir ve size yetmiştir. Ve ayrıca bu tip yazılım geliştirmeyen kişinin bir tek siz olmadığınız düşüncesiyle rahat olabilirsiniz ama ya toplanan sonuç 4 bayta sığmadıysa ? data belleğinde TMR3H yerine kullandığınız değişken taştığında size kesme üretemez. Taşmayı takip etmek için biraz daha kod yazarsınız

Buda makine diline derlenmiş hali;

90D8
0E10
6EA9
32B3
32B2
32CF
32CE
2EA9
D7FA

Eğer gün gelirde bu yapıda bir kodu herhangi bir derleyici üretebilirse o zaman o derleyicinin dilini öğrenmeye veya tekrar kullanmaya başlayabilirim.

Buraya kadar okuyabilenlere teşekkürler, inanın yazmak 1 saatimi aldı Okuyanlara faydalı olması ve tüm arkadaşlarımın bu cins gurupta olması dileğimle.

[bigbey]

Emeğine sağlık düşüncelerimi tanımlıyor. Geçmişi yaşadım yazıyı okurken.

[PROTECH_]

ellerinize sağlık hocam bir saatiniz boşuna gitmemiş, yazdıklarınızı keyifle okudum...

[cenkishan]

Eline klavyene sağlık hocam harikasın.Hani söylemek istersin cümle bulmazsın ya işte sen hepsini yazmışsın tebrikler.

[remzi]

Eline sağlık hocam büyük bir zevkle okudum...

[dijital74]

Yazdıklarınızı gecenin bu saatinde (01:30) uykulu gözlerle fakat büyük bir keyifle okudum. Devamını beklerim.

[z]

Burayı ben de sevdim.

ASM aşığı tabiri aslında biraz yanlış oldu. Bizler asm den çok çipe aşık oluyoruz gibime geliyor. Böyle olunca da insan sevgilisinin dilinden konuşmalı.

Aslında cpu üzerinde kod geliştirenleri daha en baştan ikiye ayırmak gerekli ve adamına göre davranmalı.

Bu adamlar;

1. Elektronikçi cpu kullanıcıları
2. Yazılımcı cpu kullanıcıları

Yazılımcı kullanıcılara yukarıdaki yazdıklarınız hiç ama hiç bir  şey ifade etmeyecektir.

Zaten sorun da burdan kaynaklanıyor.

Adamımız mikrosaniye nedir nano saniye nedir bilincinde olmalıki hızlı koşan koddan bahsedildiğinde sizi anlasın.

Bu arkadaşa ARM da versen DSP de versen dayayacaktır her iki kod satırı arasına delay_ms(10) u.

Eee ne oldu. C ile hızlı bir işlemciye kısa zamanda kolayca kod yazmış oldu.

Halbuki timing diagrama baksa iki sinyal arasında olması gereken birkaç yüz nanosaniyelik bilemedin 1 mikrosaniyelik geçikmeyi tek NOP la bitiriverecek.

[Eagle_Tim]

Güzel bir yazı olmuş ellerinize sağlık..

[z]

Dos zamanında ekranda yüksek hızda grafik çizmem gerekiyordu.

8086 asm bilmeme rağmen PC bios rutinlerini açıklayan dokumanım yada  programım yoktu.

Grafik çizmek için basicden başka seçeneğim de yoktu. Basic de hız açısından işime gelmiyordu.

C bilen  arkadaşım ben sana basicden çok daha hızlı grafik çizen program parçası yazayım dedi ve yazdıda. Sonra da asm falan hikaye pixeller işte bu kadar hızlı çizilir dedi.

Arkadaşın yazdığı exeyi bir kaç gün sabahlara kadar debug ile tek tek adımlattım ve nihayetinde ekran kartına ait grafik  rutinlerini köşeye sıkıştırdım. Bu esnada PC yi belki de 500 kere kitleyip restart etmişimdir.

Program biosa dalıyor ve kodlar başlıyor sormaya.

Bios int numarası ne?
Int no bu.
Peki AH ne AL ne?
Bu.
Peki Biosda şu adresde şu varmı? (Grafik kartı varmı)
var.

Geliniyor Ekran rutinlerinin bulunduğu bölüme.
Gene başlıyor sormaya
AH ne AL ne
şu ne bu ne....

Grafik kartımı siyah beyaz mı renklimi?
Renklimi tamam oyleyse kaca kac?
Kac renk?

Ardından 6845 registerleri tek tek yükleniyor. Ve kart grafik moda geçmiş oluyor.

Sıra geldi ekrana geldi pixel koymaya her pixel koyma aşamasında bunlar tekrarlanıyor. Program biosa dalıyor ve kodlar başlıyor sormaya.

Bios int numarası ne?
Int no bu.
Peki AH ne AL ne?
Bu.
Peki Biosda şu adresde şu varmı? (Grafik kartı varmı)
var.

Geliniyor Ekran rutinlerinin bulunduğu bölüme.
Gene başlıyor sormaya
AH ne AL ne
şu ne bu ne....

Grafik kartımı siyah beyaz mı renklimi?
Renklimi tamam oyleyse kaca kac?
Kac renk?


Ardından pixel konacak ramın fiziksel adresi hesaplanıyor, pixelin byte içindeki bit sıralaması tespit ediliyor kartta bir kac registere yükleme yapılıyor ve hoop pixel oluşuyordu.

Tabi bu sonuca ulaşabilmek için yaptığım tersine işlemleri varın siz düşünün.

Hemen assemblerda grafik kartın ilgili registerlerine tak tak yüklenmesi gereken verileri yükledim.

Grafik kartın çalışacağı moda (pixel sayısı, renk sayısı) uygun en kısa adres hesaplama rutini üzerinden pixelimi koydurttum.

Bunun için hiç bir şey sordurtmadım. Şuraya şuraya bunu yükle ve çık.

Sonuçta C sever arkadaşım hayretler içinde belki yazdığı grafik rutininden 20 kez daha hızlı grafik çizim rutininin yazılabileceğini gördü.

Ha bu şimdi asm nin gücümü? Hayır Benim yaptığım işlerin aynısını o da C de yazsaydı hemen hemen aynı hıza ulaşacaktı.

Ama daha baştan kaybediyordu. C de pixel koyan hazır C kütüphanesi  vardı. Adamlar oturmuşlar yazmışlar ben ondan daha iyisini mi yazacağım düşüncesinde. Ama hız ihtiyacın varsa ne olacak?

Tamam C kütüphanesi her PC de her grafik kartında sorunsuz çalışması için yazılmıştı ve benim  exem taşınamaz sadece benim PC ye özgüydü. Ama pixellerim havada uçuyordu....

[camby]

@hasangurlek , @z
Elinize sağlık , yazılarınız çok iyi..