Did you miss my post above? In fact a large number of API functions use the SSE/AVX instructions for moving data around (without any arithmetic being done). It is not a tiny minority. I'm not saying it is good or bad, just that there are in fact many functions that require the alignment.

Anyhow, we have it now. It is what it is. If you want to write code that interfaces with the API then you have to comply or have your code crashing.

this is where you get the idea wrong. In 64-bit ABI of any kind, the work of aligning the stack is not done by the function but rather the responsibility user codes / callers so that a function is free to do its job without any hassle. So the function do not bloat its code with function prologue and epilogue like your pathetic code is suggesting.

It is nothing different than 32-bit calling conventions where the users / callers need to re-align the stack, especially in CDECL. Same old, same old.

You DO know that PUSH is a high-level / complex instruction, right?

It has to move to the stack otherwise there is no point.

sub rsp,20
mov 
mov 
mov    

#include <stdio.h>

int main()
{
        int a, b, c;

        a = 23;
        b = a + a;
        c = b * a;

        printf("%d\n",c ); //1058

        return 0;
}
    

format PE console
entry start

include 'win32a.inc'
section '.idata' import data readable
 
library kernel32, 'kernel32.dll', \
        msvcrt,'msvcrt.dll'

import kernel32, \
       ExitProcess,'ExitProcess'
 
import  msvcrt, \
        printf, 'printf'


section '.data' readable  writeable

results db "%d",1010b,0

a dd 23
b dd ?
c dd ?

section '.main' code readable
start:
        mov     eax,[a]
        add     eax,[a]
        mov     [b], eax
        mov     ebx,[b]
        imul    ebx,[a]
        mov     [c],ebx

        push    [c]
        push    results
        call    [printf]
        add     esp, 4
        push    0
        call    [ExitProcess]
    

@Furs, alignment or not, 32-bit calling conventions stiil require some extra chores dealing with functions enter and exit. It's the same thing with 64-bit ABI. They just do it differently for different purposes. So whatever you're barking about 64-bit does apply to 32-bit as well. No point in barking.

Again you took the 64-bit ABI from a distroted point of view. If you looked at from stack programming, you may have a point (but still rather clueless) with SandyBridge stack engine. But the 64-bit ABI doesn't see its fastcall calling convention from stack management of the processor. The ABI design philosophy tries to avoid the stack programming or to put it in minimal use and take the RSP as an ordinary pointer of memory. There's actually no Stack semantic involved. Look, do you see anything "stacky" about this below?

Code:

sub rsp,20
mov 
mov 
mov    

All I can see from the above is pure ALU and memory transfers. No stack engine, stack frame or stack overhead involved. So there's no point barking about the performance of the 64-bit ABI when you see it wrong in the first place. There's a reason people call it FASTCALL rather than stack call.

Just because you can't code in 64-bit, that doesn't mean system designers are wrong.

I would love to know how to input my own variables manually, instead of programming it in the program. I rather get the user input instead of relying on hard coded variables.

Please advise me so I can do this the right way.

mov eax, [address]    

mov eax, [ebx]    

mov eax, [esp+4]    

mov [esp+4], eax    

mov eax, [esp-4]    

sub esp, 8      ; makes space for 8 more bytes
push something  ; same thing but decrements esp by 4 AND places a value at the new [esp]
    

some_var = 4
other_var = 8

; and then do this
mov eax, [esp+some_var]    ; same as [esp+4]    

system error wrote:

@Furs, alignment or not, 32-bit calling conventions stiil require some extra chores dealing with functions enter and exit. It's the same thing with 64-bit ABI. They just do it differently for different purposes. So whatever you're barking about 64-bit does apply to 32-bit as well. No point in barking.

Again you took the 64-bit ABI from a distroted point of view. If you looked at from stack programming, you may have a point (but still rather clueless) with SandyBridge stack engine. But the 64-bit ABI doesn't see its fastcall calling convention from stack management of the processor. The ABI design philosophy tries to avoid the stack programming or to put it in minimal use and take the RSP as an ordinary pointer of memory. There's actually no Stack semantic involved. Look, do you see anything "stacky" about this below?

Code:

sub rsp,20
mov 
mov 
mov    

All I can see from the above is pure ALU and memory transfers. No stack engine, stack frame or stack overhead involved. So there's no point barking about the performance of the 64-bit ABI when you see it wrong in the first place. There's a reason people call it FASTCALL rather than stack call.

Just because you can't code in 64-bit, that doesn't mean system designers are wrong.

WTF are you talking about? fastcall is a 32-bit calling convention, like cdecl or stdcall.

And it has nothing to do with alignment of the stack. In fact, it has nothing to do with the stack to begin with. fastcall is called that way because it passes parameters in registers instead of on the stack (which has nothing to do with alignment or whatever you talk about). Also, your example with the ALU is for what? Nothing to do with alignment, you can use dumb bloated code without 'push' instructions in 32-bit too if you want. (you can also do that in 64-bit without aligning the stack as well)

And yes designers are dumb, it's one of those cases of short-sightedness that unfortunately is one of the worst in long-standing impact, because it makes us stuck forever with it. Now, even new code utilizing the latest vector instructions will suffer from it, because it has to realign the stack anyway, so 16-byte alignment is LITERALLY nothing but a waste. But then again, this fiasco was designed by AMD and MS just adopted it later, why am I not surprised it's so shit?

Keep barking about me being unable to code in 64-bit though, you really do a good job at strawman fallacies: https://en.wikipedia.org/wiki/Straw_man

At this point I know you're just a troll or just dumb and don't even know what he's talking about (both the push thing, then the cdecl, and now fastcall thing), and anyway this started from it being more complicated to code in for a newbie like the OP in this thread + a personal rant. (MS one makes it doubly worse, not just alignment, but Shadow Space too, so yeah, it's more difficult for newbies), so not going to blow this out anymore, sorry CodeHeretic for this dragged rant in your thread.


If designers were so damn good all the time as you think they are (lol), then why are some instructions so slow in x86 like xlat? Or other instructions that nobody uses (except for super small code size optimizations). Yeah it's called lacking foresight. At that time, it seemed like a good idea. Too bad it was a shit idea.

Hello everyone,

Below I coded two programs. I have been studying as much as I know, and used the debugger, as well as compiled my C program into assembly code, which I must say is highly confusing to me.

Here is the C program:

Code:

#include <stdio.h>

int main()
{
        int a, b, c;

        a = 23;
        b = a + a;
        c = b * a;

        printf("%d\n",c ); //1058

        return 0;
}
    

And here is the assembly program:

Code:

format PE console
entry start

include 'win32a.inc'
section '.idata' import data readable
 
library kernel32, 'kernel32.dll', \
        msvcrt,'msvcrt.dll'

import kernel32, \
       ExitProcess,'ExitProcess'
 
import  msvcrt, \
        printf, 'printf'


section '.data' readable  writeable

results db "%d",1010b,0

a dd 23
b dd ?
c dd ?

section '.main' code readable
start:
        mov     eax,[a]
        add     eax,[a]
        mov     [b], eax
        mov     ebx,[b]
        imul    ebx,[a]
        mov     [c],ebx

        push    [c]
        push    results
        call    [printf]
        add     esp, 4
        push    0
        call    [ExitProcess]
    

I would love to know how to input my own variables manually, instead of programming it in the program. I rather get the user input instead of relying on hard coded variables.

Please advise me so I can do this the right way.

- Sincerely, C0d3Her3tic

C0deHer3tic wrote:

I would love to know how to input my own variables manually, instead of programming it in the program. I rather get the user input instead of relying on hard coded variables.

Please advise me so I can do this the right way.

Ok, I need to go soon but looking at your code I can tell you a few things:

The variables you defined are global (those with 'dd'), it's like defining global variables in C.

The [] memory operand is simply a dereference. Learning assembly made me actually understand C pointers so much better when I did, so here's how it works for me:


Imagine your RAM addressing space is a huge array, to cover your entire RAM. For example, for 32-bit programs, imagine it's a 4 GB array. So each variable in RAM has an index into this 'RAM' array, just like you'd use an index in a C array.

So when you type this in assembly:

Code:

mov eax, [address]    

You simply get the 32-bit (dword) found at index 'address' of RAM (note that this index is byte relative, not dword, that is, [address+1] is one byte higher in memory, not 4!!)

Basically the [] is dereference, just like an array in C.

A pointer is the same thing: it simply holds the "index" or "address" into the RAM array. So:

Code:

mov eax, [ebx]    

treats 'ebx' as a pointer, and you get the 32-bit value it points to, into eax.

There's nothing extra or special about pointers, they're just a byte index into this RAM array -- that's their storage (32-bit or 64-bit or w/e depending on architecture). That's what they hold.

So, in your case, you should allocate the variables on the stack. esp is the "stack pointer" because it points to the current address of the stack, somewhere in RAM.

The stack grows downward so when you push something, esp gets decremented by 4 (or 8 in 64-bit). It's like going "backwards" in memory. Something like:

Code:

mov eax, [esp+4]    

Gets the 32-bit variable found 4 bytes above the current stack pointer. This one stores it:

Code:

mov [esp+4], eax    

EDIT: Oh and to finish this small part up, you should never generally address things below the stack pointer (except in 64-bit with red zone, again, don't bother with that yet). So NEVER do:

Code:

mov eax, [esp-4]    

or similar, because there's no guarantee that data is "safe". (your program can get interrupted by the OS and the OS could modify data below the stack before returning back to your program)

At most, use [esp] for storing data. If you need more local variable space on the stack, simply subtract 'esp' or 'push' some more, i.e.:

Code:

sub esp, 8      ; makes space for 8 more bytes
push something  ; same thing but decrements esp by 4 AND places a value at the new [esp]
    

Normally, people do a 'sub esp, X' at the start of a function, to cover all local variables. It's easier that way, since you won't modify 'esp', so you can address all of them with same offsets.

To help you not hardcode offsets into your program, you can use symbolic constants (an assembler thing, sort of like macros in C), so:

Code:

some_var = 4
other_var = 8

; and then do this
mov eax, [esp+some_var]    ; same as [esp+4]    

The "some_var = 4" are not assembly instructions, so they don't do anything by themselves, same reason a #define in C doesn't do anything, until it is used.

U mad bro or are u trying to prove to everybody that you can actually code?

Just admit it that you can't code in 64-bit and try to put the blame on others. Your case is similar to 16-bit programmers trying to blame the lame design of 32-bit calling conventions simply because they didn't understand it. That's you. If you are not competent enough to use 64-bit calling conventions, just admit it openly.

I'm sure one of my complaint about it not using 'rax' register to pass as first parameter is also my lack of understanding. The ABI is so well designed, 'rax' is not used for anything as input and is trashed / clobbered for output. Waste of potential register.

Obviously I have difficulties using 'rcx' instead of 'rax', it's damn hard to type 'c' instead of 'a', hence my complaint about that too. Requires someone of your childish expertise to do that. You probably don't even know what the red zone is since MS ABI doesn't even use it. Sad joke of a child.

As for interactive, I misread what he meant. I thought he wanted to place his values in variables, instead of hard-coding the values as constants like he did before.

I am an experienced programmer in several languages and now I have decided it is time to tackle assembly.

I chose FASM to start with. Reasons are that I was able to compile the code on my system which is Windows 8, 64 bit of course. I have tried many assembly language books which unfortunately require me to run the compiled code in emulators. The example code in FASM works; compiling and running smoothly. Most of it is GUI, which is okay, however console is more ideal to me.

I see it pointless to program in a language, if all I can do is run it on a system not used in today's computing. 16 bit is hardly compatible now.

I would like a beginner tutorial to start assembly in Fasm with a basic teaching like a simple hello world to print to console until it covers the entire scope of the assembly language with examples and exercises preferably. NO GUI PLEASE.

No emulators needed. And no Linux. I need to learn this on windows. I don't want to hook C or any other language. Is this at all possible?

EDIT: Oh and to finish this small part up, you should never generally address things below the stack pointer (except in 64-bit with red zone, again, don't bother with that yet). So NEVER do:

Code:

mov eax, [esp-4]    

or similar, because there's no guarantee that data is "safe". (your program can get interrupted by the OS and the OS could modify data below the stack before returning back to your program)

If you're already proficient in several HLLs, then why bother with x86 assembly? Sure, assembly can be fun, but it's also very error-prone. You'll constantly be living inside a debugger.

I also wonder if this is a misguided attempt to "speed up" or "optimize" your software. Probably not worth it, you're most likely headed in the wrong direction.

Emulators aren't that bad, and VT-X is baked into (most) x86 hardware, hence it's not as "slow" as it could be (e.g. VBox or KVM). Heck, Win8 (64-bit Pro) already has Hyper-V. While I do indeed enjoy DOS (and 16-bit), I'm not actively encouraging that here. I'm just saying, emulators aren't too bad.

But overall I think you're not looking at the big picture. You don't want "obsolete", but everything is obsoleted eventually.

Honestly, even though I haven't done it myself, I would advise you to learn Linux 64-bit instead, presumably with Seyfarth's book (*nix edition, natch).

BTW, why didn't you upgrade to Win10? It runs Linux 64-bit binaries now. Well, there's half my point, binaries will run on both, so it's a good target (maybe). Hey, you didn't want GUI anyways.

And, while I hate it, I do think 64-bit is better to learn than 32-bit (although it's not criminally wrong either way).