Hello
I was wondering what impact this had on the program in terms of performance, speed and the need to use FASM variables, especially consistently.

I imagine they are "stored" in registers during assembly, or directly in the RAM; but imagine an "abusive" example: a big 3D RPG multiplayer game developed in FASM using OpenCV, OpenGL and APIs provided by the computer (I obviously don't intend to, but it's for example). If I want to create the characters' lives, their names, the names of the places, the distances to go, the stuff in the inventories, manage the multiplayer, the sounds, the textures, ... And all that and more using the simple basic variables of FASM; we would have more than a hundred lines of variables in the section '.data'.

I read that FASM optimized its code a lot, but I would like to know what variables it has. Indeed, Having already worked a bit under x86-64 INTEL, using variable scares me a bit, because I don't know the mechanism behind it. However, in the other ASM, the values are stored directly in the registers, and they are carried throughout the program. This obviously makes development more difficult. While in FASM, it's simple: you declare a variable, and you don't have to bother calculating which registers will be most appropriate for the stored variable.

In conclusion: What mechanism is behind the use of variables in FASM, what are the advantages, what are the disadvantages, and what are the impacts on performance/rapidity/utility.

Thank you, and good day

PS: Sorry again for my English ^^, if you don't understand some things, or if I made some grammatical/spelling errors, don't hesitate to let me know.

I'm not sure what you mean when you say "variables"?

Variables can be registers (EAX, R12, etc.) or they can be memory addresses.

fasm doesn't decide for you what to do with values in registers or values in memory. Your code will dictate what happens. fasm only translates your ASCII text into binary code in a one-to-one relationship.

You can put as many variable declarations in the .data section as you need. It is just a chunk of memory in RAM. Then your code decides which values to read from RAM into registers, does some computation, and stores values back into memory, or calls an API, or something.

Ok, thanks
It's more or less what I expected. But when I talk about variables, I think of this (the term may not be well chosen, sorry):

In the above code a, b, and c are pointers to an area of memory. They can point to values that can change (variables), or they can point to values that don't change (constants). Your code will decide which usage they are intended to have. fasm doesn't know what you will do with them. You might never read them. Or you might accidentally change a constant. Or you might only ever write to them. It could be anything, and fasm will simply encode the instructions for you to do that.

So, if I understood correctly, the "data" section just loads data into memory, and the name we assign to each value represents its location in the RAM (so a large pointer). Hence the use of '[' and ']' if you want to use them to frame the names in order to recover only the pointed value I imagine.

And to do constants, we could do that then:



?

Yes. If your OS supports section attributes then making it readable only for constants is usually a good idea.

What do you mean? Doesn't that fit my example?

What I mean is that not all OSes support having sections that can restrict writing. If you use Windows NT or later then it will work fine.

Those aren't variables btw. They don't even exist in the executable. The assembler (Fasm) just replaces them with their address in memory when compiling the source code.

Of course their data exists in memory, but when you say [a], it actually just means something like [1234] in code (i.e. addresses offset 1234, where the data is).

Just think of RAM/virtual address as a huge array of bytes. Even the notation makes sense (array[index] is how you access arrays in C, just no name here, since it's implicit).

Okay, thanks a lot to you two

https://en.wikipedia.org/wiki/Data_segment



It depends on your object format and OS loader. IIRC, old a.out only supported three sections (text, data, bss).

Various OSes (e.g. Minix 2.x) would share the code segment among processes so that only the data sections would need to be duplicated, thus saving total used RAM.

Ha, I understand even better now, thanks

Concerning the operating system, I (will) compile mainly under Windows, Linux and Mac. The "classics" in a way ^^ .