@gunstick @david_chisnall @koakuma @regehr From what I understand they tried to patch around this for a while in the GCC fork they were using but it was a can of worms.
Years into the console cycle they had SN Systems develop their own compiler that had more sophisticated analysis around this and lowered the "clearlady tax" as I've seen it called substantially, but it never entirely went away.
And that's just one of the many issues with that system.
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] with my "operatings system development" hat on i have to ask...
...why not just map the address space multiple times? pointer wraparound doesn't really matter if you just repeat the bottom 4GB
@erincandescent @david_chisnall @gunstick @regehr @koakuma I honestly have no idea why they did it exactly this way.
It also seems like you could just let it fail. Whenever you do a "regA+regB" style addressing mode (so lwzx in PPC) you might legitimately need to either zero- or sign-extend, because that can (if either of these was say a negative index that was multiplied by 28 because that's the size of a struct) need a lot of extra mappings otherwise.
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] i dunno what the PowerPC page tables look like but on both x86 and AArch64 you could just replicate the same entries in the L3/L4/L5 (if present) page tables endlessly.
@erincandescent @david_chisnall @gunstick @regehr @koakuma PPC is not a radix tree unfortunately, it's an inverse page table/hash table.
This has been lamented elsewhere at length: https://yarchive.net/comp/powerpc_page_tables.html
@rygorous @erincandescent @david_chisnall @gunstick @koakuma I always forget that inverse page tables exist and aren't just some bullshit to make life difficult for OS students / instructors
@regehr @rygorous @erincandescent @gunstick @koakuma
They’re only difficult for operating systems if you’ve built a virtual memory system that assumes x86 and makes everything else look like x86 (sadly, this describes Linux and modern NT, though not XNU).
Radix tables are staggeringly bad for virtualisation and a lot of modern workloads, but we’re stuck with them because the designers of the two most popular kernels didn’t build abstractions.
