Does it worth using registers instead of variables?

[Sergiu FUNIERU]

I am trying to understand why is better to use this:

Code Select Expand

Let esi = FileRead$ ("test.txt")


and

Code Select Expand

invoke CreateFile, chr$ ("test.txt"),
                       GENERIC_READ or GENERIC_WRITE,
                       FILE_SHARE_READ or FILE_SHARE_WRITE,
                       NULL,
                       OPEN_EXISTING,
                       FILE_ATTRIBUTE_NORMAL,
                       NULL
mov hFile, eax


instead of:

Code Select Expand

hFile = fread ("test.txt").

If I save the hFile into a register, it's not risky? That is, it might be possible for other function call to affect that register or I might overwrite an important data.

Why the trouble of using registers instead of variables, for small amount of data, like a file handler?

[Gunner]

Seriously, you should RTFM and search the forum  :P  It is generally faster to use a register than variable.  Other functions are not supposed to trash esi, edi, and ebx. So you can uses them freely, but if you do uses them push and pop them or use put uses esi edi ebx next to your proc name.  There are great help file in your \masm32\help folder... look at asmintro

[GregL]

Use registers for intermediate calculations, then save any results that you may need later to a variable.  If you won't need it later, don't bother with saving it.

[MichaelW]

Why the trouble of using registers instead of variables, for small amount of data, like a file handler?

Access to a variable stored in a register is generally faster than access to a variable stored in memory. And for simple code, storing a variable in a register is frequently more convenient than storing the variable in memory because storing it in a register requires less typing and/or less navigating through the source.

[hutch--]

The problem with using registers as variables is you usually run out of registers. In API code it just does not matter if you attribute the value directly to memory as APIs are some powers slower than mnemonic code and you solve problems like over-writing registers with later function calls. Keep your registers for where it matters, speed critical code and even there, start off using memory operands so that you don't run out of registers because once you do you cannot finish the algo without some really slow and sloppy code.

[jj2007]

Seriously, you should RTFM and search the forum  :P

The problem is that this kind of basic info is dispersed all over the place. Sergiu, your idea of creating a guide is not that bad, actually. If only the guide could fit in one page...

Gunner, since you have read the FM and searched the forum, where is that para that explains clearly how esi, edi & ebx are to be treated? One link is sufficient. Please, don't come up with more than one link.

[Gunner]

Gunner, since you have read the FM and searched the forum, where is that para that explains clearly how esi, edi & ebx are to be treated? One link is sufficient. Please, don't come up with more than one link.

Seriously? People come to this forum and ask questions that have been asked before (sure worded differently but the same) they dl masm and never bother to peek in the folders and discover sample code AND help files.  asmintro is a great help file.  This is helpful: Start>run>mk:@MSITStore:g:\masm32\help\asmintro.chm::/Register%20Preservation%20Convention.htm  and replace G:\ with the drive masm is on

[jj2007]

It is a good link indeed, but it is a full page of prose - I asked for a para. And the page does not contain the word "callback"...

[BlackVortex]

Read Iczelion's tutorials.

Read them.

[jj2007]

Read Iczelion's tutorials.

Read them.

I have read them, and I fully understand the ABI. It is incredibly easy to write a lot about the ABI - read here some contributions from very experienced programmers.

However, it is a lot more challenging to provide one para that explains to a noob what are the essential rules in register usage.

[oex]

Is it worth it? A noob will jump in with all sorts of preconceived ideas about what a register is , what a variable is etc etc.... At some point they have to look at the broader picture. In PHP registers dont exist, a variable can be a multi-dimensional array, a string or a class. In C++ a variable has complex type. In ASM it has basic type.... Chances are a noob wont even understand the principles of type setting so immediately you're into the next paragraph.

It took me a while to get it, I looked at the manual (about 10 times), went through the forum, used pre-existing programming knowledge, asked the odd question (probably pretty odd :lol) and finally got it.

What any noob should try to avoid is to be too much of a drain on the forum, if at first you dont succeed try, try again.... then ask on the forum. Otherise you learn sh*t and dont know where to look the next time....

Someone always knows a better function/algorithm to use but if you cant invoke the function you havent RTFM (sorry it's my all new favorite Acronym :lol)

[aker]

My guess is registers faster than memory.

[hutch--]

My only concern over this discussion is that the data to learn IS all over the place because of the nature of the data and there is a good chance that the ambition to put it all on one page is going to work unless the print is read with an electron micrscope.

Basic guidelines backed up with reference material and a few people to explain the more difficult bits go a long way towards getting someone far enough along the path to keep going themselves but putting it all on one simplistic page, nahhhhhh !

[Sergiu FUNIERU]

Seriously, you should RTFM and search the forum  :P  It is generally faster to use a register than variable.

Will all due respect, that wasn't my question. I didn't ask if a register is faster than a variable. I asked if it worth to do aggressive optimization in that particular situation. Hutch's answer was to the question I asked. That is , "Keep your registers for where it matters". You answered the question "Is a register faster than a variable?", which is a different question from that I asked.

I was taught C in college. On the final exam, I lost 1 point out of 100 because I used int instead of short int for 1 variable, that was used 1 time, in a program that had less than 1 k memory footprint. I was taught to optimize everything, even if it worth it or not. I asked the thread question to see some professorial opinion about my question - and I had the chance to get the answer I need it.

I do read the manuals. My problem is that I don't understand some information that is not written in the manuals. People here have different coding styles and I try to figure out why they do things so differently.

I'm not the lazy noob you seem to believe I am. I really try to understand how a simple code works before moving forward. What it might be obvious for you, it might be difficult to understand for me at that time. I know that I'm a slow learner, but, in the end, I understand enough to be able to give back to this forum. Hopefully, one day, I'll be able to answer even one of your questions. You may take that as a compliment.

By the way, jj2007, thank you for understanding me.

[hutch--]

Sergiu,

This is the type of logic I am addressing, when you make an API call the return value is in the EAX register, that is normal Win32 convention (if its not floating point or similar) and the next API call will overwrite EAX so inbetween you must put it somewhere. If you preserve the normal registers for a stack frame procedure (a normal proc) you can use any of EBX ESI and EDI and its sometimes convenient to do this but there are no speed or performance gains in doing so, API calls are very slow in comparison to mnemonic code.

Where you really need to understand registers and code optimisation is in intensive mnemonic algorithms where it actually matters and there you are on another planet, maximise your available registers, design careful register re-use, start with the right algorithm and code it efficiently. In this context optimal use of registers becomes critical and this is the context for my comment, start with memory operands where you can as it leaves you with some free registers to use later when you must get speed out of the algorithm. Small re-usable procedures are relatively easy but large complex ones take good organisation and a very good understanding of the hardware and the algirithm to get optimal performance.

There will always be a faster algorithm out there somewhere but if you code your own correctly and efficiently you will come close to the best and that will make it faster, better or smaller than most of your competitors.