From: anton@mips.complang.tuwien.ac.at   
      
   Thomas Koenig  writes:   
   >Kent Dickey  schrieb:   
   >   
   >> GCC has actually optimized the loop itself better, but it has lots of   
   >> fixup code to create 64-bit register versions of the unsigned inputs   
   >> (because the RISC-V ABI specifies all 32-bit quantities must be   
   >> sign-extended at the function call boundaries, even if they are   
   >> unsigned).   
   >   
   >You mean 0xffffffff as unsigned has to be passed as   
   >0xffffffffffffffff ?  Somebody was not thinking that one through...   
      
   I am sure they did think that one through.  The manual says:   
      
   |The compiler and calling convention maintain an invariant that all   
   |32-bit values are held in a sign-extended format in 64-bit   
   |registers. Even 32-bit unsigned integers extend bit 31 into bits 63   
   |through 32. Consequently, conversion between unsigned and signed   
   |32-bit integers is a no- op, as is conversion from a signed 32-bit   
   |integer to a signed 64-bit integer. Existing 64-bit wide SLTU and   
   |unsigned branch compares still operate correctly on unsigned 32-bit   
   |integers under this invariant. Similarly, existing 64-bit wide logical   
   |operations on 32-bit sign-extended integers preserve the   
   |sign-extension property. A few new instructions (ADD[I]W/SUBW/SxxW)   
   |are required for addition and shifts to ensure reasonable performance   
   |for 32-bit values.   
      
   What I find more interesting is that MIPS apparently made the same   
   choice.  In the early 90s a lot of code was around which did not   
   provide prototypes, code that worked on 32-bit systems because there   
   was no difference between int and long, and between unsigned int and   
   unsigned long.  I expect such code to have a better chance to work as   
   intended in an I32LP64 setting if unsigned is zero-extended (and the   
   choices for SPARC and PowerPC are along these lines).  So why did the   
   MIPS people go that way?   
      
   One other interesting thing is how various architectures define the   
   upper 32 bits of existing instructions when they extend to 64 bits.   
   Let's consider addition:   
      
   MIPS-IV: addu performs sign-extended 32-bit addition (and the instruction   
   is called "Add Unsigned Word":-); they added daddu for 64-bit   
   addition.  They undefined the result of addu if the inputs were not   
   sign-extended 32-bit numbers to make their lack of competence more   
   obvious.   
      
   SPARC and PowerPC: The addition instructions perform 64-bit addition.   
   No extra 32-bit variant was added.   
      
   AMD64 is actually a new instruction set incompatible with IA-32, but   
   given that AMD64 is so close to IA-32 that their decoder is shared on   
   all implementations I know of, I include it here: AMD64 defines the   
   existing instructions as producing the same result as on IA-32 (that   
   includes instructions like shift-right and division where the upper   
   bits of a 64-bit operation would play a role), with the upper 32 bits   
   being zero, and adds 64-bit variants.   
      
   ARM A64 is a completely new 64-bit instruction set.  There have been   
   efforts for an ILP32 ABI, but I don't think that this instruction set   
   was designed for that.   
      
   RISC-V was designed for both 32-bit and 64-bit settings.  The add   
   instruction performs the full 64-bit addition in 64-bit   
   implementations.  The 64-bit extension adds addw (along with addiw   
   slliw srliw sraiw sllw srlw subw sraw), which sign-extends the lower   
   32 bits of its result.  addw produces a defined result for all inputs.   
      
   - anton   
   --   
   '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)