[continued from previous message]   
      
   > it to the lower 8 bits,   
      
        MULUB    R7,R8,R9      // result range [0..255]   
      
   >                         or worse treat the result as Int8 and take   
   > whatever random value falls in bit [7] as the sign, then that's on you.   
      
       MULSB     R7,R8,R9      // result range [-128..127] or OVERFLOW   
      
   Personally, I prefer range checks that raise OVERFLOW.   
      
   > They just force you to be explicit what you are doing.   
   >   
   > > --------------------------------------------------------------   
   > > Integer instructions are now::   
   > >      {Signed and unSigned}×{Byte, HalfWord, Word, DoubleWord}   
   > > while FP instructions are now:   
   > >      {Byte, HalfWord, Word, DoubleWord}   
   >   
   > I doubt any compilers will use this feature.   
      
   RISC-V and ARM LLVM compilers already do this and use it to eliminate   
   smashes. RISC-V is limited to WORD, ARM uses registers of WORD size.   
   Both eliminate smashes. Since there are already LLVM compilers using   
   this (to eliminate smashes) it should be not terribly difficult to add.   
      
   On the other hand:: ILP64 ALSO gets rid of the problem (at a different cost).   
      
   > Strong typed languages don't have predefined operators that allow mixing.   
   > Weak typed languages deal with this in overload resolution and by having   
   > predefined invisible type conversions in those operators and then using   
   > the normal single type arithmetic instructions.   
   >   
   > > Although I am oscillating whether to support FP8 or FP128.   
   >   
   > The issue with FP8 support seems to be that everyone who wants it also   
   > wants their own definition so no matter what you do, it will be unused.   
      
   Thank you for your input.   
      
   > The issue with FP128 seems associated with scaling on LD and ST   
   > because now scaling is 1,2,4,8,16 which adds 1 bit to the scale field.   
   > And in the case of a combined int-float register file deciding whether   
   > to expand all registers to 128 bits, or use 64-bit register pairs.   
      
   My position is that people want 64-bit registers and ISA that allow   
   reasonably easy and efficient access to 128-bits, CARRY provides this.   
   But the architecture is not cut out to be a big 128-bit number cruncher;   
   occasional sure, but all the time, no.   
      
   > Using 128-bit registers raises the question of 128-bit integer support,   
   > and using register pairs opens a whole new category of pair instructions.   
      
   CARRY supports this.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)