x32 question

[dogman]

Hi Guys,

I understand you cannot access 64 bit registers in 32 bit Intel code with the normal x86 abi. I read the x32 abi is supposed to allows this.

For example is accessing rax from 32 bit code a runtime error due to hardware limitations or is it just an assembly error because intel assemblers except for maybe binutils x32 don't support this mode yet? In other words is the error trying to access 64 bit registers from 32 bit code a hardware issue or a software issue?

If it is just an abi issue then is it correct you should be able to code up a 32 bit piece of code and modify 64 bit registers and use them however you want except for calls to libraries or other pieces of code requiring the historically available abis, correct?

Thanks.

[Rob Neff]

I understand you cannot access 64 bit registers in 32 bit Intel code with the normal x86 abi. I read the x32 abi is supposed to allows this.

Correct.

For example is accessing rax from 32 bit code a runtime error due to hardware limitations or is it just an assembly error because intel assemblers except for maybe binutils x32 don't support this mode yet? In other words is the error trying to access 64 bit registers from 32 bit code a hardware issue or a software issue?

This is mostly a software-compatibility ABI issue.  GNU toolchain ( gas, gcc, binutils, ld, etc. ) all provide x32 support via flags.  Nasm uses the elfx32 output format.  x86 does not support the x32 ABI.  x32 programs can only run under an x64 operating system that has x32 ABI support built it.  Most major Linux distros can be built with x32 support enabled.  However, most pre-built distros only support x86 or x64 out of the box.  I'm not aware of an x32-only operating system. 

If it is just an abi issue then is it correct you should be able to code up a 32 bit piece of code and modify 64 bit registers and use them however you want except for calls to libraries or other pieces of code requiring the historically available abis, correct?

My understanding is that a program compiled/linked as x32 can only call x32 built libraries as there is no backward compatibility to x86 32-bit libraries.  Obviously, you cannot call x64 libraries due to pointer size differences.

[dogman]

Thanks you have confirmed everything I had understood from a quick sitrep.

What happens if you could assemble something like

mov rax,1

in a 32 bit piece of code on a pure 32 bit Linux running on 64 bit hardware? Would it work or cause some kind of runtime error?

I was going to assemble this in 64 bit mode and look at the listing to be able to code the instruction as a constant in a 32 bit piece of code and run it in a debugger but I'm not very handy with Intel-anything and maybe you already know.

[shaynox]

Why you want access 64 bit register in 32 bit Operating system ?

And when I read intel documentation software, it didn't tell me that you can do this:

[dogman]

Thanks for the manual page printouts. They're hard to read because the text doesn't all fit on one page and you can only scroll at the end of the post.

Anyway I would like to understand exactly what the limitation on accessing 64 bit hardware from 32 bit code is. I understand the part about assemblers not allowing you to generate the instructions but I would like to know what would happen if you did run code like the example I mentioned.

[shaynox]

Sorry, I have put better img now, hmm just do a simple bootloader: init 32 bit mode, then execute your instruction: mov   rax, 1.

Then look what your cpu do :p


PS: I testing actually to run this in 32 bit mode      db   0xB8, 0x01, 0x00, 0x00, 0x00         ; mean mov rax, 1

My program didn't made error, so I will look if it's work by display eax.

[shaynox]

-_-

Code: [Select]

[BITS 32]
[section .code use32]
[extern printf]
start:
label:
xor eax, eax
db 0xB8, 0x01, 0x00, 0x00, 0x00 ; mean mov rax, 1

sub esp, 32

mov [esp    ], dword label_1
mov [esp + 4], eax
call printf

add esp, 32


ret

label_1 db "eax = %d", 10, 0


Code: [Select]

@echo off
echo           Assembling test

color 0A
title  Assembling test

cd ..
path 10.TOOLS/;%PATH%

nasm -f win32 1.ASM/testing/source.asm
golink /console /entry start 1.ASM/testing/source.obj 9.DLL/msvcrt.dll

del 4.EXE\testing.exe
ren 1.ASM\testing\source.exe testing.exe
copy 1.ASM\testing\testing.exe 4.EXE\

del 1.ASM\testing\source.obj
del 1.ASM\testing\testing.exe

4.EXE\testing.exe


echo DONE
pause


it's work -_- it  display me eax = 1

WHY ??

[dogman]

Thanks a lot. Ok, so it looks like the whole ABI thing is just bad designs. The hardware really doesn't care. I wonder what else works. Supposedly there are limitations on SSE regs, etc.

[shaynox]

Maybe, but anyway 32 bit is the past, gogo 64 bit :p

No problem.


PS: But like eax is mapped into rax, it's a little logic no ? It's engineering problem lol

[dogman]

Where did you learn 64 bit Intel assembly? I saw you wrote you didn't learn 32 bit.

[shaynox]

back, sry I help another one :p

Hmm, you learn this by ... viewing 64 bit prog ? (cool way^^)

You can read intel doc software: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html


Extra: https://software.intel.com/en-us/intel-isa-extensions
https://msdn.microsoft.com/en-us/library/windows/hardware/ff558891(v=vs.85).aspx

I have upload some personally doc, I hope it will helpful

[Rob Neff]

Why use x32 you may ask?  For access to 64 bit registers, more registers, x64 calling convention ( register params, not stack-based ), but using 32-bit pointers.  It's a Linux ABI spec only ( ie: not applicable to Windows ) on Intel/AMD cpus.  The benefit would be faster execution with reduced memory requirements.  That's the theory anyways.  It hasn't really taken the world by storm since many folks simply moved to x64 and haven't looked back.

[Frank Kotler]

This is all way above my pay grade, but I want to point out that Nasm assembles:

Code: [Select]

bits 64
mov rax, 1
as:

Code: [Select]

mov eax, 1
anyway. To actually see a difference, try a larger number...

Code: [Select]

bits 64
mov rax, -1
To get the same bytes from 32-bit code:

Code: [Select]

bits 32
db 0x48 ; or "dec eax" if you prefer
mov eax, 0xFFFFFFFF
dd 0xFFFFFFFF
I have no idea whether "x32" puts the CPU in "long mode" or not, so I have no idea what'll happen.

While I'm here...

Code: [Select]

section .code use32
... ".code" is not one of the "known section names" in "-f win32" output format (AFAIK). It would be appropriate in "-f obj" format, but may not do what you want here. Probably isn't a problem...

Best,
Frank

[shaynox]

For . code section, hmm i write it, cause for me it's the best description, and i though seen this already one day, after yes it's maybe not a problem, windows recognize this section (or not), i don't have really knowledge for that, i'm lucky so :p

[dogman]

Rob, Shaynox, Frank,

Thank you all for the help. Frank, I suspected mov eax,1 and mov rax,1 generated the same code but didn't have a chance to try it. This is a little disconcerting though as it would seem to indicate in 64 bit mode you can't move 32 quantities to named registers like al ah in the old days (different names for different register portions). I need to get my doc out but of course as soon as I asked this I got involved in a million other things and couldn't get back to actually testing anything.

Is there any difference as far as the hardware is concerned between 32 bit and 64 bit mode aside from stuff like page tables which I ASSume are a mixed software/hardware implementation?

Here's another mind experiment, what would happen with mov r8,1 in 32 bit Linux on 64 bit hardware? Maybe my first test wasn't really a test...