From: user5857@newsgrouper.org.invalid   
      
   John Savard  posted:   
      
   > On Fri, 03 Oct 2025 08:58:32 +0000, Anton Ertl quoted:   
   > > |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:   
   >   
   > I think that for a computer to be big-endian is a good thing.   
   >   
   > It makes it easier to understand core dumps, as numbers are stored just as   
   > they are written.   
   >   
   > But more importantly, it means that binary integers are ordered the same   
   > way as packed decimal integers, which are ordered the same way as integers   
   > in character text form.   
      
   Nada true:: packed decimal in LE is stored in the same order as binary.   
   Bytes at higher addresses are more significant.   
      
   > As for the _rest_ of the items, though, all of them are indeed bad things.   
   >   
   > But some are worse than others.   
   >   
   > > | - only do aligned memory accesses   
   >   
   > Nearly all memory access are, or could be, aligned. Performance is   
   > improved if they are. As long as there's some provision to handle   
   > unaligned data, such as a move characters instruction, data structures can   
   > be dealt with for things like communications formats.   
   > I'm not saying it isn't bad, just that it was excusable before we had as   
   > many transistors available as we do now.   
      
   I am (AM) a BE guy through and through--but even I can read the writing   
   on the wall. BE is dead and will remain an ever shrinking niche. Making   
   My 66000 architecture LE was  painful; but ultimately the correct   
   decision.   
      
   > > | - expose your pipeline details in the ISA   
   >   
   > The original MIPS did this. This is bad indeed, as whatever you do in this   
   > direction won't be applicable to later iterations of the ISA as technology   
   > advances.   
      
   We {the original RISC generation 1 architects} would have all dropped   
   delayed branches if we believed everyone else would do so. But we knew   
   they wouldn't, so we couldn't allow ourselves to loose 20% perf, so we   
   all jumped off the same cliff like lemmings. That was in the 1-wide   
   generation, by the 2-wide generation we knew it was bad-architecture,   
   by the 4-wide generation we would have all been better off without.   
      
   I do not think any of us would do that to our projects again. I advise   
   you not too either.   
      
   > Failing to support the entire IEEE 754 floating-point standard just needs   
   > to be documented. Expecting software to fake it being implemented is not   
   > reasonable: as long as denormals instead produce zero as the result, one   
   > just has an inferior floating-point format, not a computer that doesn't   
   > work. Once again, bad, but not all that terrible.   
      
   No, just no. There are enough transistors today to "do the right thing"   
   a) full 754-2019 support   
   b) misaligned memory   
   c) hardware table-walkers   
   d) HyperVisor support   
   e) an infinite number of interrupt tables   
      
   > But anything that means that programs could randomly fail because   
   > interrupts don't properly save or restore the entire machine state...   
   > *that* is catastrophically bad, and hardly compares to his other examples.   
      
   We now need to provide for situations where the Guest OS fails, or   
   where Host OS fails; and the system remains up and running while   
   only a few applications die off and guest OS or Host OS reboots   
   from checkpoints.   
      
   > John Savard   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)