News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Recent posts

#11
The Campus / Re: Stack management and para...
Last post by NoCforMe - Today at 08:04:52 AM
There's a Linux forum here: perhaps that would be a better place for this topic? (Most of the discussions here are about x86/x64 code, so this is kind of an outlier.)
#12
The Workshop / Re: gdiplus tests
Last post by NoCforMe - Today at 07:46:38 AM
OK; so now we come to the matter of image quality. Does GDI or GDI+ yield the better image quality? Especially if the image is stretched?

I know that some rendering techniques result in really crappy images, but I can't remember exactly which ones those were.
#13
The Campus / Re: Stack management and para...
Last post by mulu64 - Today at 07:38:53 AM
Thank you, but it's the gcc compilation of the C code that was in first post. It seems to use 32 bits part of registers (optimisation of compiler ?).
I will use gdb tomorrow on this, i'm on my phone for now.
#14
The Campus / Re: Re: TransparentBlt Example...
Last post by zedd151 - Today at 07:29:48 AM
No, the dialog box window style in the .rc file was fine.

This issue is really driving me nutz!  :biggrin:
Both the latest 'resize and center using AdjustWindowRect' version, and the original 'homemade resize and center' version attached.
#15
The Campus / Re: Stack management and para...
Last post by zedd151 - Today at 07:14:04 AM
Upon taking a quick second look at your code, you are indexing rbp at 4 byte increments. [rbp-4], [rbp-8], [rbp-12], etc.
That is wrong, this much I can tell you. 64 bit registers are 8 bytes, not 4. Beyond that I cannot offer much help otherwise.
#16
The Campus / Re: Stack management and para...
Last post by zedd151 - Today at 05:42:46 AM
I am not sure if it makes any difference for your example, but it might.
Thanks.
I myself don't have sufficient knowledge of 64 bit, or stack manipulations in 64 bit.

In Windows programming with the Masm64 SDK, when we use 'invoke' to call a procedure, all of the stack management is handled without needing to fiddle with the stack at all (as long as 4 arguments or less) the first 4 arguments are passed in rcx, rdx, r8, and r9. Also, 'shadow space' is taken care of as well.

For Linux, this may be (and probably is) different.
We have a couple of members that use Linux as their primary operating system and may be able to help you with this, mabdelouahab and I think jack.
#17
The Campus / Re: Stack management and para...
Last post by mulu64 - Today at 05:38:07 AM
Quote from: zedd151 on Today at 05:35:57 AMI had seen your posting in the Linux board.
Is this for Linux or Windows?

It is for Linux.
#18
The Campus / Re: Stack management and para...
Last post by zedd151 - Today at 05:35:57 AM
I had seen your posting in the Linux Assembly board.
Is this for Linux or Windows?
#19
The Orphanage / Re: Ambition
Last post by daydreamer - Today at 05:18:03 AM
Sometimes I get an idea and write down unfinished code anywhere, but too many coding ideas and other ideas too, 3d graphics, fantasy novel, seldom make a poem, too little time to finish all projects at home on my pc.
I sometimes enjoy sit in library writing and sometimes sketching too, or on train /buses when I commute, that helps me write down my ideas before I forget it and fast concept art sketch for artwork ideas.

Right now busy with less advanced things than coding, writing new parts of fantasy novel while I get ideas to write and translate to swedish, making a pic that shows how main mage character looks like.

Isn't it called "round robin", switching between working on many different things all the time?
#20
The Campus / Stack management and paramete...
Last post by mulu64 - Today at 05:09:26 AM
Hello,

For studying parameters passing, i'm using those C functions (found on a tutorial):

int foo(int arg1, int arg2, int arg3, int arg4, int arg5, int arg6, int arg7, int arg8) {
    return arg1 + arg2 + arg3 + arg4 + arg5 + arg6 + arg7 + arg8;
}

int bar() {
    return foo(1, 2, 3, 4, 5, 6, 7, 8);
}

When bar() is called, i expect to have arguments from 1 to 6 passed to EDI,ESI,EDX,R10,R9,R8 and arguments 7 and 8 go to the stack.
Check with godbolt:

bar:
        push    rbp
        mov     rbp, rsp
        push    8
        push    7
        mov     r9d, 6
        mov     r8d, 5
        mov     ecx, 4
        mov     edx, 3
        mov     esi, 2
        mov     edi, 1
        call    foo
        add     rsp, 16
        leave
        ret

First surprise: it's not R10 which is used as fourth argument, but ECX.
I had read here and there that ECX was not to be used (don't remember where, but chatgpt said the same thing, last time i trust you liar!). I've check later with AMD ABI documentation, and it seems that sometimes it's ECX and sometimes it's R10 (for kernel calls with syscall). I'm not sure of this, so i mention it.

For the « leave » instruction , it seems it's like:
mov rsp,rbp
pop rbp

I would have just push'ed and pop'ped RSP at beginning and end, but maybe it's a generical way to write for the compiler. Is it for restoring a good value, in case of RSP has been changed by inner function calls ?

But then, here goes foo()

foo:
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        mov     DWORD PTR [rbp-8], esi
        mov     DWORD PTR [rbp-12], edx
        mov     DWORD PTR [rbp-16], ecx
        mov     DWORD PTR [rbp-20], r8d
        mov     DWORD PTR [rbp-24], r9d
        mov     edx, DWORD PTR [rbp-4]
        mov     eax, DWORD PTR [rbp-8]
        add     edx, eax
        mov     eax, DWORD PTR [rbp-12]
        add     edx, eax
        mov     eax, DWORD PTR [rbp-16]
        add     edx, eax
        mov     eax, DWORD PTR [rbp-20]
        add     edx, eax
        mov     eax, DWORD PTR [rbp-24]
        add     edx, eax
        mov     eax, DWORD PTR [rbp+16]
        add     edx, eax
        mov     eax, DWORD PTR [rbp+24]
        add     eax, edx
        pop     rbp
        ret

So it saves RBP and store RSP in it.
And then it start to store parameters.

[RBP-4] is the first one.
So i believe it will write from RBP-4 to RBP , reaching top of allowed stack.

And then we continue until parameter 6, growing stack down.

I believer parameters 6 and 7 should be at RBP and RBP+8.

But i read in the addition, it accesses params 6 and 7 with [RBP+16] and [RBP+24].
What is stored in [RBP] and [RBP+8] ?
When the function ends, RSP is adjusted by 16 octets, not 32 (if param 7 begins at RBP+24, that means it ends at RBP+32)

I have a last question: we are using RBP, ans RSP stays at the top of the frame.
What if we push something of size x ? RSP will be used and destroys from RBP to RBP-x , won't it ?

Thank you.

PS: i'm sorry to have put all these questions in one post. Answer only to part you want, of course.