From: cr88192@gmail.com   
      
   On 10/3/2025 3:58 AM, Anton Ertl wrote:   
   > 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   
   > ):   
   >   
      
   Yeah...   
      
   Sadly I kinda feel called out here.   
      Wouldn't necessarily get the Torvalds' seal of approval...   
      
      
   > |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.   
   > |   
      
   Sorta applies to my core...   
   Though the L1D$ also remembers the Phys-Addr and uses this for Write-Back.   
      
      
   > | - only do aligned memory accesses   
   > |   
   > |   Bonus point for not even faulting, and just loading and storing   
   > |garbage instead.   
   > |   
      
   Avoided in BJX2 Core.   
      
   Would apply to my smaller BSR1 and B32V cores (aligned only = cheaper).   
      
      
   > | - 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   
   > |   
      
   Former true of SuperH.   
      Both true of BJX1.   
      Latter true of BJX2 XG1/XG2.   
      
   Not true of XG3, which went over to superscalar.   
      
   WEX Bundling may have been a mistake in retrospect...   
      
      
      
   > | - 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.   
   > |   
   > |   It has decades of history, and an architecture cannot be called   
   > |truly awful if it doesn't support some kind of HIGHMEM crap.   
   > |   
      
   Avoided.   
      
      
   > | - 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.   
   > |   
      
   Errm, true of BJX2.   
      
   Though, TLB Misses are nowhere near that frequent though (if they were,   
   performance would be unusable dog crap).   
      
      
   > |   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.   
   > |   
      
   Also true of my core.   
      
      
   It also now pretends to have Binary128, pretty much entirely by software   
   traps.   
      
   But, trapping has less code footprint, so if sinl/cosl/... are used,   
   they wont burn as much space in ".text" with the function calls (and if   
   I can trap out of RISC-V mode, then it can use 128-bit math and a few   
   other features that don't exist in RV64, so it isn't necessarily slower   
   than using a function call).   
      
      
      
   > |   Remember: your mom picked up your dirty laundry from your floor,   
   > |and software people are like the super-moms of the world.   
   > |   
      
   But, makes hardware cheaper...   
      
      
   > | - make exceptions asynchronous.   
   > |   
   > |   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.   
   > |   
      
   Avoided:   
   TLB Miss handling really needs precise exceptions in order to work   
   correctly.   
      
      
   > |   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!   
   > |   
   > |   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.   
   > |   
   > |I'm sure I've forgotten many other points. And I'm sure that hardware   
   > |people will figure it out!   
   >   
      
   Ignoring HOB's in pointers except in certain edge cases?...   
      
   I have mixed feelings about having put FPU status in HOBs of SP   
   (possible foot gun).   
      
   Weak coherence, with special rituals needed to actually get caches   
   flushed?...   
      
   Bit-slicing certain address calculations so the relevant structures have   
   mandatory alignment?...   
      
   Interrupt entry is basically just a glorified branch-with-mode change,   
   so the ISR handler has to go through a convoluted sequence to get to   
   where it can start saving off the registers?...   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)