Where to store variables?

[The_Grey_Beast]

I'm programming a PrintString routinue that prints a string to the screen. The only problem is that I NEED to optimize extremely well, because the format used by my font's data is very compressed, and therefore needs a lot of additions and bit operations to decompress it, and printing a font to the screen per frame must be done very fast. The routinue works well, but I still got a minor question about variable optimization.

I know I must store as much variables as possible into the registers, and I did it. Which one of the following is better?
1) Store the word variable into ebx's upper 2 bytes (because I use bl and bh, eax, edx. I use ecx temporary for string instructions, so I cannot store in ecx for the entire routinue), and then, to use the variable, do something like:
mov ecx, eax
shr ecx, 16
; do something with cx (the word variable)

or
2) Store the word variable into the stack and use it from there.
3) Store the word variable into gs or fs (because I don't use them).. Does this affect the program's functionality or brokes it? Is this good? Also, do I have to save gs and fs and restore them at the end of the routinue?

Who's the fastest? 1, 2 or 3? Thanks.

[roticv]

I would assume that you are coding for 32bit

1. I would recommend that you use dword to store information instead of words.
2. fs is used for seh, so don't mess with that segment register. In fact why are you making use of segment registers? If you are really lacking space you can make use of local variables (if you are not fooling with esp) or mmx/xmm registers.

[The_Grey_Beast]

Well, memory access is slower than registers, so I thought I could use registers to speed up my procedure.
Can't I push fs at the beginning of the routinue and pop it at the end? Wouldn't that restore fs to it's original value?

[pbrennick]

roticv has the right idea here.  Do not mess with segment registers.  Use mmx registers, this will both give you more registers to play with and will also give you a better solution in terms of speed.

Paul

[hutch--]

If you are talking about 32 bit code, the output to screen is very slow anyway so your compression rountine will not be the bottle neck. If what you are trying to write is 16 bit DOS code, I will move this topic to the 16 bit forum.

[The_Grey_Beast]

32-bit code... but thanks anyways... I did a minor optimization step that greatly improved the speed