probleme mit wordlength + stack memory allocation



  • einen wunder schönen guten morgen,

    ich habe mich noch nicht lange mit asm beschäftigt und hoffe das meine frage hier nicht fehl am platze ist, ich bitte also um rücksicht.

    ich habe hier ein kleines C programm welches nur eine funktion (function1) aufruft, welche einen 10 byte char buffer anlegen soll:

    void function(){
         char buffer1[10];
    }
    main(){
         function();
    }
    

    wenn ich richtig rechne sollte die funktion, auf meinem amd athlon (32 bit), 12bit auf dem stack reservieren ( wordlength=4byte=32bit????)

    wenn ich mir jedoch den assemblercode ansehe werden 24 byte reserviert...

    assembler code:

    .file	"example.c"
    	.text
    .globl function1
    	.type	function1, @function
    function1:
    	pushl	%ebp
    	movl	%esp, %ebp
    	subl	$24, %esp
    	leave
    	ret
    	.size	function1, .-function1
    .globl main
    	.type	main, @function
    main:
    	pushl	%ebp
    	movl	%esp, %ebp
    	subl	$8, %esp
    	andl	$-16, %esp
    	movl	$0, %eax
    	subl	%eax, %esp
    	call	function1
    	leave
    	ret
    	.size	main, .-main
    	.ident	"GCC: (GNU) 3.3.1 (Debian)"
    

    ich glaube herrausgefunden zu haben das er bei mir immer 16byte + 8byte irgentwas (ret und esp???) reservieren will,
    denn wenn ich den buffer1 auf 17 byte setze will er 40 byte haben, das wären dann ja 16byte + 16byte + 8irgendwas.

    habe ich also eine wordlenth von 16 byte??? bitte gebt mir einen tip oder anstoß in die richtige richtung.

    danke mOrLa



  • "wenn ich richtig rechne sollte die funktion, auf meinem amd athlon (32 bit), 12bit auf dem stack reservieren ( wordlength=4byte=32bit????)"

    soll natürlich 12byte heissen;)
    sorry



  • Ich kann nur spekulieren, haben die Athlons schon einen 128-Bit-Bus zum Speicher? Oder irgendwo eine solchartige architektur? Das riecht nämlich stark nach alignen an 16-Byte-Grenze. Die 8 kommen wohl von ret/esp, da müssen noch 8 drauf um auf 16 zu kommen und danach jeweils in 16er-Schritten.
    Eine Wortgröße von 16-Byte hast du bestimmt nicht, ist ja noch ein 32-Bit-Prozessor. Aber vielelicht sind Cachezielen so groß oder ähnliches.



  • naja es ist so:
    wenn ich 1-16 byte reservieren möchte macht mein rechner (und mein laptop und der rechner auf meiner arbeit):

    function1:; 
        pushl    %ebp 
        movl    %esp, %ebp 
        subl    $24, %esp 
        leave 
        ret
    

    und wenn ich 17-32byte reservieren möchte:

    function1:; 
        pushl    %ebp 
        movl    %esp, %ebp 
        subl    $40, %esp 
        leave 
        ret
    

    und so weiter...
    das heist doch das immer in 16byte schritten + 8byte (4byte esp+ 4byte ret)
    allocated wird oder??!?!
    bin für alle tips und komentare dankbar!!
    mOrLa



  • Hab ich doch oben shcon geposted 🙄

    Der Stack wird immer auf eine 16-Bit-Adresse ausgerichtet. Nachdmem der Call ausgeüfhrt ist und EBP gepushed wurde, sind 8 Bytes drauf, also ist die 16-Bit-Anordnung zerstölrt, also 8 Bit drauf um das zu richten. Danach nochmal jeweils 16 Byte für jeden angebrochenen 16-Byte-Block. So bleibt der Stack immer schön 16-Byte-aligned.



  • hmm ich denke das verstehe ich. thx 2: TriPhoenix
    aber warum ist das so? in alle texten die ich bis jetzt gelesen habe allocated
    der compiler immer in 4 byte schritten. ist das bei euch auch so??

    mOrLa



  • mOrLa schrieb:

    hmm ich denke das verstehe ich. thx 2: TriPhoenix
    aber warum ist das so? in alle texten die ich bis jetzt gelesen habe allocated
    der compiler immer in 4 byte schritten. ist das bei euch auch so??

    In welchen Schritten er allocated hängt davon ab wie gut es für den drunterliegenden Prozessor ist. Auf jedem 32-Bit-Prozresor lohnt sich auf jeden Fall ein 4-byte-alignment. Wenn nun aber z.B. der durunterliegende Prozesser z.B. immer 16 Byte auf einmal über den Addressbus vom RAM holt, dann lohnt es sich den Stack so zu alignen. Verloren ist nichts dadurch (außer Platz), da der Prozessor ob man aligne doder nicht immer 16 Byte liest/schreibt. Vorteil ist, dass jede Funktoin sichergehen kann, an einer 16-Byte-Adresse zu starten und so nicht der Inhalt einer Funktion über zwei Speicherabfragen geht.


Anmelden zum Antworten