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]

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.

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

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

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.

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.

That is exciting for me =)


Do you plan to implement JIT compilation at that time also?

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.