MIPS: way too comfortable exposing microarchitectural/implementation details in a way that affects program behavior. not just talking about things like load/branch delay slots here - see how the multiplier is implemented in mips3, or how they never bothered to specify memory ordering behavior (and implementations range from TSO to anything-goes)
SPARC: register windows kinda suck. we knew this before they made their way into SPARC. why did they use them anyway? don't really have complaints other than that, SPARC seems otherwise sensible to me
ARM: the problem with ARM the architecture is mainly ARM the company, and the state of the ecosystem. there's been technical decisions that did not hold up, but they've been pretty good about deprecating those things and moving forward. it's still a little complex for my taste.
POWER/PowerPC: ok, i love POWER, but cmon. the instruction encoding complexity is bad. the ABI is bad. neither of those things has an apparent reason, and they're bad enough i couldn't blame anyone for not wanting anything to do with this architecture
RISC-V: ok, i know big endian is out of vogue, but would it really hurt to specify an endianness bit, say you can be big endian if you really want, and be done with it? also, i wish that software-managed TLB was an option. but i understand why it isn't and realistically it makes more sense to do that and implement the software in firmware or microcode so that it is transparent to the OS (like Alpha PALcode)
Embed Notice
HTML Code
Corresponding Notice
- Embed this notice
linear cannon (linear@nya.social)'s status on Monday, 22-Jan-2024 02:47:44 JSTlinear cannon