From: antispam@fricas.org   
      
   In comp.arch Anton Ertl  wrote:   
   >   
   > 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.   
      
   Obectively, a lot of programs fit into 32-bit address space and   
   may wish to run as 32-bit code for increased performance.  Code   
   that fits into 16-bit address space is rare enough on 64-bit   
   machines to ignore.   
      
   > 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.   
      
   It is more complex.  There are machines on the market with 64 MB   
   RAM and 64-bit RISCV processor.  There are (or were) machines   
   with 512 MB RAM and 64-bit ARM processor.  On such machines it   
   is quite natural to use 32-bit pointers.  With 32-bit pointers   
   there is possibility to use existing 32-bit code.  And   
   IPL32 is natural model.   
      
   You can say that 32-bit pointers on 64-bit hardware are rare.   
   But we really do not know.  And especially in embedded space one   
   big customer may want a feature and vendor to avoid fragmentation   
   provides that feature to everyone.   
      
   Why such code need 32-bit addressing?  Well, if enough parts of   
   C were undefined compiler could just extend everthing during   
   load to 64-bits.  So equally well you can claim that real problem   
   is that C standard should have more undefined behaviour.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)