Nybörjarlitteratur programmering i C

[datajompa]

Så folk som vill lära sig köra bil rekommenderar du alltså att börja med häst och vagn för att lära sig grunderna? Det där med att rekommendera assembler som första språk är i dagens läge bara snobberi.

Nej, när det gäller att lära sig C rekommenderar jag assembler för att spara tid.

Jag rekommenderar inte assembler vare sig som första eller sista språk utan som språket innan C.

Jag har programmerat många olika språk av olika slag och tycker om C och lågnivå. Men de kniviga problem man har med C-kod brukar nästan alltid ligga på assemblernivå. När man debuggar C så debuggar man assembler i de flesta fall, till skillnad från i högnivåspråk (dit jag inte räknar C++). Det är ganska svårt att få grepp om lågnivå genom att programmera C, men det är lätt genom att programmera assembler. Jag har också sett otaliga människor försöka lära sig C som första språk och ge upp på grund av pekare och minnesallokeringsfel, eftersom de aldrig lyckas förstå själva grundkoncepten. Båda sakerna exponeras på ett direkt och lättbegripligt sätt när man programmerar assembler, och det är mycket lätt att gå från den "konkreta handfastheten" i assembler till det lite mer abstrakta men kraftfullare C. Att gå åt andra hållet är svårare rent mentalt.

Det mesta av det enkla med C fungerar likadant men bättre i högnivåspråk som Python eller Javascript. Allt det krångliga fungerar dock som i assembler, men är mindre tillgängligt.

[TomasL]

Eftersom Assembler inte är ett språk, är det tämligen onödigt att lära sig om man inte har specifika behov.
Dessutom eftersom Assembler är unikt för i princip varje processorfamilj, så måste man lära sig ett antal tusen olika varianter innan man kan assembler.
K&R är väl lite mer avancerad än ren nybörjare.
När jag började med C så hade leverantören av mitt första utvecklingssystem ett i mitt tycke bra "lärobok" för nybörjare: Learn C with FED. (fored.co.uk).

[datajompa]

Eftersom Assembler inte är ett språk

Så fort man diskuterar någonting med programmerare så blir anmärkningarna på språket det viktigaste! Faktum är att jag först skrev "språk" inom citationstecken och en parantes om att assembler inte är ett språk. Jag tog bort det för att hålla ner postlängden. Sedan funderade jag på att skriva "maskinkod" istället för assembler, eftersom jag insåg att det annars riskerade att bli sura kommentarer om att det var maskinnivån som var det viktiga och inte assemblerinstruktionerna. Men om det stått "maskinkod" skulle det ändå bli sura kommentarer om att det var stenålder och att det var stöddigt försök att skryta med hur lågnivå jag var.

Om inlägget istället hade garderat sig mot alla möjligheter till feltolkning så att det kompilerade utan varningar så skulle det istället ha blivit ett surt "tl;dr".

[SeniorLemuren]

Så folk som vill lära sig köra bil rekommenderar du alltså att börja med häst och vagn för att lära sig grunderna? Det där med att rekommendera assembler som första språk är i dagens läge bara snobberi.

Nej, när det gäller att lära sig C rekommenderar jag assembler för att spara tid.

När man debuggar C så debuggar man assembler i de flesta fall, till skillnad från i högnivåspråk

Nu får jag säkert en jävla massa skäll. (Ja ölen tog slut och solen gick i moln så jag är nere från flybridge nu)
Men va faan skall man debugga för överhuvudtaget. Många här på forumet pratar ofta om att använda debuggerfunktioner, varför det? Gör man ett väl planerat flödesschema och håller sig till det så funkar det till 99,99%.

Skulle det vara så att något inte blir som man tänkt, ja då är det fel på flödesschemat och det debuggar jag med penna och papper. Jag har aldrig löst ett programmeringsfel med att använda en debugger. På min tid som programmerare av Cobol så fanns inte ord som debugger ens i språket eftersom man var tvungen att vänta kanske flera timmar på att få sitt program kompilerat och tack vare det tvingades man att hålla det komplett strukturerat, samma sak med RPG2 osv.

[lillahuset]

När jag gick på universitetet hade vi en kurs i assemblerprogrammering för PDP-10. En av de roligaste kurser jag gått.

Lemuren: COBOL. Hela våran labbgrupp fick våra labbar godkända utan vidare av studierektorn som vikarierade för läraren. Sedan ville han visa oss APL.

[datajompa]

Debugga behöver ju inte bara betyda att använda en stegdebugger utan över huvud taget att plocka bort fel. I C-kod utgörs dessa fel väldigt ofta, i jämförelse med alla andra språk som någon skulle kalla högnivå, av problem med minneshanteringen, pekare, och stackhantering. Det är också saker som datorn kan hantera alldeles utmärkt på egen hand och som man därför slipper bekymra sig om i riktiga högnivåspråk.

Problem med flödet är ju en helt annan sak, och mycket enklare och mindre frustrerande. Syftet med ett högnivåspråk är ju att hålla sig i en miljö där det är flödet och logiken man debuggar. C är inte ett sådant språk.

[lillahuset]

Nåja. Även måttligt komplexa system med flera processorer mår ofta bra av en eller flera JTAG debugger(s) eller liknande. En brytpunkt säger ibland mer än 1000 ord.

Tillägg:

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”

― Brian W. Kernighan

[TomasL]

Så folk som vill lära sig köra bil rekommenderar du alltså att börja med häst och vagn för att lära sig grunderna? Det där med att rekommendera assembler som första språk är i dagens läge bara snobberi.

Nej, när det gäller att lära sig C rekommenderar jag assembler för att spara tid.

När man debuggar C så debuggar man assembler i de flesta fall, till skillnad från i högnivåspråk

Nu får jag säkert en jävla massa skäll. (Ja ölen tog slut och solen gick i moln så jag är nere från flybridge nu)
Men va faan skall man debugga för överhuvudtaget. Många här på forumet pratar ofta om att använda debuggerfunktioner, varför det? Gör man ett väl planerat flödesschema och håller sig till det så funkar det till 99,99%.

Skulle det vara så att något inte blir som man tänkt, ja då är det fel på flödesschemat och det debuggar jag med penna och papper. Jag har aldrig löst ett programmeringsfel med att använda en debugger. På min tid som programmerare av Cobol så fanns inte ord som debugger ens i språket eftersom man var tvungen att vänta kanske flera timmar på att få sitt program kompilerat och tack vare det tvingades man att hålla det komplett strukturerat, samma sak med RPG2 osv.

I lite mer komplicerade system, där till exempel ett RTOS är inblandat, där man har task-switchning och interruptstyrd exekvering så är en debugger ofrånkommlig, av den enkla anledningen att det inte går att göra ett flödesschema i traditionell mening över programmet,´för respektive funktion kan man göra det men inte för det hela, eftersom slumpen i princip styr när viss kod skall exekveras.

Datajompa, jag föredrar faktiskt benämningen maskinkod i stället för assembler, eftersom det är exakt vad ett assemblerprogram är.

Nog om det, eftersom det är C som gäller, så får man anta att det handlar om embedded, som alltid när det gäller denna typ av programmering så behöver man ha rätt bra koll på hur hårdvaran fungerar och varför den eventuellt inte gör som man tänkt.
Då kan det vara ra att ha grundläggande kunskap om maskinkodsprogrammering, dvs skriva in en massa mneonics på för processorn rätt sätt och låta en assemblator få omvandla dessa mneonics till maskinkod.
Dock ju mer komplicerad processorn är desto mer omfattande är det.

Men som sagts tidigare, C betraktas som ett lågnivåspråk, dvd så nära man kan komma maskin kod.

När jag höll på med PIC18 så hade jag hyfsad koll på maskinkoden, men nu när jag enbart jobbar med PIC32, så har jag i princip noll koll på maskinkoden.
Personligen så har jag/vi inte behövt debugga maskinkoden, utan debugging i C räcker till och blir över, och då är behovet av djupare kunskap i maskinkoden inte så stor, dock som sagt, har jag i princip hundra koll på hur maskinvaran fungerar.

[lillahuset]

Jag gillar att skriva "assembler" men inser att det är något man ska undvika i normalfallet. En bra C-kompilator generar ofta bättre "assembler" än man själv och det kan vara jobbigt för egot.
Däremot tycker jag det är en ganska viktig färdighet att kunna läsa "assembler" för att se vad kompilatorn hittade på. Naturligtvis inte hela program men där något underligt inträffar.

Edit: Grattis TomasL för migreringen till MIPS.

[TomasL]

beträffande just avlusning, dvs debugging, så läste jag någonstans om JPL, och världens mest buggfria kod.

Enligt artikeln så har de två alternerande team, vilka tävlar mot varandra, det ena teamet kodar och det andra debuggar, den som förlorar, betalar pubrundan sas.
I princip varje programrad är kommenterad.
Dokumentationen beskriver varje enskild programrad, med förklaringar till varför just den raden ser ut som den gör och varför den finns där.
Även buggrättningarna är kommenterade och beskrivna med orsak och verkan.
Om en programlistning tar upp en A4-pärm, så tar dokumentationen upp 100, typ.

Å andra sidan kan de skryta med den mest felfria koden som någonsin skrivits.

Lillahuset, javisst, man behöver ha grundläggande kunskap om maskinkoden, så man åtmindstånde kan få ett hum om vad som faktiskt händer.
Och ja de flesta C-kompilatorerna genererar för det mesta betydligt korrektare och kompaktare kod än vad man kan göra manuellt.
Switchade till MIPS för typ 8 år sedan eller nått sånt.

[datajompa]

Alltså, hela min poäng var att programmera på assemblernivå ett tag för att förstå hur hårdvara funkar och sedan gå över till C. Det enda område idag där verkliga program kan skrivas i assembler är små embedded-projekt, så det vore synd att kasta bort möjligheten att lära sig assembler i sin naturliga miljö.

När man väl har förstått det behöver man inte skriva en enda rad i assembler igen, C funkar bra. Jag menar bara att assembler förmodligen är en snabbare väg till C.

[TomasL]

Personligen tror jag inte det, bättre att plugga datablad och lära sig C direkt.
När sedan behovet kommer så kan man grotta in sig i maskinkoden.
Dock kan det i bland vara oundvikligt att skriva "in-line" då allt inte går att göra i C, men då är det lite mer avancerad programmering, till exempelvis interruptwrappers och att kringå errata.

[Icecap]

C är mer effektivt att skriva än assembler, inte tu snack om det!

Men vad jag ofta ser här i forumet är att många inte förstår vilka resurser de jobbar med och hur man använder dom bäst möjligt. Detta är något man tvingas lära sig vid assembler-programmering - men man kan likaväl lära sig vid C-programmering om man bara vill.

Tyvärr hoppar många på Arduino-träsket och stannar kvar i det nivå för att - vad jag anser som basal inlärning - undvika att lära sig om hårdvaran på bit-nivå.

[lillahuset]

Helt min mening. Men det är ju så nuförtiden. Det får inte vara jobbigt, bara kul.

[lillahuset]

“C is not a big language, and it is not well served by a big book.”
― Brian W. Kernighan, The C Programming Language