flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Main > Use variables a lot

Author
Thread Post new topic Reply to topic
Mino



Joined: 14 Jan 2018
Posts: 74

Use variables a lot

Hello Smile
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 Smile

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.

_________________
The best way to predict the future is to invent it.
Post 12 Apr 2018, 10:48
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15633
Location: Thasus

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.
Post 12 Apr 2018, 11:46
View user's profile Send private message Visit poster's website Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 74

Ok, thanks Smile
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):


Code:

a db 'n'
b dw 100
c dd 0.76
...



_________________
The best way to predict the future is to invent it.
Post 12 Apr 2018, 12:36
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15633
Location: Thasus

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.
Post 12 Apr 2018, 12:46
View user's profile Send private message Visit poster's website Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 74

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:


Code:

section '.const' data readable ; Without "writeable"
   ...




?

_________________
The best way to predict the future is to invent it.
Post 12 Apr 2018, 13:11
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15633
Location: Thasus


Mino wrote:
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.

Yes.

Mino wrote:
And to do constants, we could do that then:

Code:

section '.const' data readable ; Without "writeable"
   ...


?

If your OS supports section attributes then making it readable only for constants is usually a good idea.
Post 12 Apr 2018, 13:22
View user's profile Send private message Visit poster's website Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 74


revolution wrote:
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?

_________________
The best way to predict the future is to invent it.
Post 12 Apr 2018, 13:58
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15633
Location: Thasus

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.
Post 12 Apr 2018, 19:16
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1071

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).
Post 12 Apr 2018, 19:17
View user's profile Send private message Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 74

Okay, thanks a lot to you two Smile
Post 12 Apr 2018, 19:20
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2224
Location: Usono (aka, USA)


Mino wrote:


Code:

section '.const' data readable ; Without "writeable"
   ...




?



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


Quote:

The data segment is read-write, since the values of variables can be altered at run time. This is in contrast to the read-only data segment (rodata segment or .rodata), which contains static constants rather than variables; it also contrasts to the code segment, also known as the text segment, which is read-only on many architectures. Zero-initialized data, both variables and constants, is instead in the BSS 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.
Post 12 Apr 2018, 23:23
View user's profile Send private message Visit poster's website Reply with quote
Mino



Joined: 14 Jan 2018
Posts: 74

Ha, I understand even better now, thanks Smile

Concerning the operating system, I (will) compile mainly under Windows, Linux and Mac. The "classics" in a way ^^ .
Post 13 Apr 2018, 07:37
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2018, Tomasz Grysztar.
Powered by rwasa.