Verwendung des Steacks bei MSP und AVR.

Oliver_E Gast 10.06.2008 21:26 #892512

Lesenswert?

•

Hallo zusammen,

ist die Verwendung des Steacks bei allen Controller (MSP430, AVR, 
PIC,...) gleich -also beim Aufruf einer Funktion werden die Sprung 
Adressen + lokale Variablen auf dem Steck abgelegt? Oder ist das 
Controller abhängig?

Besten Dank

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Christian R. (supachris) 10.06.2008 21:50 #892539

Lesenswert?

•

▲
▼

1. das Ding heißt Stack (Stapel).
2. Ja, das ist wohl bei den meisten Prozessoren so. Allerdings der Stack 
an verschiedenen Stellen angelegt werden. Ist ja in letzter Konsequenz 
auch nur ein Pointer.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Johann L. (gjlayde) 10.06.2008 21:51 #892540

Lesenswert?

•

▲
▼

Mal so, mal so bei den Steaks...

Wie die Verwendung ist, steht jeweils im ABI des Compilers (Application 
Binary Interface). Von der HW wird zunächst festgelest ob das Steak nach 
unten wächst oder nach oben, ob Werte big oder little endian sind etc, 
wobei "nach unten" verbreiteter ist.

Lokale Variablen müssen nicht aufs Steak, die können ebenso in lokalen 
Registern leben was dazu führt, dass sie niemals explizit in RAM 
auftauchen.

Ja nach Architektur gibt's mehr als ein Steak. TriCore kennt zB nen 
Steak für push/pop und eine CSA wo automatisch GPRs und RET-Adresse bei 
nem call rauf kommen.

Lokale Variablen können auch woanders angelegt werden (zB solche die 
static sind) oder gänzlich wegoptimiert werden und tauchen dann nichma 
innem Register mehr auf.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Oliver_E Gast 10.06.2008 21:58 #892551

Lesenswert?

•

▲
▼

Danke für die Antwort.
Johann, Was meinst mit "wegoptimiert"?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Johann L. (gjlayde) 10.06.2008 22:05 #892563

Lesenswert?

•

▲
▼

Nehmen wir mal die C-Quelle

int main (void)
    int sum = 0;
    for (int i=1; i <= 100; i++)
        sum += i;
    return sum;    


und lassen nen optimierenden Compiler drauf los (hier avr-gcc 4.x). Der 
macht da draus

  ldi r24,lo8(5050)
  ldi r25,hi8(5050)


also

int main (void)
    return 5050;    


Wenn Du dann mit den Debugger durchgehst kannst Dir nen Wolf suchen nach 
Deinen Variablen...

Antwort Zitieren Bearbeiten Löschen Beitrag melden

crazy horse Gast 10.06.2008 22:09 #892569

Lesenswert?

•

▲
▼

Warum muss ich gerade an den jungen Gauss denken??

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Johann L. (gjlayde) 10.06.2008 22:17 #892573

Lesenswert?

•

▲
▼

Als interne Darstellung von dem, was da algebraisch abgeht, dient die

"GNU algebraic uniform symbol semantic", kurz Gauss.

In gcc 5.x werden dann die "Extended uniform level expression rules" 
implementiert sein, die auch Optimierungen wie

$e^{2 \pi i} = 1$


ermöglichen werden.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

mr.chip Gast 10.06.2008 22:44 #892587

Lesenswert?

•

▲
▼

> "GNU algebraic uniform symbol semantic", kurz Gauss.

Das heisst also, da mathematische Ausdrücke oder gar Algorithmen auf 
hohem Abstraktionsniveau analysiert und schliesslich optimiert werden? 
Wie weit geht sowas?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Johann L. (gjlayde) 10.06.2008 23:25 #892623

Lesenswert?

•

▲
▼

> "GNU algebraic uniform symbol semantic", kurz Gauss.

Das was ein Scherz am Rande...

Prinzipiell sind der Phantasie (oder inzwischen Fantasi?) keine Grenzen 
gesetzt was Optimierungen bzw. Codetransformationen angeht.

Nehmen wir mal folgendes C-Progrämmle, das 5! ausrechnen soll. gcc 4.3 
macht in main() effektiv ein return 120.

unsigned int fak (unsigned int n)
    if (n > 1)
        return n * fak(n-1);
    return 1;
int main (void)
    return fak (5);


Hier mal dumps der Passes, die avr-gcc zwischen .i (nach dem Präprozess) 
und *.s (asm-Ausgabe) durchläuft:

fak.c.001t.tu                   fak.c.102t.ivcanon
fak.c.003t.original             fak.c.107t.cunroll
fak.c.004t.gimple               fak.c.110t.ivopts
fak.c.006t.vcg                  fak.c.111t.loopdone
fak.c.007t.useless              fak.c.114t.reassoc2
fak.c.010t.lower                fak.c.115t.vrp2
fak.c.011t.ehopt                fak.c.116t.dom3
fak.c.012t.eh                   fak.c.117t.phicprop3
fak.c.013t.cfg                  fak.c.118t.cddce
fak.c.015t.veclower             fak.c.120t.dse2
fak.c.021t.cleanup_cfg1         fak.c.121t.forwprop4
fak.c.023t.early_optimizations  fak.c.122t.phiopt3
fak.c.024t.ssa                  fak.c.123t.tailc
fak.c.026t.einline2             fak.c.124t.copyrename4
fak.c.027t.cleanup_cfg2         fak.c.125t.uncprop
fak.c.028t.copyrename1          fak.c.126t.optimized
fak.c.029t.ccp1                 fak.c.127t.nrv
fak.c.030t.forwprop1            fak.c.128t.blocks
fak.c.031t.addressables1        fak.c.129t.final_cleanup
fak.c.032t.sdse1                fak.c.131r.expand
fak.c.033t.esra                 fak.c.132r.sibling
fak.c.034t.copyprop1            fak.c.134r.initvals
fak.c.035t.mergephi1            fak.c.135r.unshare
fak.c.036t.dce1                 fak.c.136r.vregs
fak.c.037t.addressables2        fak.c.137r.into_cfglayout
fak.c.038t.sdse2                fak.c.138r.jump
fak.c.039t.tailr1               fak.c.139r.subreg
fak.c.040t.profile              fak.c.140r.dfinit
fak.c.041t.release_ssa          fak.c.141r.cse1
fak.c.051t.apply_inline         fak.c.142r.fwprop1
fak.c.052t.salias               fak.c.143r.gcse1
fak.c.054t.retslot              fak.c.144r.ce1
fak.c.055t.copyrename2          fak.c.145r.loop2
fak.c.056t.ccp2                 fak.c.146r.loop2_init
fak.c.057t.phiprop              fak.c.147r.loop2_invariant
fak.c.058t.fre                  fak.c.151r.loop2_done
fak.c.059t.dce2                 fak.c.153r.bypass
fak.c.060t.forwprop2            fak.c.154r.cse2
fak.c.061t.copyprop2            fak.c.155r.dse1
fak.c.062t.mergephi2            fak.c.156r.fwprop2
fak.c.063t.vrp1                 fak.c.157r.regclass
fak.c.064t.dce3                 fak.c.158r.auto-inc-dec
fak.c.066t.dom1                 fak.c.159r.init-regs
fak.c.067t.phicprop1            fak.c.160r.outof_cfglayout
fak.c.068t.ifcombine            fak.c.161r.dce
fak.c.069t.phiopt1              fak.c.162r.combine
fak.c.070t.tailr2               fak.c.163r.ce2
fak.c.073t.cplxlower            fak.c.165r.regmove
fak.c.074t.sra                  fak.c.166r.split1
fak.c.075t.copyrename3          fak.c.167r.subreg2
fak.c.076t.dom2                 fak.c.171r.asmcons
fak.c.077t.phicprop2            fak.c.175r.lreg
fak.c.078t.reassoc1             fak.c.176r.greg
fak.c.079t.dce4                 fak.c.178r.postreload
fak.c.080t.dse1                 fak.c.180r.split2
fak.c.081t.forwprop3            fak.c.182r.pro_and_epilogue
fak.c.082t.phiopt2              fak.c.183r.dse2
fak.c.083t.objsz                fak.c.185r.csa
fak.c.084t.store_ccp            fak.c.186r.peephole2
fak.c.085t.copyprop3            fak.c.187r.ce3
fak.c.086t.fab                  fak.c.189r.cprop_hardreg
fak.c.088t.crited               fak.c.190r.dce
fak.c.090t.sink                 fak.c.191r.bbro
fak.c.091t.loop                 fak.c.197r.alignments
fak.c.092t.loopinit             fak.c.200r.mach
fak.c.093t.copyprop4            fak.c.201r.barriers
fak.c.094t.dceloop1             fak.c.203r.split5
fak.c.095t.lim                  fak.c.204r.eh-ranges
fak.c.098t.sccp                 fak.c.205r.shorten
fak.c.099t.empty                fak.c.206r.dfinish


Näheres zu einigen Passes/Algorithmen findest Du in den Links unten. 
Teilweise werden Algorithmen mehrfach angewandt (zB dce -- dead code 
elimination)

http://gcc.gnu.org/onlinedocs/gccint/Tree_002dSSA-passes.html#Tree_002dSSA-passes
http://gcc.gnu.org/onlinedocs/gccint/RTL-passes.html#RTL-passes

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Verwendung des Steacks bei MSP und AVR.

Antwort schreiben