Martijn van Buul
dohd.org> wrote:
>Nico Coesel (nico@puntnl.niks) schreef:
>> Martijn van Buul
dohd.org> wrote:
>>>>>Nico Coesel (nico@puntnl.niks) schreef:
>>>
>>>[ grote knip ]
>>>
>>>Tot hier was ik het roerend met je eens, maar:
>>>
>>>> Als je begint met een platform waarop je goed in C kunt programmeren (dus
>>>> niet de PIC, 8051 of AVR),
>>>
>>>Een AVR valt fantastisch in C te programmeren. Een 8051 in zekere zin
>>>ook, maar die wil je om andere redenen niet meer.
>>
>> Maak eens een programma waarin je met strcpy en strcat een constante
>> en niet constante character array naar een niet constant character
>> array wilt kopieren. Dat gaat niet op een harvard architectuur zonder
>> bijzondere (trage) pointer acrobatiek omdat de processor aan de
>> pointer zelf niet kan zien in welke geheugen de data moet worden
>> opgehaald/weggeschreven.
>
>So? Het is wat minder handig, inderdaad, maar
>*juist omdat je in C programmeert* heb je er helemaal geen last van, omdat
>de compiler dit soort details voor je oplost.
Maar wel ten koste van performance en tegenwoordig koop je voor
hetzelfde geld een veel snellere en betere microcontroller die al die
truukerij niet nodig heeft. Waarom zou je nog met paard en wagen op
weg gaan als je voor hetzelfde of minder geld een auto hebt?
>>>[knip]
>>>
>>>> En tegenwoordig zijn er voor veel platforms (ARM, MIPS, MSP430, H8)
>>>> uitstekende GCC compilers beschikbaar voor niets.
>>>
>>>Gcc? Uitstekend? Laat me niet lachen. Gcc is een vrij slechte compiler. Het
>>>*werkt* voor veel targets, maar daar is het dan ook mee gezegd. Performance is
>>>(op alle targets!) vrij bedroevend. De beschikbaarheid van gcc voor een bepaald
>>>platform (waaronder AVR, overigens) is geen reden om andere beschikbare
>>>C-compilers die vele malen beter presteren (Keil cq Tasking voor de 8051,
>>>CodeVision AVR voor de AVR) te negeren.
>>
>> Met de 8051 en de AVR noem je 2 specifieke 8 bit platforms waarbij de
>> 8051 nog eens zo krom is als een hoepel (been there, done that).
>
>Ik pak de 2 platformen die jij eerder al aan de kant had geschoven omdat je
>ze niet in C zou kunnen programmeren. Wat baarlijke onzin is.
Het kan wel, maar je doet jezelf tekort en je loopt een keer tegen de
grens aan en dan zeg je 'had ik maar...'. Been there, done that -hier
spreekt ervaring-. Probeer eens functie pointers op een 8051. De Keil
8051 compiler ondersteund dat alleen met constante functie pointers.
En zo zijn er nog wel meer dingen die je als je begint niet kunt
overzien, maar waar je wel flink last kunt krijgen. Vandaar mijn
advies om niet met 8051, PIC of AVR te beginnen ook al lijkt de DIL
behuizing zo aantrekkelijk. Dat zijn valkuilen die je uiteindelijk
flink veel tijd gaan kosten.
>En geloof me, ik ken de 8051. Heb jarenlang op de 8-bit microcontroller
>sales support van een bepaalde voormalige gloeilampenfabrikant in het
>zuiden des lands gewerkt. Je mag drie keer raden welke CPU.
Wie heeft er niet met de 8051 gewerkt, maar wat mij betreft mag het
ding begraven worden.
>> Maar voor 32 bit platforms presteert de GCC compiler zeer goed.
>
>*proest*.
>
>>>Gcc is *zo* brak, dat een alle-remmen-los release build van gcc, met maximale
>>>optimalisaties, vaak *langzamer* is dan een debug build van msvc. Om maar
>>>eens een zijstraat te noemen. En dat is dan op een mainstream platform als
>>>32-bits x86.
>>
>> Dat lijkt me erg sterk. Dit soort stellingen komen meestal van mensen
>> die van de ene compiler wel goed weten hoe die werkt en van de andere
>> compiler totaal niet.
>
>En toch zie ik het keer op keer. Inmiddels weet ik hoe ik mijn C zo moet
>schrijven dat zelfs het stomste kindje uit de klas (Wist je overigens dat
>GCC een afkorting is? Staat voor GCC Can't Compile) het een beetje snapt.
Ik dacht dat GCC stond voor Gnu compiler collection, maar weer wat
geleerd.
>En zelfs dan. GCC is stom. En het ergste is nog dat het er van uitgaat
>dat ik *OOK* stom ben.
En dat is maar goed ook. Ook de gevorderde programmeur maakt stomme
fouten.
>> 1 ding weet ik zeker: er zit veel meer tijd en energie in GCC dan in iedere
>> andere compiler.
>
>Veel meer tijd ja - waaronder heel veel verprutste tijd. Tijd verprutst aan
>het toevoegen van zinloze warnings omdat er zoetwaterprogrammeurs zijn die
>te stom zijn om te weten dat && boven || gaat.
Ik noem dat handig want dergelijke programmeurs komen bij bosjes van
school. Programmeer maar lekker simpel want dan kan iemand anders het
project later nog van je overnemen.
>> Als GCC veel slechter presteert dan een commerciele compiler dan doe je of
>> iets heel erg fout of je hebt heel erg veel geld betaald voor de commerciele
>> compiler.
>
>Of de commerciele compiler is voor een specifieke architectuur geschreven, ipv
>voor zoveel mogelijk achitecturen tegelijkertijd.
Dan snap je de opzet van GCC niet. Iedere architectuur heeft juist
zijn eigen back-end met specifieke optimalisaties. Een GCC versie
heeft altijd nog wel een dozijn platform specifieke opties. Alleen de
voorkant is hetzelfde. Wel zo prettig als je code wilt porteren van de
ene naar de andere compiler. Dan kom je erachter dat C niet altijd C
is.
>Intel's icc bestaat niet voor niets, bijvoorbeeld.
>
>Als je dat fundamentele verschil weigert te accepteren, vraag ik me af wie
>er nou degene is die oogkleppen op heeft.
Kijk en vergelijk en je ziet dat GCC zich doorgaans in de top van de
compilers voor een bepaalde architectuur bevind.
>Maar weet je wat de belangrijkste reden is waarom OP misschien beter af is met
>een simpele AVR? Heeft helemaal niets met architecturen, C-compilers of wat
>dan ook te maken, maar met een hele simpele reden:
>
>Een Atmel AVR komt in een fijne DIL behuizing, en is gemakkelijk op een stuk
>gaatjesbord te solderen. Kom daar maar eens mee, met je 48 pins LQFP "low pin
>count" ARM. Of MIPS. Of H8. Zeker zo vriendelijk voor een hobbyist.
Eitje en je hebt er geeneens speciaal gereedschap voor nodig (hint:
hoe dunner de soldeerbout, hoe lastiger je het voor jezelf maakt).
Flux, een schone punt en desoldeerlitze voor de ongelukjes. Bovendien
zijn er heel veel kant & klare bordjes tekoop die je zo in je project
zet. Kan het nog makkelijker?
--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)
