From: cr88192@gmail.com   
      
   On 8/6/2025 10:55 AM, Waldek Hebisch wrote:   
   > 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.   
   >   
      
   Something like the X32 style ABIs almost make sense, since most   
   processes need less than 4GB of RAM.   
      
   But, then the problem becomes that one would need both 32 and 64 bit   
   variants of most of the OS shared libraries, which may well offset the   
   savings from using less RAM for pointers.   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)