In comp.arch Anton Ertl <
anton@mips.complang.tuwien.ac.at> 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: fsxNet Usenet Gateway (21:1/5)