5 ms·
Most of the changes are removals of architectures other than x86_64. What a joke.
by lowry 8y ago
Most of the changes are removals of architectures other than x86_64. What a joke.
- LeifCarrotson 8y agoTo be fair, when I was using Lua a decade ago, LuaJIT mostly only supported Linux and x86-64. Mike was adding new architectures and variants on request and when people would pay him to do so, while the core was both mostly sufficient and still improving. Those 50,000 lines did come after x86-64, if you wanted to move the project in a different direction it seems sensible to strip them out, make your changes. As long as your changes a rent too drastic, it should be comparatively easy to put them back in.
- justincormack 8y agoEach architecture had a hand coded interpreter. The plan is to write a portable interpreter in C.
- timClicks 8y agoAre you willing to contribute to the port? Don't rubbish other peoples' work unless you've got something better to replace it with.
- moocowtruck 8y agogood point, but i think we can admit the title is weird if the only support is x86-64
- lukego 8y agoRaptorJIT is good for writing applications like Snabb. Snabb is a networking framework that’s very low level: cycle-counting loops, device drivers, DMA, etc, in Lua. In this domain of high performance software networking the advantages of supporting other architectures don’t currently outweigh the costs. That’s why it’s a low-level system programming language that prioritizes working very well on x86-64 over supporting other platforms like 32-bit heap, MIPS, Xbox, no FPU, etc. Just got bigger fish to fry right now.
- raytracer 8y ago> no FPU. How much of a hit does floating point math take? I have a desire to build some realtime audio tools.
- justincormack 8y agoThe wording is confusing it does support fpu it doesn’t support machines without fpu.
- DarkWiiPlayer 8y agoIt seems pretty clear to me. It doesn't support "no fpu". It's a lazy way of putting it though and "Architectures without FPU" would have been clearer.
- pygy_ 8y agoAFAIK it is not about float perf. LuaJIT uses NaN-tagging to represent Lua values in memory to save space. Float64 numbers can be left alone, and other types are represented as NaN with the pointer bits stashed in the mantissa part of the float. Only one, canonical NaN value is recognized as such by the language, the others are disguised 32 bit pointers.
- cordite 8y agoOn microcontrollers, you might as well change to lookup tables if you are trying to do something real-time with more than 100 operations per millisecond. This varies by microcontroller obviously.. this comes from reimplementing GLSL shadertoy samples for a neopixel grid.
- lukego 8y agoRealtime audio sounds like a good domain. You might also want to check out LuaRadio if you haven't already. http://luaradio.io/ http://luaradio.io/
- floatboth 8y agoYeah, 32-bit, Xbox and no-FPU platforms can be dropped, but dropping FreeBSD, aarch64 and powerpc64 is kinda sad.
- bbernoulli 8y agoFrom the comment on commit which removed 50,000 lines of code: `The only supported platform is now Linux/x86-64 with JIT+FFI+GC64.` And the readme: `Reduced code maintenance footprint ~50% by removing #ifdef features that are not required for Linux/x86-64 e.g. Windows support, 32-bit heap support, and non-x86 backends. This is a necessary short-term expedient to make the code maintainable while we bootstrap the project.` I wonder how that 50,000 lines was broken down by feature...