Some fun with portable asm code

[MazeGen]

Long time ago, I was seriously thinking about portable asm code between x86-32 and x86-64. I never realized it though. However, my thoughts are now written down in this article:

http://x86asm.net/articles/portable-x86-flat-syntax/

Small demo (MASM) is included. Have fun :)

[jj2007]

Interesting. I stumbled over this statement:

The exception is PUSH const, which always default to current stack width using zero extension

Given that ordinary code contains plenty of memory accesses, not only as push/pop, what are the implications for speed? Is 64-bit code half as fast??  :eek

[MazeGen]

I don't know if I got you right, you meant if there is any penaulty because you always need to PUSH 64-bit operand instead of 32-bit one?

[jj2007]

Yes. After posting, I googled around a bit and found this story confirming my suspicion - although there are arguments pro 64-bit, too. In a nutshell:
- If you have a thousand pointers to variables that count "only" from 0 to 2^31, then doing all these memory accesses with a 64-bit pointer might slow down your code;
- If you manage to make efficient use of the extra registers, you may speed it up.
Of course, even in extreme cases it will never been half as fast... ;-)

[Randall Hyde]

Long time ago, I was seriously thinking about portable asm code between x86-32 and x86-64. I never realized it though. However, my thoughts are now written down in this article:

http://x86asm.net/articles/portable-x86-flat-syntax/

Small demo (MASM) is included. Have fun :)

Since the x64-based OSes all support 32-bit compatibility mode, I'm not sure why anyone would care to have the same assembly code run in 32-bit and 64-bit mode. Indeed, running "only 32-bit code" in 64-bit mode (compiled properly) tends to run slower. The real benefit of 64-bit mode is realized by having the extra registers available.  If you're not going to take advantage of the extra facilities present in 64-bit mode, it makes a lot of sense to compile for 32-bits and run your code in compatibility mode.
Cheers,
Randy Hyde

[Mark Jones]

Also, from my limited experience, Win64 executables impose a much larger memory footprint from the OS -- perhaps by a factor of 2-3x in practice. So a program written in 32-bit may use 10MB of ram, but the 64-bit equivalent uses 30MB. I was shocked to see how much RAM Win XP x64 used on inital install. A nearly bare-bones WinXP dev system on x32 may use 175MB RAM, and a bare-bones x64 version uses 450MB! So anything that can be done to reduce the memory footprint of x64 apps would be greatly beneficial.

[MazeGen]

Since the x64-based OSes all support 32-bit compatibility mode, I'm not sure why anyone would care to have the same assembly code run in 32-bit and 64-bit mode. Indeed, running "only 32-bit code" in 64-bit mode (compiled properly) tends to run slower. The real benefit of 64-bit mode is realized by having the extra registers available.  If you're not going to take advantage of the extra facilities present in 64-bit mode, it makes a lot of sense to compile for 32-bits and run your code in compatibility mode.
Cheers,
Randy Hyde

Hi Randy, it is mostly for fun. I've done some research long time ago and I just wanted to publish it. As I wrote in the lead paragraph, it is weird idea after all.

On the other side, there can be an edge case where you need to assemble the same code for both modes. For example, this can happen if you need to make a project, which must be written in asm and which must run in both 32-bit protected mode and 64-bit mode. It can be more complicated to maintain two similar asm projects for both modes.