|
Anzeige
|
Formel bläht Code auf
Gast
#2171578
Moin, ich habe folgende Formel:
Wenn ich von hand rechne kommt da 6.1xxxx heraus. Wenn ich allerdings nun faktor benutze wird der Code gleich gewaltig größer. Ist ja klar, der setzt da eine Kommazahl rein. Wenn ich allerdings ein (char) oder (uint8_r) davor setze, ist der erzeugte Code immernoch rund 100Byte größer als wenn ich manuell eine 6 eintrage. Wo ist das Problem? z.b.
mfg Nils schrieb: > Wo ist das Problem? Vergessen die Compileroptimierung (-Os z.B.) einzuschalten?
Gast
#2171589
Nein, die habe ich auf 2 oder 3. Dann schau mal in den generierten ASM-Code, was er daraus macht.
Gast
#2171604
Der scheint da ne Menge ldi und call reinzuschieben. Mir scheint, dass der ne int oder long vorher berechnet und dann die ersten 8 bit in PORTA reinschiebt, statt ein einziges ldi zu schreiben. Nils schrieb: > Der scheint da ne Menge ldi und call reinzuschieben. Mir scheint, dass > der ne int oder long vorher berechnet und dann die ersten 8 bit in PORTA > reinschiebt, statt ein einziges ldi zu schreiben. Und dafür einhundert Bytes? Krass...
Gast
#2171635
Nils schrieb: > st ja klar, > > der setzt da eine Kommazahl rein Nein, wieso sollte er? Nils schrieb: > (256*1024*10) und ist das nicht eh schon ein Überlauf? Nils schrieb:
Ich bekomme hier folgende Warnings: ../test.c:14: warning: integer overflow in expression ../test.c:14: warning: division by zero Das ist auch logisch: 256*1024*10 sind größer als ein 16Bit-Integer packen kann. Der avr-gcc dividiert hier jedenfalls durch 0. Korrigiere das zu:
Dann sollte es passen. Bei mir ist jedenfalls der Code gleich groß, egal ob ich obigen Ausdruck verwende oder direkt den Wert 6 zuweise. Gruß, Frank
Gast
#2171706
Ok das funktioniert. Dann musste da Nenner auch ein UL rein. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
