Lågnivå, hur läggs ett objekt på stacken?

@Ragin Pig: Jag vet inte hur mycket detaljer du vill ha så vi håller det lite översiktligt. Det hela beror på vilken kompilator du använder men en vanlig variant är att man i funktionen använder en pekare som frame-pointer och låter den peka ut "början" på funktionens lokala variabler:

      | Inkommande         |
      | parametrar         |
      |--------------------|
      | returadress        |
FP -> | lokala variabler   |
      |                    |
      |                    |
      |--------------------|
SP -> |                    |
      |                    |

Eftersom man använder sig av frame-pointern för att adressera lokalvariabler kan man med den här modellen kan man pusha och poppa saker från stacken vid funktionsanrop utan att behöva ta hänsyn till det när man accessar lokala variabler. Allting går via FP och man har samma offset under hela funktionen.

Till GCC kan du ge switchen -fomit-frame-pointer som betyder att man inte skall använda FP. Då får man ett extra ledigt register, men då får kompilatorn istället gå via SP när man vill komma åt lokala variabler och justera variablernas offset från SP när det pushas och poppas värden.

Om MyObj är 500k stort kan det vara svårt att nå hela arean för lokala variabler direkt via SP eller FP om "register indirect with offset"-adresseringsmoderna inte kan ta tillräckligt stora offset. Då får kompilatorn använda ett extra register för adressberäkningen. (Det går att justera SP eller FP också men det går normalt åt fler instruktioner eftersom man måste sätta tillbaka den efter accessen.)

Svarade detta på din fråga?

När du anropar en funktion där saker ligger på stacken utförs rent logiskt denna prolog (rent logiskt, i praktiken finns det en rad optimeringar som gör att man kanske inte alls explicit behöver allokera stack-utrymme)

    move basePtr, stackPtr      ; detta är inte ett krav, görs i
                                ; praktiken bara om du behöver debugga
                                ; och därmed kompilerat utan
                                ; optimeringar
    sub stackPtr, #frameSz      ; där 'frameSz' är storleken på alla
                                ; lokala variabler

Alla objekt/variabler som är lokala för funktionen ligger då mellan stackPtr och basePtr, d.v.s svaret på din fråga är: objektet ligger inuti stack-ramen.

Notera att stacken växer mot lägre adresser i pseudokoden ovan. Detta är inte ett hårt krav men nästan alla CPU-arkitekturer (eller rent formellt, alla ABIs är definerade så) gör på detta sätt (inklusive t.ex. x86 och ARM).

Huruvida man direkt kan adressera allt som ligger på stacken beror på CPU-arkitektur, så tyvärr är svaret här: det beror på. x86 kan i praktiken alltid adressera allt oavsett storlek på det man har på stacken. ARM har en gräns på 4 kB, sedan måste man involvera temporära register. Andra RISC CPUer lär nästan alltid få göra lite beräkningar för att nå fält.

I slutet av funktionen finns sedan epilogen

    add stackPtr, #frameSz      ; lämna tillbaka stackutrymmet
    ret

De enda jag kan tänka mig att detta spelar roll för är de som utvecklar kompilatorer. Sedan är 4 kB knappast en relevant begränsning i praktiken, det lär täcka väldigt nära 100 % av fallen.

Det lite roliga är att de beskrivningar som gjorts ovan må vara en korrekt beskrivning av vad som sker rent konceptuellt. Skulle någon däremot börja titta på strukturen hos koden som kompilatorer faktiskt lägger ut när man bygger med optimeringar och liknande skulle man bl.a. se detta

• på 64-bitars x86/ARM Linux/OSX/BSD/UNIX kommer funktioner som inte anropar andra funktioner eller bara anropar sådant som går att "inline:a" överhuvudtaget inte skapa ett stackutrymme om utrymmet för lokala variabler understiger 128 bytes. I stället läggs dessa i register samt ett implicit utrymme kallat "red zone" som alltid finns ovanför toppen av stacken

• på 64-bitars Windows skapas ingen stackram i funktioner som inte anropar andra funktioner om storleken på lokala variabler som inte kan hållas i register understiger 32 bytes. Till skillnad från *NIX så lagras detta 8-40 bytes under toppen av stacken (de första 8 bytes på toppen är initialt returadressen)

• ABI som används på 64-bitars x86 av *NIX är explicit designat så att debuggers kan fungera utan att sätta upp en base-pointer, gcc/llvm skippar därför att sätta upp en sådan i normalfallet (går att tvinga dessa att generera kod med BP uppsatt)

Så precis som vanligt: finns ingen regel utan massor med undantag