64bit question

Strictly for discussing ZSNES development and for submitting code. You can also join us on IRC at irc.freenode.net in #zsnes.
Please, no requests here.

Moderator: ZSNES Mods

Post Reply
Spekkio
New Member
Posts: 8
Joined: Sat Jan 14, 2012 11:32 am

64bit question

Post by Spekkio »

64bit cpu's are backward compatible with 32bit cpu's, so shouldn't the 32bit code also run if it is compiled into 64bit anyway?
Or are there lots of other things that I don't know that is different in 64bit, like function calls are different, MMX/SSE stuff are different maybe...?

maybe it's pointless to even try to do this.

compile the asm files with "-f elf64", and target "-march=x86-64", seems to compile ok with a few warnings here and there.

First error I get is when AllowMMX is read/written to, it tries to access to a 64bit pointer in memory thats filled with lots of junk I think.

Code: Select all

    test edx,1 << 23
    jz .nommx
    mov byte[ShowMMXSupport],1
--> mov al,[AllowMMX]
    mov [MMXSupport],al
    jz .nommx


Code: Select all

   0x000000000040d670 <+51>:    je     0x40d6ab <MMXCheck.nommx>
   0x000000000040d672 <+53>:    movb   $0x1,0x9102ee(%rip)        # 0xd1d967 <ntsc_snes+3046855>
=> 0x000000000040d679 <+60>:    movabs 0x963902a2008dca28,%al
   0x000000000040d682 <+69>:    add    %dh,-0x9(%rsi,%riz,1)
   0x000000000040d686 <+73>:    retq   $0x0
   0x000000000040d689 <+76>:    add    %al,(%rdx)


0x963902a2008dca28 cannot be accessed, if it is a pointer, it points way outside RAM!?
Pointer should be at 0x8dca28, why does it say 0x963902a2008dca28 ?
grinvader
ZSNES Shake Shake Prinny
Posts: 5626
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Re: 64bit question

Post by grinvader »

Spekkio wrote:64bit cpu's are backward compatible with 32bit cpu's, so shouldn't the 32bit code also run if it is compiled into 64bit anyway?

Compatibility is at the binary stage, not the code stage. You can run the zsnes executable (32 bits) on your 64-bits machine given you have the needed libraries also in 32 bits. Ok.
But you cannot compile zsnes as a 64 bit program.
When you code stuff with that dual-target idea in mind, interpreters or compilers work out the various kinks needed to build it (hell, even assemblers are dabbling in the stuff, although i fucking hate the syntax you have to use). The bulk of ZSNES is made of hardcoded stuff and cares little for possibilities (like pointers suddenly being twice the size). Which will either break at linktime, or go sour at runtime.

function calls are different, MMX/SSE stuff are different maybe..

You should read more on that stuff, it's tedious to explain. MMX and SSE are not x86 or x64-specific, so they're the same. Function calls are different, but ZSNES has no major stack magic regarding that, so issues shouldn't pop up.

maybe it's pointless to even try to do this.

"You can't compile the current source as 64 bit."
When in doubt, reread last sentence.

A short example: all the core stuff like, you know, snes opcodes, or mmio registers, are implemented in zsnes as function pointer arrays. Those arrays are filled manually. With hardcoded values. Graph time.

Code: Select all

32 bit ZSNES. pointers are 32 bits (4 bytes, represented as [XX] under here)
opcode table after being filled manually= [00][01][02][03] ... [FE][FF]

64 bit ZSNES, pointers are now 64 bits (8 bytes, [--XX--]).
opcode table after being filled manually= [--0[--0[--0[--0 ... [--F[--F@@@@
  The @@@@ indicates that we wrote out of bounds of the array, which could cause a crash with a bit of bad luck.


As you can see, not a single pointer is whole, because they all got half-overwritten by the next one. Calling them will crash or worse.
Now before you mention how easy that would be to fix, go reread the source and do it while you're at it.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Gil_Hamilton
Buzzkill Gil
Posts: 4267
Joined: Wed Jan 12, 2005 7:14 pm

Re: 64bit question

Post by Gil_Hamilton »

Spekkio wrote:64bit cpu's are backward compatible with 32bit cpu's, so shouldn't the 32bit code also run if it is compiled into 64bit anyway?

The CPU is backwards-compatible, which means it can run old code. In fact, a modern 64-bit x86 processor can run old code going all the way back to the original 8086(though 64-bit Windows WON'T run 16-bit code, this is a limitation of Windows, not the processor).

That does not mean old code is usable in the new mode. It just means that the new processor can still run old code.
Just like 16-bit 8086 code won't run in 32-bit mode, 32-bit code won't run in 64-bit mode.
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.


KHDownloads
Spekkio
New Member
Posts: 8
Joined: Sat Jan 14, 2012 11:32 am

Re: 64bit question

Post by Spekkio »

Thanks grinvader, good info! :)

Just like 16-bit 8086 code won't run in 32-bit mode, 32-bit code won't run in 64-bit mode.


OK, I was afraid of that, that the CPU working in a different mode when running a 64bit OS.

I tried bsnes yesterday, looks good, I like the idea about trying to make a accurate emulator. but it's not still as fast as zsnes :)
Gil_Hamilton
Buzzkill Gil
Posts: 4267
Joined: Wed Jan 12, 2005 7:14 pm

Re: 64bit question

Post by Gil_Hamilton »

Spekkio wrote:Thanks grinvader, good info! :)

Just like 16-bit 8086 code won't run in 32-bit mode, 32-bit code won't run in 64-bit mode.


OK, I was afraid of that, that the CPU working in a different mode when running a 64bit OS.

I tried bsnes yesterday, looks good, I like the idea about trying to make a accurate emulator. but it's not still as fast as zsnes :)
Well, it's more complex than that. The x86 architecture has several modes, and has ever since the 286 came out.


But even if it doesn't, the fact that the new CPU can run old code does not mean old code can make use of new features.

To go back several years and find a really convenient example... a MMX Pentium offers no speedups to non-MMX code. Just because it can run "plain" Pentium code doesn't mean that code written for a plain Pentium can utilize MMX without extra work. Even though MMX commands are available to all programs running in protected mode.
Squall_Leonhart wrote:
You have your 2s, 4s, 8s, 16s, 32s, 64s, and 128s(crash course in binary counting!). But no 1s.
DirectInput represents all bits, not just powers of 2 in an axis.


KHDownloads
Post Reply