Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
RayeR(R)

Homepage

CZ,
22.01.2014, 23:44
 

64-bit long mode compatability with 32-bit instructions-GAS (Developers)

Hi,
in my multiplatform C code (I use GCC) I have a few lines of inline assembler. I tried it to recompile under 64-bit Linux and I got an error from gcc/gas that some instructions has invalid suffix, e.g.:
" pushfl ; "
" popl %%eax ; "
I searched for solution and found that I have to use 64-bit extended instructions instead so I used:
#ifdef __x86_64__
" pushfq ; "
" popq %%rax ; "
Now it seems to work. Do I really need to make branching for 32-bit and 64-bit platform? Does it mean that if CPU is in long mode it is not compatible with 32b (and 16b) instructions? Then how does 64-bit windows run older 32-bit apps without recompiling? I know that it use some WoW64 layer but I don't know what it is exactly doing. If I would use long mode under DOS then do I need to write all in 64-bit asm (otherwise will I got invalid opcode exception)?

---
DOS gives me freedom to unlimited HW access.

Rugxulo(R)

Homepage

Usono,
23.01.2014, 01:10

@ RayeR
 

64-bit long mode compatability with 32-bit instructions-GAS

> Hi,

Hopefully marcov (amd64 expert) can chime in more here.

> in my multiplatform C code (I use GCC) I have a few lines of inline
> assembler. I tried it to recompile under 64-bit Linux and I got an error
> from gcc/gas that some instructions has invalid suffix, e.g.:
> " pushfl ; "
> " popl %%eax ; "
> I searched for solution and found that I have to use 64-bit extended
> instructions instead so I used:
> #ifdef __x86_64__
> " pushfq ; "
> " popq %%rax ; "
> Now it seems to work.

Presumably this is to avoid misaligning the stack since SSE is mandatory.

> Do I really need to make branching for 32-bit and
> 64-bit platform?

Compatibility is rarely as simple as just recompiling.

> Does it mean that if CPU is in long mode it is not
> compatible with 32b (and 16b) instructions?

Not 100%, no, you have to avoid some instructions (e.g. AAM, SAHF) and keep in mind that "xor eax,eax" will clear rax (etc. etc.) among other things.

> Then how does 64-bit windows run older 32-bit apps without recompiling?

It's not 100% transparent. You can't mix drivers or plugins or libraries. All of that has to be duplicated / redone. Windows server editions (I think) even make the 32-bit compatibility optional.

> I know that it use some WoW64
> layer but I don't know what it is exactly doing. If I would use long mode
> under DOS then do I need to write all in 64-bit asm (otherwise will I got
> invalid opcode exception)?

No idea, probably can't use long mode + DOS at all. It wasn't really designed for that (although VT-X maybe allows a way, indirectly). In other words, you're probably expected to host a 16-bit VM atop a 64-bit OS rather than trying the opposite.

P.S. Don't forget that some people don't want to be compatible, they want you to "upgrade" to them, exclusively! It's not a given that they want to help you at all.

Oso2k(R)

23.01.2014, 01:34

@ RayeR
 

64-bit long mode compatability with 32-bit instructions-GAS

> Now it seems to work. Do I really need to make branching for 32-bit and
> 64-bit platform? Does it mean that if CPU is in long mode it is not
> compatible with 32b (and 16b) instructions? Then how does 64-bit windows
> run older 32-bit apps without recompiling? I know that it use some WoW64
> layer but I don't know what it is exactly doing. If I would use long mode
> under DOS then do I need to write all in 64-bit asm (otherwise will I got
> invalid opcode exception)?

My understanding (though I have yet to read extensively) is that x86-64 mode is incompatible with all previous modes, at least as implemented by Apple and, Windows. Essentially, this means they operate in Long-mode/64-bit mode. Linux/gcc supports "multilib" as you know, but I would have to venture a guess the ELF header is different or used as a signal to enter "Long mode/compatibility mode.

RayeR(R)

Homepage

CZ,
23.01.2014, 03:03

@ RayeR
 

64-bit long mode compatability with 32-bit instructions-GAS

Well, about WoW64 I read on wiki and it's clear then that it does CPU mode switching so this means that 32b code cannot be executed natively and I do need branching for some cases. BTW can I manipulate AX or AH in long mode? Maybe yes for reg2reg moves but push/pop to stack is forbidden and valid only for 64b regs.
http://en.wikipedia.org/wiki/WoW64
Technically, WoW64 is implemented using three dynamic-link libraries (DLLs):
1. Wow64.dll, the core interface to the Windows NT kernel that translates between 32-bit and 64-bit calls, including pointer and call stack manipulations
2. Wow64win.dll, which provides the appropriate entry-points for 32-bit applications
3. Wow64cpu.dll, which takes care of switching the processor from 32-bit to 64-bit mode
...switches the processor hardware from its 64-bit mode to compatibility mode when it becomes necessary to execute a 32-bit thread, and then handles the switch back to 64-bit mode.

BTW when WoW64 switches CPU to 32b mode (or what else is "compatibility mode") then it should be possible to switch it to v86 mode and execute 16b code too?

---
DOS gives me freedom to unlimited HW access.

alexfru(R)

USA,
23.01.2014, 08:34

@ RayeR
 

64-bit long mode compatability with 32-bit instructions-GAS

> Well, about WoW64 I read on wiki and it's clear then that it does CPU mode
> switching so this means that 32b code cannot be executed natively

Why not? It can and does. The switch is needed because the kernel is 64-bit, while the caller (your app) is not and you need to switch between the two modes since 32-bit code won't execute in 64-bit mode correctly and the other way around.

> and I do
> need branching for some cases. BTW can I manipulate AX or AH in long mode?

You surely can, the register is still there for you.

> BTW when WoW64 switches CPU to 32b mode (or what else is "compatibility
> mode") then it should be possible to switch it to v86 mode and execute 16b
> code too?

Unfortunately, no. Once you've got into long/64-bit mode, only 16- and 32-bit protected compatibility modes can coexist with it. V86 and real mode can't. Your only options for real-mode/v86 code are:
- code emulation
- hardware virtualization (note that older Intel's CPUs with VT didn't quite support real/v86 VMs, while AMD's with Pacifica did, not to mention the fact that the two implementations need two different versions of the Hypervisor)
- leaving long/64-bit mode completely (undoing all things that were required to set it up) and either switching to 32-bit protected mode (if you are OK with v86) or going one step further and leaving protected mode altogether.

georgpotthast(R)

Homepage

Germany,
23.01.2014, 20:16

@ alexfru
 

64-bit long mode compatability with 32-bit instructions-GAS

Alex knows this stuff in and out. :ok: I guess you could consult the Intel developers in this field.

By the way Japheth made a real nice example how to switch all the way to long mode and back:

http://www.japheth.de/JWasm/Dos64.html

marcov(R)

23.01.2014, 21:57

@ RayeR
 

64-bit long mode compatability with 32-bit instructions-GAS

> Now it seems to work. Do I really need to make branching for 32-bit and
> 64-bit platform? Does it mean that if CPU is in long mode it is not
> compatible with 32b (and 16b) instructions?

Yes. I think flags is simply not subdivided. (can you push 16-bits flags in 32-bit mode?)

> Then how does 64-bit windows
> run older 32-bit apps without recompiling?

The same way that 32-bit win9x runs 16-bits dos.

> then do I need to write all in 64-bit asm (otherwise will I got
> invalid opcode exception)?

No, you can use 32-bit eax for instance. Just not all registers have such legacy subdivisions.

Afaik even the new registers have 32-bit subdivisions (r11d, r11w,r11b etc), but they don't have -H variants.

Back to index page
Thread view  Board view
15192 Postings in 1365 Threads, 250 registered users, 16 users online (0 registered, 16 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum