serenity
serenity copied to clipboard
SerenityOS
LibJS not supported on ppc64le
[ 155s] /home/abuild/rpmbuild/BUILD/serenity-0+1702743748.ac79ab0b45/Userland/Libraries/LibJS/Runtime/Value.h:434:6: error: #error "Unknown architecture. Don't know whether pointers need to be sign-extended."
[ 155s] 434 | # error "Unknown architecture. Don't know whether pointers need to be sign-extended."
Apparently on amd64 pointers are sign-extended from 48bit to 64bit, and on arm64 the top bits are zero. There is no reason given so I cannot decide which should be used on a new platform.
This is required for the NaN Boxing implementation in LibJS. If NaN Boxing is not possible on a specific platform, then we would need to think really hard about how to store JS::Values.
Putting Indian bread into boxes?
Anyway, I see LibJS is one of those runtimes that require those legacy memory mapping workarounds that prevent any memory mapping above 48bit.
Still why the boxing is different on different platforms?
Aren't float formats standardized by now?
I haven't touched PPC before so this is what I found searching the internet:
According to https://www.kernel.org/doc/ols/2001/ppc64.pdf user effective addresses have their top 21 bits cleared, so there wouldn't actually be a difference between zero-extending and sign-extending (bit 47 is 0), so you can just add PPC to the (simpler) AArch64 branch.
(Kernel addresses >= 0xC000000000000000 should never end up in JS::Values so we don't have to worry about preserving the top bits)
That's no longer true, the address space is > 50bit by now, just like any other 64bit platform.
Still why the boxing is different on different platforms?
When we extract a pointer bits out of the NaN value, on some platforms we need to sign extend it before accessing it or the CPU gives a hardware exception.
That's no longer true, the address space is > 50bit by now, just like any other 64bit platform.
https://developer.arm.com/documentation/101811/0103/Address-spaces/Size-of-virtual-addresses " Note All Armv8-A implementations support 48-bit virtual addresses. Support for 52-bit virtual addresses is optional and reported by ID_AA64MMFR2_EL1. At the time of writing, none of the Arm Cortex-A processors support 52-bit virtual addresses."
I'm not sure what consumer desktop hardware is out there that supports 52-bit addresses, but it's possible that they exist? We probably need to figure out what to do with our NaN boxing once that becomes a thing, but I'm sure that V8, SpiderMonkey and JSC will need to solve that problem first and we can just look at their homework.
Just like on the other 64bit architectures you should get flagged as 'legacy' by default and get only the low 48bits enabled.
If some application wanted to use more address bits and LibJS at the same time that could be problematic.
Picking the amd64/riscv option the library builds. Are there some tests that could verify that this is working?
Presumably the difference between the two options would be only noticeable when using an address with bit 47set which would happen rarely under everyday use.
Are there some tests that could verify that this is working?
test-js is the canonical one. Using the script, Meta/serenity.sh test lagom JS. Or if you have the test-js binary already, ctest --test-dir Build/lagom -R "JS$" (or wherever your CMake binary directory is).
I am building in the Ladybird directory and then ctest fails to find the tests