Question/Request: Does RapidJIT support windows kernel/driver addressspace (all upper bits set)

[hendrikp]

One reason LuaJIT couldn't be ported to 64bit in a project of mine was the limitation to the 47-bit addressspace(due to the double-tagging) even after the changes to the gc the last years. Is RapidJIT now working in full 64bit-addresspace and doesn't make use anymore of undocumented win api hacks that might not be working in kernel mode?

Or if not might there be interest in a sponsorship for changing RapidJIT to use normal allocations that support true 64-bit addresses everywhere (userdata+luadata).

Thanks for the feedback

[lukego]

The 96-bit VM (#93) would allow us to use full 64-bit addresses. This would divide tagged values into a 32-bit type tag and a 64-bit value. This has not been implemented yet but to me it seems very promising.

Note that RaptorJIT does not support Windows. Supporting new operating systems would require active maintenance, full CI test coverage, and generally being a net-positive for users of existing platforms. This can be done but it can't be taken lightly.

P.S. Is there actually a CPU that supports full 64-bit address space in hardware? That would be news to me.

[hendrikp]

Ah ok sad to hear that windows is not supported, I'm not sure about CPU's physical addresses as those can't be made use of anyways; the virtual addresses in windows kernel mode have all upper bits set (kinda negative address range if you can imagine).

[lukego]

@hendrikp I'd bet there is a simple solution that you can use with LuaJIT. Sounds like you only need signed/sign-extended addresses. I would be surprised if there is not a well-known solution for this on x86. I'd start by looking in the Intel CPU manuals where they describe how the bits of an address are actually interpreted by the CPU.

[lukego]

@hendrikp Just to clarify: I am saying that virtual addresses on x86-64 are not really 64-bit on the hardware level. They are more like signed 48-bit numbers that look 64-bit due to sign extension. So I reckon you could pretty well encode any practical address in the bits LuaJIT provides.

See https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details for more details.

[hendrikp]

yeah im aware of that i just wouldn't know where to even start with that im more of a C / C++ guy it would be outside of the teams/projects scope to start analyzing/extending/maintaining assembler-code. We will just have to switch to Lua 3.3 for 64bit until there maybe is a ready stable solution available. 2018-02-07 13:02 GMT+01:00 Luke Gorrie <notifications@github.com>:

…

@hendrikp <https://github.com/hendrikp> Just to clarify: I am saying that *virtual addresses* on x86-64 are not really 64-bit on the hardware level. They are more like signed 48-bit numbers that look 64-bit due to sign extension. So I reckon you could pretty well encode any practical address in the bits LuaJIT provides. See https://en.wikipedia.org/wiki/X86-64#Virtual_address_space_details for more details. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH99glzpG4Dibwnsfuq-b7ubBJttAm_ks5tSZDxgaJpZM4R8WyV> .

[lukego]

@hendrikp If you want professional help to work out what the issue is and find a solution I can help you with that via http://snabb.solutions/. Windows should not be a problem if you use LuaJIT rather than RaptorJIT as the base.

[hendrikp]

Thanks i will pass on the contact information it might really be an option if you think that a feasable change that results in a stable luajit run-time (currently were on 2.0.5 because we think that this is still more stable then 2.1.x). 2018-02-07 14:10 GMT+01:00 Luke Gorrie <notifications@github.com>:

…

@hendrikp <https://github.com/hendrikp> If you want professional help to work out what the issue is and find a solution I can help you with that via http://snabb.solutions/. Windows should not be a problem if you use LuaJIT rather than RaptorJIT as the base. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH99oYq90sy-VO8I_ZSulTKvLDIvE1Yks5tSaC5gaJpZM4R8WyV> .