HEX bestand stuk kleiner na re-compile

Op zich geen probleem, maar uit pure nieuwsgierigheid toch mijn vraag gepost.

Ik had van iemand een AVR projectje gekregen met source code en HEX bestand.
Ding spuugt wat seriële tekst uit op 4800 baud, niet heel spannend.

Nu heb ik dat aangepast naar 9600 baud en gecompileerd naar een nieuwe HEX, maar tot mijn verbazing is mijn HEX bestand de helft kleiner dan het origineel.

Geen idee waar het originele HEX bestand mee gecreëerd is, ikzelf heb AVR Studio 5.1 gebruikt.
Als ik een HEX editor gebruik zie ik dat het origineel ook niet gewoon voor de helft leeg is, maar echt extra data bevat.

Iemand hier ervaring mee ?
Kan het verschil komen door een andere compiler, en waarom dan ?

In the beginning there was nothing, but even that exploded
Arco

Special Member

Je hebt een ander optimization level ingesteld? (of die compiler optimaliseert meer?)

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

Dit kan inderdaad komen door de compiler. Is onder andere afhankelijk van welke libraries allemaal gelinkt worden. Ik denk dat je het daar in moet zoeken.

This is the world we know best, the world of madness

Op 10 augustus 2020 15:04:16 schreef Arco:
Je hebt een ander optimization level ingesteld? (of die compiler optimaliseert meer?)

Geen idee eerlijk gezegd, want ik weet ook niet hoe de originele gecompileerd is (heb ik zo gekregen)

Gebruik zelf eigenlijk altijd PICjes, nooit AVR, en bij PICjes heb ik dit nooit eerder meegemaakt.

Maar dank voor het meedenken, zal ik kijken of ik ergens optimization levels kan vinden in AVR Studio...

In the beginning there was nothing, but even that exploded

Op 10 augustus 2020 15:05:16 schreef Blackfin:
Dit kan inderdaad komen door de compiler. Is onder andere afhankelijk van welke libraries allemaal gelinkt worden. Ik denk dat je het daar in moet zoeken.

Dank voor de uitleg.
Weer wat wijzer geworden ;-)

In the beginning there was nothing, but even that exploded

Extra libraries meelinken heeft meestal geen effect. Zolang die funkties niet gebruikt worden komen ze ook niet in de hex file terecht. Maar misschien is er wel een compiler vlag om dat uit te schakelen.

Wel kan het zijn dat floating point printf aanstaat in het oorspronkelijke project. Dat geeft wel een paar kilo extra code.

En optimisation levels maken ook wel verschil.

Arco

Special Member

Gebruik zelf eigenlijk altijd PICjes, nooit AVR, en bij PICjes heb ik dit nooit eerder meegemaakt.

De Mikrobasic compiler bijv. heeft 6 optimization levels...

'Zelfdenkende compiler' is soms wel lastig. Ik gebruik vaak constantes gedeclareerd op een vaste geheugenplaats in flash (voor een bootloader)
Die worden (ongeacht optimization level) altijd eruit gesloopt. (compiler denkt: niet gebruikt, weg ermee... )

Ik moet dan een extra dummy read van die constantes gebruiken om de compiler te laten denken dat die constantes niet weg mogen... :( )

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

Misschien is het originele HEX bestand wel een kopie van het complete geheugen met en berg FF's aan het einde na het programma?

Hobby, maar sample met mate. | BumbleBee plus pack | Weerstand calculator voor je PSP
Arco

Special Member

Als ik een HEX editor gebruik zie ik dat het origineel ook niet gewoon voor de helft leeg is, maar echt extra data bevat.

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

Ik heb pas nog zitten spelen met de compiler optimalisatie settings. Met bug in mijn code kreeg ik 14k code, met een aantal settings tussen de 75 en 82k en bij de allerslechtste optimalisatie zelfs 120k aan code. Dus het kan een boel schelen.

De "normale" setting voor mijn programma leverde bij mij dus 75k aan code op, en een factor twee is best veel. Maar als je programma niet zo groot is dan kan zo'n setting van: wel floating point printf ineens een groot verschil maken...

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Op 11 augustus 2020 15:13:43 schreef Switching Power:
Misschien is het originele HEX bestand wel een kopie van het complete geheugen met en berg FF's aan het einde na het programma?

Nope... Had ik al naar gekeken in een HEX editor, maar geen FFjes of andere lege ruimte aan het eind. ;-)

In the beginning there was nothing, but even that exploded

Op 11 augustus 2020 16:13:40 schreef rew:
Ik heb pas nog zitten spelen met de compiler optimalisatie settings. Met bug in mijn code kreeg ik 14k code, met een aantal settings tussen de 75 en 82k en bij de allerslechtste optimalisatie zelfs 120k aan code. Dus het kan een boel schelen.

De "normale" setting voor mijn programma leverde bij mij dus 75k aan code op, en een factor twee is best veel. Maar als je programma niet zo groot is dan kan zo'n setting van: wel floating point printf ineens een groot verschil maken...

Das inderdaad een groot verschil.
Maar goed, mijn eigen compile is dus al de helft kleiner dan het origineel, dus wat mij betreft prima zo.
Was alleen nieuwsgierig omdat ik het nog nooit eerder gezien had...

Thx!

In the beginning there was nothing, but even that exploded
Anoniem

Op 11 augustus 2020 13:40:31 schreef Arco:
[...]
Ik moet dan een extra dummy read van die constantes gebruiken om de compiler te laten denken dat die constantes niet weg mogen... :( )

Kan dat niet met een pragma?

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

#pragma GCC optimize ("O0")