View unanswered posts | View active topics It is currently Tue Jul 16, 2019 10:12 am



Reply to topic  [ 5 posts ] 
64bit question 
Author Message
New Member

Joined: Sat Jan 14, 2012 11:32 am
Posts: 8
Reply with quote
Post 64bit question
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:
    test edx,1 << 23
    jz .nommx
    mov byte[ShowMMXSupport],1
--> mov al,[AllowMMX]
    mov [MMXSupport],al
    jz .nommx


Code:
   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 ?


Thu Jan 19, 2012 11:39 am
Profile
ZSNES Shake Shake Prinny
User avatar

Joined: Wed Jul 28, 2004 4:15 pm
Posts: 5615
Location: PAL50, dood !
Reply with quote
Post Re: 64bit question
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.

Quote:
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.

Quote:
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:
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:
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)

Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54


Thu Jan 19, 2012 8:19 pm
Profile
Buzzkill Gil

Joined: Wed Jan 12, 2005 7:14 pm
Posts: 4240
Reply with quote
Post Re: 64bit question
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:
Quote:
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


Sat Jan 21, 2012 6:07 am
Profile
New Member

Joined: Sat Jan 14, 2012 11:32 am
Posts: 8
Reply with quote
Post Re: 64bit question
Thanks grinvader, good info! :)

Quote:
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 :)


Sat Jan 21, 2012 12:03 pm
Profile
Buzzkill Gil

Joined: Wed Jan 12, 2005 7:14 pm
Posts: 4240
Reply with quote
Post Re: 64bit question
Spekkio wrote:
Thanks grinvader, good info! :)

Quote:
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:
Quote:
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


Sat Jan 21, 2012 1:21 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 5 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software.