Microchip'i C keel

[tvtv]

Et siis midagi sellist? Aga üldiselt, spetsiifilise probleemi jaoks on spetsiifiline lahendus tavaliselt tõhusam kui universaalne lahendus. Kui sul on vaja sprintf-i ainult ühes kohas, siis on olemas arvatasti mingi tõhusam asi, mis sama töö ära teeb võttes seejuures oluliselt vähem ruumi, kui isegi ära nuditud sprintf. Ja endiselt soovitaks kiigata korra fixed point aritmeetika poole (ujukoma arvudele su PIC ju nagunii mingit riistvaraliset tuge ei oma).

[ahelet]

C-keel ei ole üldse microchipi tarbeks tehtud. Algselt tehti kõigile teistele mikroprotsessoritele C-keele translaatorid ära ja siis lõpuks kuidagi moodi sai ka microchipile C-keele translaator tehtud.
Põhimõtteliselt on C-keeles tehtud hex pic-le 6x (tervelt kuus korda) pikem, Muutuja registreid kasutatakse samuti 6x rohkem, kui vaja oleks, ja toimimise kiirus on ka 6x aeglasem, kui assembleris normaalselt kirjutatud hex.
C-keele translaatorid ei tunnista bit orienteeritud käske, s.t. kui assembleris oleks vaja ühe sisendi oleku kontrollimiseks 1 rida, siis C-keele transleeritud variant teeb sama töö ära 4-reaga.(C-keel teeb terve 8byte registri võrdlemise AND abil .) .Siis on veel see banking, assembleris muudetakse normaalselt bankingut ainult siis kui on seda vaja teha, ehk kui vajalik register asub teises pangas, aga kui järgmine käsk tahab ikka veel sellest pangast, kus eelmine oli ja järgmine jne, siis assembleris pole ju vaja vahepeal minna pank 0 tagasi ja siis uuesti pank4 jne. aga C-keel muudab automaatselt panka igaks juhuks kogu aeg, aga see on ju raiskamine , iga käsu kohta 2või rohkemgi käske sõltuvalt protsessorist ja pankade arvust.
Kui tahad C- või Basic keeles pic-e progeda pead enne assembleris pic sisu selgeks saama , siis võib oma C või basic kasutada, muidu oled igaljuhul jännis. Natukenegi keerulisemaid või kiiremaid asju sa ei saagi C-keeles tegema, sest see õgib ressursi lihtsalt ära.
C-keeles tehtud transleeritud assembleri vaatamine on lihtsalt õudne, kuidas võib nii teha.

[tvtv]

Mul pole mingit kogemust konkreetselt PIC-i kompilaatoritega, aga võtaks nende kaitseks siiski sõna. Vähegi suurema programmi puhul on inimene tunduvalt viletsam optimeerija kui masin. Mida suurem programm seda enam. See 6x suurem programm võrreldes käsitsi kirjutatuga tundub ebareaalne. Ehk ainult juhul, kui optimeerimine täiesti maha keerata või kirjutada C-s programm mingil väga ebanormaalsel viisil. Lõpeks pole ju kompilaator mingi ime-relv, ta täidab lihtsalt programmeerija käske ja teisendab tema antud instruktsioonid masinkoodi. Seejuures on tal üsna vähe mänguruumi, tulemus peab olema ekvivalentne sellega mis algselt kirjas. Ei ole võimalik kusagilt nurki süüa ja mõelda, et nii võib ka teha... pole küll päris see, mis kirjas lähtekoodis aga antud juhul on see see, mida programmerija tahtis. AFAIK on ka "lite" ja "student" versioonid C-kompilatoritest ära nuditud, et täis-versioon oma hinda õigustaks.

[ahelet]

Vaidleks vastu, just selles see asi ju ongi, et sama asja saab teha vägagi erineval moel. Ja siinkohal need igasugused c-keele ja basic ja muud asjad just mitte kohe ei hiilga. Kui on vaja midagi suht lihtsakoelist teha, siis pole c-keel mine ta, ehk isegi mitte paha, lausa flowcodega saab teha, see on veelgi lihtsam, kui c-keel. Aga niipea, kui on vaja teha midagi kiiret ja tõsist, on nende c-keele asjadega probleemid. See 6x (täpsemalt 5,8x) ei ole mul lambist võetud, oleme teinud rohkem, kui 1 katset, sama ülesanne, üks mees teeb assembleris, teine teeb C-keeles või kolmas teeb basic-us. Ja tulemuseks on ca 6x erinevust. Tõsi küll, igal medalil on ka teine pool, kui assembleris kulub sama asja tegemiseks programeerijal ca 3 päeva, siis c-keeles saab asja ära teha 1 päevaga. Keerukamate asjade juures võib ka 6x aja kulu vahe vast olla, (ega assembleris rs232, i2c, spi, ja muude igasuguste protokollide kasutamine pole teab mis lihtne ülesanne.) C-keeles on selle jaoks n.n. librarid, ehk siis valmis toorik klotsid, anna käsk sisse ja teeb ise asja ära. Ka siin on sedasi, et kahjuks need librarid ei oska vahetevahel kõike teha, näiteks sd kaarti kasutamine selliselt, et töötaks korraga nii fat16 ja fat32, et pole vahet milles formattitud sd kaarti lugejasse lükkad, et pic loeks mõlemat samaväärselt, sellega on c-keelel probleeme, saab leida kas fat16 või fat32 librarit, aga mõlemat korraga pole. Ag ahea küll, ma kaldun arvama, et c-keel on hea neile, kes tegelikkult ei tea, ega tahagi teada, mis pic sees tegelikkult toimub ja kuidas see asi töötab. Ja veel on selline tõsiasi ka, et kahjuks on pic taktsageduste ülempiir tänapäevaste rakenduste jaoks madalavõitu, ca 40 Mhz, aga kui x6, siis ei saa hakkama ja peab kas mõne muu tootja asjaga tegema või assembleris. Ja veel kaldun ma arvama, et parim on teha segamini, nii, et c-keele sisse on pandus assembleris tehtud klotse, see annab parima tulemuse ja kompromissi, aga eeldab ka eriti hea mõlema keele tundmist.

[tvtv]

See on teema, millel võib lõputult vaielda, aga ma jätan selle osa vahele, ja postitan siia hoopis ühe üldhariva loengu, mis olukorda ehk selgitab. Loeng on pikk (1.5h), inglise keeles ja loetud ühel Java-konverentsil. Mõned väited loengus (eriti selle alguses) võivad selle foorumi rahva küll veidi närvi ajada aga varuge kannatust ja arvestage, et loeng on suunatud pisut teisele auditoorimuile. Loengu mõte on aga suuresti see, et töötades mingil abstraktsiooni tasemel (näiteks C) on vägagi abiks, kui sa tunned ka neid abstraktsioone, mille see baseerub (ASM ja riistvara näiteks). Ehk, kui sa tead, kuidas töötab kompilaator ja kuidas töötab riistvara ja assembler, siis on võimalik ka C-s efektiivselt toimetada. Teisiti öeldes - eeldus, et ainult C tundmisest piisab, on lihtsalt vale.

[A.R.]

Kas on hea olla terve või rikas?
Hea on olla terve JA rikas.

Lugesin siin seda juttu ja kirjutasin ühe proovitesti.
_________________________________________
#include <p18f4550.h>
#include <math.h>
#include "user\vajalik_lisa.h"
//char input_buffer[64];
char output_buffer[64];

float a1=3.5;
float a2=3.55;
float c,s;
float d,l,p;
double dp,dx,dy;
long double ldp, ldx, ldy;
***********************
void main( void )
{
InitializeSystem();
c=a2*a1;
s=sqrt©;
l=log©;
dp= pow(dx,dy);
ldp= pow(ldx,ldy);

if(mUSBUSARTIsTxTrfReady()){
sprintf(output_buffer, (const far rom char*)"%c %d %f", 'X', dp,c);
mUSBUSARTTxRam((byte*)output_buffer,strlen(output_buffer));
}
}
*********************
Transleerub ja vast ka töötab kui ta PICi kirjutan.
hex on 63 kb.
Kui kaua tuleks kirjutada seda asmis et siis saada 10 kb?

Kas selleks et PICi kasutada pean ma teadma kõiki masina peensusi?
Kunagi sai kirjutatud programmi nõelaga paberlinti bitte torkides. (5a)
Sai kirjutatud assembleris ja fortranis. (5-7a)
Sai kirjutatud oma Basic+C segatranslaator ja kasutatid (jälle 5a)
ja siis edasi 25 a C-s.

Palju läks nüüd selles vanast kogemusest vaja?
Kui mul oleks mäluprobleem, kui oleks vaja kiirust,
kui programm ei tööta
- siis jah.

/*
Oli mingi databaas. Ei tunnistanud Eesti tähti.
Tuli üks bitt & maskis ära muuta ja kõik käis. See oli töö bitteditoriga.

Tuli mahutada 256 baidile OPsüsteem, katkestused ja ketta test.
"Normaalne" programm oli üle 350 baidi.
Minu õpetaja Mait Sarv õpetas et igat programmi saab teha ühe käsu võrra lühemaks. Surusimegi kokku.
*/

Kui ON vaja, siis tasub näha vaeva.
Aga hea on olla porilaisk ja kasutada rohkem mütsialust ruumi
et mitte teha tööd.
Mõttetut tööd.
____________________
Tegin siis ka natuke asjalikku tööd ja masin ütleb:
Program Memory Usage : 9990 bytes 7,6 % Full
Data Memory Usage : 725 bytes 1,1 % Full
Mille kuradi nimel ma peaks hakkama programmi kokku suruma?

[Teemo]

Selle viimase näite kohta ütleks, et mingit suvalist asja tundub C-s väga hea teha küll. Näiteks matemaatikat. Samas, reaalselt ettetulevaid ülesandeid on assembleris kergem lahendada, eriti selle pärast, et saab mõnusalt ära kasutada PIC riistvaralisi sisseehitatud lisasid. Eriti mõnus oleks muidugi teha põhiprogramm asmis ja siis matemaatika C-s juurde. Aga see nõuab jälle mõlema korralikku oskust, või siis oskust C-le asemmbleris ise funktsioonie teha, ehk siis ise C kompilaatori valmistamise oskust. Sellepärast on paljud asjad lihtsam asmis ära teha ja mitte hakata selle pärast C kompilaatorit leiutama.

[A.R.]

Eks ta õige ole et kui ei oska siis ei saa.
Aga kui on omandatud mingi keeleloogika siis järgmise keele omandamine
pole eriti keeruline.
Mis aga puutub C-d siis vajadusel võib see sisaldada ka ASM käske.
Kunagi, 1985, katsetasime võimalust teha PC exe failist tagasi C lähteteksti.
Oli võimalik, lahendatav vahetusega blokk bloki vastu.

Mis aga puutub seda et LEIUTADA C translaator siis seda pole vaja.
Juba toll 85. oli olemas PC C ja MASM (makroassembler).
Ainult et siis ei olnud alati ühendust kahe eri tüüpi arvuti vahel ja tuli selleks aparatuur ehitada.

Kui võtta hommikul C kirjeldus siis tunni pärast saab juba aru kuidas need näited töötavad.
Õhtuks on aga tegu noore C spetsialistiga.

Seal C-s on vast kõige suurem probleem hoolikus ja tähelepanu.
Tekstis ei lubata ebakõlasid. Aga antakse ka hoiatusi kus mis mäda on.

Samas, ega ei pea midagi uut õppima.
Kunagi algas matikutel suur sõda et programmis ei tohi olla goto käsku.
Kui aga selle gotovaba programmi disasmi vaadata siis pole asi nii roosiline.
Ja kui ikka kasutad, siis vangi ei panda.

[Teemo]

Probleem on jah, et kui ASM juba üsna käpas, aga C-d ei oska, siis kipud tegema ka selliseid programme ASMis mida C-s oleks hulga lihtsam teha(kui oskaks). Et tegelikult tuleb sama välja, kui õpiks nädal aega C-d ja teeks C-s programmi, või siis programmeeriks ASMis nädal aega ja saaks ka programmi valmis. Esimesel juhul on boonuseks, et saab C ka selgeks, teisel juhul on boonus, et see konkreetne programm saab parem (kiirem, ökonoomsem).

Mingil hetkel tuleb asmiga muidugi piir ette, mingeid asju ei saa teha. Siis vaja mingi uus loogika/keel selgeks õppida.

[A.R.]

õpiks nädal aega C-d ja teeks C-s programmi, või siis programmeeriks ASMis

Kui võtad mingi sarnase näit ette ja katsud aru saada siis, tunni pärast juba teed täiendusi. Katseta. Kiikad natuke manualist juurde ja asi areneb.

Ega need kõrgkeeled pole ELFA poe vale aadress mida poole aastaga muuta ei saa ja millest rääkida ei tohi.