Jump to content
  • Advertisement
Sign in to follow this  
lantic

x64 support & late binding of classes

This topic is 5171 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Well, being that all calling conventions are the same on x64, then we should definitely keep the asCALL_CDECL, asCALL_STDCALL, etc as is, and have them map to the one internal calling convention ICC_FASTCALL.

I'll have to analyse the pointer issue before giving the final answer. One thing, the bytecode that is saved to disk should be compatible between all version of the library, but that doesn't stop us from having a different internal representation on 64bit processors.

If you feel up to it, you may change the library anyway you need to get it working on 64bit processors. Then you can pass me the code, and I'll find a way to unify the code so that it compiles on both 32bit and 64bit systems. You'll probably have to change the size of some bytecodes, to accomodate for the 64bit pointers.

I'm reluctant to make the AngelScript stack be align to 16byte words, as it would consume a lot more memory. To begin with what you have done is enough, but perhaps it would be possible to customize the stack alignment with a preprocessor flag for optimal behaviour.

Regards,
Andreas

PS. I wish I had a 64bit system to test this on. Anyone willing to donate one to me? [wink]

Share this post


Link to post
Share on other sites
Advertisement
Yep, the ICC_FASTCALL definition sounds good.

One thing that I thought of was to have the AS stack 8 byte aligned. This would aid in passing double values & (obviously) 64-bit pointers around without having unaligned data access costs & pointer size issues on x64. Although obviously it still wastes space on x86, these articles have some interesting bits on the subject of stack alignment:


http://www.fftw.org/fftw3_doc/Stack-alignment-on-x86.html


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vcconwindowsdataalignmentonipfx86x86-64.asp


I'll start taking a look at pointer issues tonight. Hopefully it won't be too bad... And sorry Andreas, I've only just got access to an AMD64 system myself. Assembly is great though - the extra 8 registers make all the difference.

Cheers,
Will.

Share this post


Link to post
Share on other sites
My mistake, when you said to make the stack 8-byte aligned, I somehow thought that all variables had to be 8-byte aligned. [wink]

Of course, proper data alignment will be implemented. Some of this work was already done with the port to Dreamcast which requires aligned data in order to work. I will expand this to conform with the rules for 64bit processors as well. I consider this optimizations though, and currently that is quite low priority for me.

Thanks for the links, these are very good indeed, especially the MSDN one.

Together we will be able to make AngelScript work on both 32bit and 64bit systems. I greatly appreciate that you take the time to do this.

Regards,
Andreas

Share this post


Link to post
Share on other sites
I've decided that the next step (after finishing 2.4.0) will be a major revision of the VM. In this revision I will try to prepare the library as much as possible for 64bit support as well as add register based operations, which should make the VM much more efficient.

Things that will be done are to support variable sized pointers, aligned variables, including stack memory, etc. I'll also change the byte code instructions to read constants from a special memory buffer (that will use proper alignment) instead of having the constants inside the byte code. All byte code instructions will be 32bit in size, with room for arguments so that operations with three operands can be made.

Saving and loading byte code compiled for a 64bit machine will not be compatible on a 32bit machine, and vice versa. At least not in the beginning.

Unfortunately that ASM VM will no longer work when I make these changes. But, I'm sure that the new C++ VM will be much more efficient than the current ASM VM anyway. It will also be good to have only one VM to maintain again [wink].

64bit processors are getting more popular by the minute, and AngelScript must not be too late in supporting them or it will hurt the libraries popularity. I will do what I can to add this support, but I'll have to rely on you guys to test it for me since I don't have a 64bit processor myself.

Just thought I'd let you know what my plans are.

Regards,
Andreas

Share this post


Link to post
Share on other sites
Andreas, That's good news. I have made initial attempts to adapt the bytecode to support 64bit pointers but ran into various problems, usually due to assumptions made by other bits of code. The function calling code for x64 is still valid however - do you want a copy?

Anyway, I look forward to the new register based VM & would be more then happy to help you test & bugfix it for x64.

Cheers,
Will.

Share this post


Link to post
Share on other sites
Yes, I can imagine the problems you had.

Please send me the code for calling functions on 64bit processors. I'll include it when starting the change of the VM. You'll of course be credited for the constribution. :)

I'm sure that we will have a lot of testing to do once the work starts, but I think it will be interesting to learn more on 64bit support.



Share this post


Link to post
Share on other sites
No, JIT compilation is still far away. But I'm sure the planned changes for the VM will make future support for JIT compilation a lot easier.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!