XPost: alt.folklore.computers   
   From: anton@mips.complang.tuwien.ac.at   
      
   BGB  writes:   
   >counter-argument to ILP64, where the more natural alternative is LP64.   
      
   I am curious what makes you think that I32LP64 is "more natural",   
   given that C is a human creation.   
      
   ILP64 is more consistent with the historic use of int: int is the   
   integer type corresponding to the unnamed single type of B   
   (predecessor of C), which was used for both integers and pointers.   
   You can see that in various parts of C, e.g., in the integer type   
   promotion rules (all integers are promoted at least to int in any   
   case, beyond that only when another bigger integer is involved).   
   Another example is   
      
   main(argc, argv)   
        char *argv[];   
   {   
     return 0;   
   }   
      
   Here the return type of main() defaults to int, and the type of argc   
   defaults to int.   
      
   As a consequence, one should be able to cast int->pointer->int and   
   pointer->int->pointer without loss.  That's not the case with I32LP64.   
   It is the case for ILP64.   
      
   Some people conspired in 1992 to set the de-facto standard, and made   
   the mistake of deciding on I32LP64   
   , and we have paid for   
   this mistake ever since, one way or the other.   
      
   E.g., the designers of ARM A64 included addressing modes for using   
   32-bit indices (but not 16-bit indices) into arrays.  The designers of   
   RV64G added several sign-extending 32-bit instructions (ending in   
   "W"), but not corresponding instructions for 16-bit operations.  The   
   RISC-V manual justifies this with   
      
   |A few new instructions (ADD[I]W/SUBW/SxxW) are required for addition   
   |and shifts to ensure reasonable performance for 32-bit values.   
      
   Why were 32-bit indices and 32-bit operations more important than   
   16-bit indices and 16-bit operations?  Because with 32-bit int, every   
   integer type is automatically promoted to at least 32 bits.   
      
   Likewise, with ILP64 the size of integers in computations would always   
   be 64 bits, and many scalar variables (of type int and unsigned) would   
   also be 64 bits.  As a result, 32-bit indices and 32-bit operations   
   would be rare enough that including these addressing modes and   
   instructions would not be justified.   
      
   But, you might say, what about memory usage?  We would use int32_t   
   where appropriate in big arrays and in fields of structs/classes with   
   many instances.  We would access these array elements and fields with   
   LW/SW on RV64G and the corresponding instructions on ARM A64, no need   
   for the addressing modes and instructions mentioned above.   
      
   So the addressing mode bloat of ARM A64 and the instruction set bloat   
   of RV64G that I mentioned above is courtesy of I32LP64.   
      
   - 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)