From: anton@mips.complang.tuwien.ac.at   
      
   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.   
   |   
   | - only do aligned memory accesses   
   |   
   |   Bonus point for not even faulting, and just loading and storing   
   |garbage instead.   
   |   
   | - 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   
   |   
   | - 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.   
   |   
   | - 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!   
   |   
   | - 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.   
   |   
   |   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.   
   |   
   | - 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.   
   |   
   |   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!   
      
   --   
   'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'   
     Mitch Alsup,    
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)