www.freepascal.org voor AVR

Assembly heeft in de meeste gevallen geen duidelijk voordeel, maar ontwikkelen in assembly kost veel meer tijd, en als iemand anders ooit een project over moet nemen en bugs moet oplossen of iets moet toevoegen ben je echt aan de beurt.

@Arco: een factor 5-10 code space, vergeleken met C code met alle space optimization opties ingeschakeld? Zo'n factor geloof ik nog wel als je het vergelijkt met een debug build, maar voor een goede release build zou het toch niet zo groot mogen zijn.

Of vergelijk je nou met Basic? Misschien zit daar dan het probleem...

@eSe: Die lijst is wel een beetje raar; je kunt PHP en VHDL wel samen in een lijst zetten, maar de toepassing daarvan is zo verschillend dat de vergelijking totaal zinloos is.

De index is gebaseerd op regels code geschreven in elke taal; het is dus niet zo vreemd dat assembly relatief hoog staat, aangezien die programma's voor gelijke functionaliteit vele malen langer zijn (in aantal regels).

Daarbij vind ik de manier van meten een beetje twijfelachtig; tellen ze nu alleen publiek toegankelijke code? Dan is het ook wel logisch dat sommige talen veel hoger of juist lager scoren; talen die populair zijn bij open-source projecten (zoals Python en C) zullen dan veel hoger scoren, dan talen die voornamelijk worden gebruikt voor closed-source projecten.

[Bericht gewijzigd door SparkyGSX op 27 november 2021 21:59:56 (40%)]

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

Op 27 november 2021 18:29:00 schreef Arco:
+1 ;)

Heb nooit begrepen waarom C zonodig het pipe/dakje teken moet gebruiken om 1 letter uit te sparen... (Or / Xor is toch veel duidelijker?

C ligt erg dicht tegen machinetaal aan en vroeger was elke byte besparing toch mooi meegenomen. Ook scheelde dat weer enkele machineslagen.

Bezoek mijn neefjes' site: www.tinuselectronics.nl

|, &, ! en ^ zijn gewoon andere wiskundige bewerkingen, niet anders dan +, - , *, /, etc. Wil je die dan ook allemaal vervangen door hele woorden?

Het mooie van die operators is dat je ook verschil kunt maken tussen bitwise en logic operators | en & voor bitwise, || en && voor logic, en expressies als "A = A bit-wise OR B" kort en duidelijk kunt schrijven, als "A |= B;". Dit lijkt me toch triviaal, en iets wat iedere beginnen vrijwel direct kan snappen; de rest van het werk van een programmeur is vele malen ingewikkelder (algoritmes, datastructuren, computationele complexiteit, etc.).

Een manager is iemand die denkt dat negen vrouwen in één maand een kind kunnen maken

de rest van het werk van een programmeur is vele malen ingewikkelder (algoritmes, datastructuren, computationele complexiteit, etc.).

Dat bedoelde ik ook. Het leren programmeren is best moeilijk en in welke taal je dat leert maakt heel weinig uit.

Als je eenmaal weet hoe algoritmes, datastructuren enz werken is dat ook wel vrij eenvoudig te vertalen naar een andere taal.

En als die ene taal precies doet wat jij wilt zie ik ook geen reden waarom je dan iets anders moet gaan doen.

Heb nooit begrepen waarom C zonodig het pipe/dakje teken moet gebruiken om 1 letter uit te sparen

Moet niet ik type het soms ook gewoon voluit, maar dat is meer omdat het | teken vaak over het hoofd ziet en de IDE maakt hem grijs terwijl or dan in het groen verschijnt.

In C mag ik A++ schrijven ipv A = A + 1

Zoals eerder aangeven is het ook aan de programmeur om een goede structuur aan te houden

eSe

Honourable Member

We zijn hier echt wel aan het afdwalen van @TS zijn vraag in de openingspost, maar 't is wel interessant :-)

...het is dus niet zo vreemd dat assembly relatief hoog staat...

Het gaat niet om de hoogte maar om de verhoging tegenover de vorige vergelijking in taalgebruik. Python en C zijn van plaats gewisseld en zoals gemeld zijn assembler en Fortran flink omhoog gegaan. En dat is wel raar.

Voor Fortran kan ik dat nog aannemen: die taal is echt geschikt voor parallel computing en tegenwoordig met die multicore cpu's zou dat wel kunnen.
Maar assembler?

...C ligt erg dicht tegen machinetaal aan...

C is oorspronkelijk gemaakt voor het ontwikkelen van OS's daarom staat het ook zo dicht bij de machine. En daarom kan je machines ook makkelijk op de knieen krijgen als je niet goed oplet. (simpel gezegd)

Groetjes,
eSe

Simulations are like miniskirts, they show a lot and hide the essentials.

...C ligt erg dicht tegen machinetaal aan...

JA en nee zou ik zeggen. Voor de Arduino zijn er 1000den libraries te vinden en dan staat je weer redelijk ver van machine(taal) , sensor of wat dan ook.

Op 27 november 2021 21:48:42 schreef SparkyGSX:
@Arco: een factor 5-10 code space, vergeleken met C code met alle space optimization opties ingeschakeld? Zo'n factor geloof ik nog wel als je het vergelijkt met een debug build, maar voor een goede release build zou het toch niet zo groot mogen zijn.
Of vergelijk je nou met Basic? Misschien zit daar dan het probleem...

Basic, C, of Pascal zit weinig tot geen verschil meer in de size van de gegenereerde code tegenwoordig, is alleen het front-end/parser tenslotte.
Ze gebruiken bijv. bij MikroE allemaal dezelfde compiler.

Verschil in codegrootte tussen geoptimaliseerde assenmbly en C is minstens enkele malen. Als je de meegeleverde libraries gebruikt zelfs groter.
Dit omdat die vaak onnodig groot en uitgebreid zijn met functionaliteit die meesten niet eens nodig hebben.
(Da's ook omdat ze de libraries simpel bruikbaar willen houden voor gebruikers)

De PPS routine voor PIC24 in de MikroE compilers is bijv. bijna 2k groot: in assembly schreef ik dat in 17 instructies...

De basic compiler gebruikt voor bitwise en logic dezelfde notatie.
Da's ook geen probleem want hij hij kan aan eventuele haakjes in de code zien wat de bedoeling is...
(de haakjes maken alles ook veel duidelijker te lezen)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com