64bit games?

Discussion in 'Programming & Software Development' started by Mensuri, Oct 16, 2006.

  1. Pacifist

    Pacifist Member

    Joined:
    Mar 10, 2002
    Messages:
    1,949
    Location:
    Gosford
    Well i'd say it's the biggest barrier to converting code from 32bit to 64bits, as you rely on 3rd parties.

    Also there is no glue to use a 32bit .lib in a 64bit app. You need to have the 32bit library re-compiled to64bit which is impossible without the source code (as in the case of most 3rd party physics and 3d engines).
     
  2. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    There's no reason why you couldn't write something to convert between the different sized quantities.
     
  3. Pacifist

    Pacifist Member

    Joined:
    Mar 10, 2002
    Messages:
    1,949
    Location:
    Gosford

    You can't do it between 32bit static libraries and 64bit apps, there's just no way. Static libraries act as part of your code and are part of the execeutable itself. You can't jump from the 32bit to 64bit code in the executable.
     
  4. Thunder

    Thunder Member

    Joined:
    Jul 22, 2001
    Messages:
    782
    Location:
    Brisbane
    Thats for 16<->32 bit code, there is no such mechanism for 64<->32 bit code.
    The entire application must be 64 bit. you can't mix 32 and 64 bit code at all.


    Most of the problems with porting code to 64 bit is programmers doing stupd/lazy things, such as casting pointers to ints. This works fine in 32 bit code as they are the same size. However this breaks in 64 bit code as a pointer is 64 bits and an int is 32 bits. Similar problems arise in Unix when mixing ints and longs

    A lot of the problem in windows is that Microsofts 64 bit windows compiler does not allow inline assembly, which is widley used in multimedia/math based applications. Any asm code will either need to be re-written in C or ported to 64 bit asm (mostly just to use the extra registers) and compiled and linked seprately. Also, MMX can't be used in 64 bit windows code. (I'm not sure if this is a windows thing or a x64 thing)

    Most code compiles and runs off the bat as 64 bit without an issue, if it's properly written.

    The other part is that lazy vendors don't really want to spend the time porting and testing to get their app working on 64bit platforms.
     
  5. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    I'm sorry, I fail to see why you couldn't call your 32bit library via some compatibility layer if you absolutely had to. Obviously it's not native linking and not nice but saying it's impossible strikes me as odd.

    Edit: speeling ;)
     
    Last edited: Oct 21, 2006
  6. Thunder

    Thunder Member

    Joined:
    Jul 22, 2001
    Messages:
    782
    Location:
    Brisbane
    It's impossible because there is NO compatability layer. an app must be 64 bit the whole way through, no exceptions.
     
  7. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    Um, Vista can run old apps in 32bit compatibility mode. DOSBox supports 16bit code; heck, AMD's architectures are designed for 32/64 bit code! All you need is a compatibility layer to convert the 32bit instructions to equivalent 64bit instructions. There's no big deal here; this technology exists for a long time.

    EDIT: Just to clarify, if it's not already clear: I'm not suggesting that you can mix 32bit and 64bit instructions natively on a given thread. That was never my stance. However, moving to 64bit doesn't automatically render all your 32bit infrastructure useless.
     
    Last edited: Oct 21, 2006
  8. Thunder

    Thunder Member

    Joined:
    Jul 22, 2001
    Messages:
    782
    Location:
    Brisbane

    Right, I thought you were saying that you could mix 32 and 64 bit code within an application? IE: link a 32 bit library into a 64 bit program. That you cannot do.

    That link you posted to Microsofts KB was a mechanisim to link 32 and 16 bit code within the same application, that's why I thought you were talking about mixing code.

    Yes of course a 64 bit operating system can run 32 bit code, It would be pretty useless if it couldn't. I run 64 bit windows and it handles 32 bit apps just fine. (unless they need a 32 bit psuedo device driver)
     
  9. Pacifist

    Pacifist Member

    Joined:
    Mar 10, 2002
    Messages:
    1,949
    Location:
    Gosford
    When you link a .lib file that becomes part of the code. So yes you can run entirely sepearate applications but if you link a static c library it must be compatible with the code it is linked to.
     
  10. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    I posted the link to give an example about how one might go about achieving such a thing. Of course, 32bit instruction sets were much more similar with 16bit ones than 64bit are to 32 so today the same problem involes a less than trivial solution. Your MMX conundrum is a point in case. MMX is no longer part of the x87 instruction set having been dropped in favour of SSE2.

    Anyway, I was just trying to make a point rather than point to a workable approach. :)
     
  11. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    I don't mean to sound rude or anything but reading your posts in this thread it sounds like you're a relatively new programmer. That's not a bad thing -- more power to you -- but I think you're misunderstanding me. If you re-read my posts carefully you'll see I was never disagreeing with what you're saying.
     
  12. Pacifist

    Pacifist Member

    Joined:
    Mar 10, 2002
    Messages:
    1,949
    Location:
    Gosford
    I am an embedded software engineer with many years experience but anyway i forgive you.

    Anyway here is the problem with a compatibility layer-

    When you run the CPU in 64bit mode (not compatibility mode), it expects all address sizes to be 64bits. So the instruction
    mov ax, [0x12345678]
    on a 32bit machine will be compiled as
    0x41 (move to ax) 0x12 0x34 0x56 0x78 (from address 0x12345678)

    In long mode the CPU will expect that address to be 64bits, not 32bits so it will read the next 4bytes as part of the address. This will crash it. In compatibility mode the CPU knows to only read 32bits. The mode (whether long or legacy/compatibility mode) is set by the CR register which is controlled exclusively by the OS.

    Now your link that you provided shows how to do a thunking layer between DLLs and an application (16bit-32bit). I was talking about static libraries. Not that there arn't issues with DLLs.

    With a DLL it may be possible to mix and match. In a DLL you know exactly when you will call them so you can create a layer between them and your code. DLLs are also entirely self contained applications in their own right (hence why you always have a DLLMain() in a dll). When you call a DLL you pass the parameters via the stack then request the OS to run the DLL file starting at a pariticular location. The reason you can't currently use a 32bit DLL is that Windows64 simply doesn't facilitate the changing of long mode to compatibility mode when a call is made. You would also need to ensure your data you pass to it is pointed to by 32bit addresses that match up correctly (this may be impossible if the data is in the area >4GB that only 64bit mode can access).

    Now the main issue that i was talking about is static libraries (not that DLLs don't have problems of their own). These become part of your executable so you link a library containing the compiled instruction mov ax, 0x12345678 into your 64bit code you will have the problems i mentioned above. So i don't see it being possible (at least not easily) to create a layer as there is no room for a layer when the library gets linked straight in. Also there is no way to change the mode on the fly.

    Edit: thought i better format that a bit better (damn fangled technical mumbo jumbo can be hard to read in a big block :p)
     
    Last edited: Oct 21, 2006
  13. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    Cheers ;) The way you kept reiterating simple truisms made me wonder.

    No, you weren't. You were talking about:
    I can't remember the last physics or 3D engine that I used which I shipped as static library. Unless you're writing your own (and even then if you want some reusability) you create dynamic libraries which don't require static linking and can be run through a compatibility layer. As you've so well (if somewhat long-windedly) explained, the problem is switching between 32bit and 64bit instruction sets and instruction lengths in the same process thread. I've never argued against that.

    So... you totally proved my point. To yourself nonetheless! :p
     
  14. Pacifist

    Pacifist Member

    Joined:
    Mar 10, 2002
    Messages:
    1,949
    Location:
    Gosford
    Pretty much any third party 3D or physics API use static libraries (whether d3dx9.lib, openGL32.lib or PacifistsAwesomeEngine.lib :p ). You can call the DLL directly, the libs are just the easier way as they call the DLL for you and include helper code to ensure you call the DLL correctly It also requires some serious hacking to directly use the DLL as the DLLs typically arn't documented.

    Anyway the point i'm trying to make is developers rely on all third parties to release 64bit versions of the libraries etc. Those third parties are then relying on any third parties they used before. So before a game can be recompiled to 64bit the entire tool chain used needs to be re-released. So you can understand why it has taken a while for developers to come on board.
     
    Last edited: Oct 22, 2006
  15. xsive

    xsive Member

    Joined:
    Jun 29, 2001
    Messages:
    4,343
    So, really, what you're saying is that developers haven't started developing 64bit games because they're using crap undocumented tools that lock them in to doing things a certain way and they can't move unless their crack merchant decides to move first. Yup, sounds like Microsoft to me.

    Again, the helper libs are nice to have but there's nothing to stop you hooking into the DLL directly. What you're saying is all true but I view those issues as more political and stemming from poor development practices to begin with. For a start I blame the development shop for not choosing free and open tools.

    A possible solution might be to insert a dynamic proxy between your code and the static libraries that your code depends upon. Bam, problem solved. :)
     
    Last edited: Oct 22, 2006

Share This Page

Advertisement: