Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows support #255

nico-abram opened this issue Jun 8, 2019 · 2 comments


Copy link

commented Jun 8, 2019

I'm opening this issue for possible discussion about windows support (As far as I can tell it's not currently a goal?). The most similar thing I could find was #157 (Can that issue be closed? Seems relatively resolved for that particular issue and addressed by #93).

I've seen some mentions of raptorjit being a successor of luajit, and I'd be all for that (There's a few things that seem really attractive), but I think a big part of what made luajit might be it's support for different architectures/OSs (Windows, arm, x86, mips, etc). Afaik ARM, windows and x86 are probably the most important/desireable but I could be completely wrong.


This comment has been minimized.

Copy link

commented Jun 8, 2019

hi there! :)

if im right, then ive read somewhere in the past that its not really a goal, but if serious help comes, then they can get back any architectures. on the contrary, it took really much effort to make rj much smaller and handleable. much gone, like platforms, the allocator, the asm interpreter, and i dunno if the c api is/was just under consideration, but ive seen that in the crosshair. so u actually need to be/find a serious guy for the task if its even acceptable by the main rj folks, and i cant even talk in their name, but only hope, that i wont say bulls*t from the wrong chair :D

otherwise it would be much better for everyone if you would switch to linux, its full of fun an joy!!! :D ;) 🐧

bests! :)


This comment has been minimized.

Copy link

commented Jun 9, 2019

@nico-abram Support for more platforms and architectures should follow naturally once we have finished ported the VM from assembler to C (wip on #254.) Help on that would be great, @eugeneia is making a bunch of progress and discussing in #raptorjit lately (#233.)

The problem with adding windows support back right now is that we would need to reintroduce a bunch of #ifdefery in the assembler VM code. I hate that. I don't believe that #ifdef is a legitimate approach to structuring and modularizing a program for multiple architectures. It makes the assembler code much harder to read, with multiple implementations of the same thing scattered all over the place, and much easier to screw up, with multiple register assignment schemas and calling conventions having to be kept in your head at the same time to avoid corrupting something. That's a mess: we have to offload this complexity onto the C compiler instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.