From: cr88192@gmail.com
On 10/3/2025 10:41 AM, MitchAlsup wrote:
>
> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>
>> Apparently someone wants to create a big-endian RISC-V, and someone
>> proposed adding support to that to Linux. This has evoked the
>> following design guideline for designing bad architectures from Linus
>> Torvalds (extracted from
>> ):
>>
>> |If somebody really wants to create bad hardware in this day and age,
>> |please do make it big-endian, and also add the following very
>> |traditional features for sh*t-for-brains hardware:
>> |
>> | - virtually tagged caches
>> |
>> | You can't really claim to be worst-of-the-worst without virtually
>> |tagged caches.
>> |
>> | Tears of joy as you debug cache alias issues and of flushing caches
>> |on context switches.
>
> Avoided.
>
>> | - only do aligned memory accesses
>> |
>> | Bonus point for not even faulting, and just loading and storing
>> |garbage instead.
>
> Avoided.
>
>> | - expose your pipeline details in the ISA
>> |
>> | Delayed branch slots or explicit instruction grouping is a great
>> |way to show that you eat crayons for breakfast before you start
>> |designing your hardware platform
>
> Avoided
>
>> | - extended memory windows
>> |
>> | It was good enough for 8-bit machines in order to address more
>> |memory, and became a HIGHMEM.SYS staple in the DOS world, and then got
>> |taken up by both x86 and arm in their 32-bit days as HIGHMEM support.
>
> Avoided
>
>> | It has decades of history, and an architecture cannot be called
>> |truly awful if it doesn't support some kind of HIGHMEM crap.
>> |
>> | - register windows. It's like extended memory, but for your registers!
>> |
>> | Please make sure to also have hardware support for filling and
>> |spilling them, but make it limited enough that system software has to
>> |deal with faults at critical times. Nesting exceptions is joyful!
>> |
>> | Bonus points if they are rotating and overflowing them silently
>> |just corrupts data. Keep those users on their toes!
>
> Avoided
>
>> | - in fact, require software fallbacks for pretty much anything unusual.
>> |
>> | TLB fills? They might only happen every ten or twenty instructions,
>> |so make them fault to some software implementation to really show your
>> |mad hardware skillz.
>
> Avoided--and mine are even coherent so you don't even have to shoot
> them down.
>
>> | denormals or any other FP precision issues? No, no, don't waste
>> |hardware on getting it right, software people *LOVE* to clean up after
>> |you.
>> |
>> | Remember: your mom picked up your dirty laundry from your floor,
>> |and software people are like the super-moms of the world.
>
> Avoided.
>
>> | - make exceptions asynchronous.
>
> Avoided
>
>> | That's another great way to make sure people stay on their toes.
>> |Make sure machine check exceptions can happen in any context, so that
>> |you are guaranteed to have a dead machine any time anything goes
>> |wrong.
>> |
>> | But you should also take the non-maskability of NMI to heart, and
>> |make sure that software cannot possibly write code that is truly
>> |atomic. Because the NM is NMI is what makes it great!
>
> Avoided
>
>> | Floating point! Make sure that the special case you don't deal with
>> |in hardware are also delayed so that the software people have extra
>> |joy in trying to figure out just WTF happened. See the previous entry:
>> |they live for that stuff.
>
> Avoided
>
>> |I'm sure I've forgotten many other points. And I'm sure that hardware
>> |people will figure it out!
>>
>
> A clean sweep.
The alternative position might be:
All jank is acceptable so long as it doesn't significantly impede
performance or negatively impact userland.
Or, maybe, actively embracing the "full jank route".
Possibly Torvalds wouldn't exactly approve though...
Well, except for aligned-only and big-endian, better reasons not to go
that way. Better IMO to just leave everything LE and then use byte-swap
instructions for the rare case one needs to access a big-endian variable.
Well, and then be annoyed that C lacks any standard way to specify the
endianess of variables or pointers; and the need to have compiler
builtins which map to to htonl/ntohl/htons/ntohs/... (with the usual
annoyance that one also needs a generic function fallback in the
background for the case where someone wants to take the function pointer
of one of these functions; sorta like with memcpy and similar).
If I were to try to go in a "jank reducing" direction, probably:
Use XG3 as a design base;
Comparably cleaner and more orthogonal than XG1 and XG2.
Eliminate Modal stuff;
Maybe drop the RISC-V conjoined-twin thing;
Hardware page walker and fully IEEE FPU?...
Probably also add cache coherence.
Mandate zero or sign extended registers as the default (like x86-64);
Put FPU status/control into its own register or similar (*1).
...
Though, unclear is if a "good" core by these definitions could be done
without a significant negative impact on FPGA resource budget.
*1: Sticking it into the HOBs of either GP or SP is ugly, and has an
unreasonable level of footgun potential. So, this is pretty high on my
"I probably need to change this before it ends up getting stuck this way
permanently" thing (in which case, would go back to SP[63:48] being
hard-wired to 0).
This is probably one of those "going to change once I come up with a
better option" situations.
Don't really want to define a new CR for this, but need a place to put
it that:
May be exposed to userland without creating problems;
May be saved/restored on context switches.
Actually, relocating it the HOBs of TBR could almost work here:
Already preserved on context switch;
Not directly visible to RISC-V or XG3 via normal registers;
TP is a shadow of TBR in TestKern, but TP is its own register here.
In this case, might change TP from "Read Only in userland" to "Fault on
attempt to modify low 48-bits in Userland".
Exposure to RISC-V land being the bigger problem, as compilers like GCC
are not going to be aware of "various registers may have weird crap
squirreled into the HOBs" type issues.
Granted, Link-Registers have weird stuff in the HOBs, but generally GCC
doesn't poke at the link register. But, then again, there is still the
"glibc violently explodes if I try to use it" issue, and I can't prove
this is not due to the wacky link registers or similar (would have to
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
