in x86 some operations allowed only with specific register: result of 32bit division goes to eax, while remainder goes to edx, result of multiplication goes to edx:eax pair too.
in xlatb operation used al & ebx.
in data movement (string instructions) are used esi & edi.
pointing via ebp register is 1 byte shorter than via any other register.

so in data transfer & much of operations registers are equivalent, but when needed to execute specific to register instruction thou should use other registers or memory.
And esp, only with that registers executed pushes, popes, calls, rets.

but calling convention it is a bit different thing than register roles.

convention determine how will be passed params of different sizes, they will be passed via registers(and via which) or/and via stack, for clearing stack to state before call is responsible callee or caller, in what order params would be passed, will stack be aligned or not, and so on...

it seems unclear to you what is meant by PUSH?
we PUSH a value on top of the stack to preserve it or pass it to a function/subroutine/procedure.

that is why Tomasz Grysztar PUSHed EBP to preserve it, and load ESP into EBP; if we were in a nested subroutine and did not preserve the value of EBP then that will cause a crash.

using different registers always matter, as for registers have specific job; YES, but they are general-purpose-registers.
ProMiNick already mentioned some examples, in addition to what ProMiNick wrote; every register in x86 mode have some specific uses by some specific instructions.

first off, lets go for "Naming Conventions":
E?X - E = Extended from previous intel architectures.

EAX = Accumulator, used by many x86 instructions. we cant count these as writing them down would take 30minutes to an hours.

ECX = Counter, used by few x86 instructions. REP/REPE(Z), REPNE(Z), JCXZ, JECXZ, few more ..

EDX = Data, some specific instructions.

EBX = Base, used by XLAT. and its the return value of some instructions like CPUID and others ...

ESP = Stack Pointer, which pointer to the current stack. used by PUSH, POP, CALL, RET, IRET, ENTER, LEAVE ...

EBP = Base Pointer, which is used to save current stack frame. its used by ENTER and LEAVE instructions.
in your example if you have used LEAVE before the RET instruction you will crash. (and you wouldnt crash if you followed what Tomasz wrote)

ESI = Source Index, see below.
EDI = Destination Index, see below.

both ESI and EDI are used by string-instructions.

as for Calling Conventions, ProMiNick already mentioned the purpose of the Calling Conventions.

Calling Convention is not fixed, by mean it can vary from one OS to another; also to be more clear its not something specific for OSes or Libraries.

its per function, for example 99.99% (and infinite line of nines) win32 api use the STDCALL Calling Convention.
however, some specific functions use CDECL Calling Convention. (they were originally C Lib functions that were adopted by microsoft windows)

both STDCALL and CDECL require parameters to be PUSHed on the stack, however the stack cleaning is different.
STDCALL - the callee must clean the stack. (easier to call) (when making your own function you may forget about how many bytes you should clean)
CDECL - that caller must clean the stack. (you may forget to clean the stack after the call) (easier to implement a function)

that is not everything, both Calling Conventions require parameters to be pushed right-to-left; both Calling Conventions guarantees that EBX,ESP,EBP,ESI,EDI are non-volatile by mean they will not be changed by the callee in other words they are preserved by the callee.
while EAX, ECX, EDX are volatile, and they will be altered by the callee; if the caller want to keep their values then the caller must preserve whatever content in EAX,ECX,EDX.

and the return value is in EAX.

that is for x86 Calling Conventions, the 64-bit Calling Conventions are different.

as for your own functions, you dont have to follow any rules especially if they are used within your program; you can customize them however you please.

but if you want to make a DLL, then you probably want to follow STDCALL Calling Convention; otherwise you have the document your custom Calling Convention.

in general STDCALL is the most used Calling Convention, and luckily fasm have some macros for stdcall.
invoke - indirect (optional)
stdcall - direct (optional)

as for making a function, PROC and ENDP pairs are used. (optional)

@ProMiNick @Ali.Z
Thanks a lot for explaining, many things are now clear for me.

And here I am after a long break with another question
Currently I am on "Introduction to x86 assembly, part 5: CoMParing numbers"
I would like ask why only first 3 letters change size to small and rest remain unchanged?

somewhere happened call to ToLowerCase,
where first param passed as string to convert, (and in current case I could suppose that it is address of "example" var)
where 2nd param is count of chars from begining to convert (and in current case I could suppose that it is value 3)

to lower case transforming itself is adding to char difference between locase char and upper case one it is 'a'-'A'=$20=20h
add byte[edx],20h
note: it REQUIRES source string to consist only from ENGLISH CAPITAL LETTERS ASCIIs, for other sources it will convert strings to garbage.

that is answer on thour question.

Yeah that's right @ProMiNick I found on beginning of code

after switch value of 3 to another number I can convert much more letters.

I would like ask about priority like on the picture

0 means most important or without priority?

thou could apply logic (if thou remember math).
multiplication & division are more priorited than sum or substraction, so priotity 0 - no priority, 7- highest.

Currently I am reading INTEL 80386 MANULA REF. Could you recommend any good or best book about assembly?

Also I would like ask why my text is not displayed on console
here is code:

So, what is your target OS? It definitely is time to choose.

Windows

If your target OS is Windows, then you need to use its API and not use Linux system calls!

In your FASM\EXAMPLES directory there is an HELLO WORLD example that you can study.

Thanks for you answer
I would like ask why I should use API ? and why I can't do this in console?
I really need to know why this is so important

You can't directly access the hardware in Windows. The best you can get is a virtual console (used by cmd.exe), and for that you also need to use the API.

You can't avoid using the API in Windows, and most other protected OSes (including Linux and MacOS). It's part of being a protected OS.

So why in hight level language everything is displayed in console? The reason is libraries or IDE or something else?

I understand that my questions may be pointless for you, but I see many differences between high-level and low-level programming, which is why I ask.

What makes you think it is the way you say?

It isn't about the language, HLL or LLL, they don't matter. It is the OS that controls access to everything.

So all user programs, e.g. IDEs and compilers, use the API to display text and graphics. The console is only accessible through the API. You don't get to choose this, the OS chooses for you.

So, in short, to answer your question "I would like ask why I should use API ?" it is because the OS enforces this.

BTW: The console is really just a normal graphics program that renders text. And in Windows you can also draw pixel graphics directly to the console window (through the API of course), all you need is the DC handle.

Simplicity. Regardless you are coding in high level or low level language.

Sure, you can use fancy UI (forms with pretty buttons etc) to display the computation result, but that's unecessary and involves more coding.

I always thought that the console is the basic program of any king programming language even assembler, and I always thought after calling code console is running as first program.

Now I know how wrong I was...

many if not most (but not all) programming languages provide some basic input/output functions, we can call these language specific library functions.

when it comes to porting X language to Y operating system, we need to sort of translate these language specific i/o functions into something that Y operating system can understand.

which is OS APIs, so if we take C language as an example; the printf function acts like a wrapper around the real Windows API that deals with console i/o.

what that wrapper do is, basically formats the text, measure the length then pass these to the real API that renders the text.

you can either use language specific functions that act like a wrapper, or make your own wrapper, or maybe call the Windows API directly which is what we do here using x86 Assembly.

also to remind you, revolution said:



so you keep this in mind.