Windows support

[nico-abram]

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.

[hippi777]

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! :)

[lukego]

@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.