From: user5857@newsgrouper.org.invalid
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> kegs@provalid.com (Kent Dickey) writes:
> >In article <2025Oct4.121741@mips.complang.tuwien.ac.at>,
> >Anton Ertl wrote:
> >>MitchAlsup writes:
> >>>int subroutine( int a, int b )
> >>>{
> >>> return a+b;
> >>>}
------------------------------------------------------------
>
> >RISC-V is in another land, where they effectively have
> >no 32-bit operations, but rather a convention that all 32-bit inputs
> >must be sign-extended in a 64-bit register.
>
> RISC-V has a number of sign-extending 32-bit instructions, and a
> calling convention to go with it.
RISC-V has word sized integer arithmetic.
>
> There seem to be the following options:
>
> Have no 32-bit instructions, and insert sign-extension or
> zero-extension instructions where necessary (or implicitly in all
> operands, as I outlined earlier). SPARC V9 and PowerPC64 seem to take
> this approach.
This was My 66000 between 2016 and two weeks ago.
The cost is 4% growth in code footprint and similar perf degradation.
> Have 32-bit instructions that sign-extend: MIPS64, Alpha, and RV64.
>
> Have 32-bit instructions that zero-extend: AMD64 and ARM A64.
>
> Have 32-bit instructions that sign-extend and 32-bit instructions that
> zero-extend. No architecture that does that is known to me. It would
> be a good match for the SPARC-V9 and PowerPC64 calling convention.
This is the starting point for My 66000 2.0:: integer arithmetic has
size and signedness, with the property that all integer results have
the 64-bit register contain a range-limited result suit-
able to the base-type of the calculation {no garbage in HoBs}.
> There is also one instruction set (ARM A64) that has special 32-bit
> sign-extension and zero-extension forms for some operands.
>
> And you can then adapt the calling convention to match the instruction
> set. For "no 32-bit instructions", garbage-extension seems to be the
> cheapest approach to me, but I expect that when SPARC-V9 and PowerPC64
> came on the market, there was enough C code with missing prototypes
> around that they preferred a more forgiving calling convention.
>
> >If you pick ILP64 for your ABI, then you will get rid of almost all of
> >these zero- and sign-extensions of 32-bit C and C++ code. It will just
> >work. If you pick I32LP64, then you should have a full suite of 32-bit
> >operations and 64-bit operations, at least for all add, subtract, and
> >compare operations.
>
> For compare, divide, shift-right and rotate, you either first need to
> sign/zero-extend the register, or you need 32-bit versions (possibly
> both signed and unsigned).
My 66000 CMP is signless--it compares two integer registers and delivers
a bit vector of all possible comparisons {2 equality, 4 signed, 4 unsigned,
4 range checks, [and in FP land 10-bits are the class of the RS1 operand]}
My 66000 SL, SR can be used in extract form--and here you need no operand
preparation if you only extract meaningful bits.
My 66000 2.0 DIV has a size component to the calculation.
> >And if you do I32LP64, your indexed addressing
> >modes should have 3 types of indexed registers: 64-bit, 32-bit signed,
> >and 32-bit unsigned. That worked well for ARM64.
>
> It is certainly part of the way towards my idea of having sign- and
> zero-extended 32-bit operands for every operand of every instruction.
Unnecessary if the integer calculation deliver properly range-limited
64-bit results.
> It would be interesting to see how many sign-extensions and
> zero-extensions (whether explicit or implicitly part of the
> instruction) are executed in code that is generated from various C
> sources (with and without -fwrapv).
In GNUPLOT is is just over 4% of instruction count for 64-bit-only
integer calculations.
> I expect that it's highly
> dependent on the programming style. Sure there are types like pid_t
> where you have no choice, but in frequently occuring cases you can
> choose:
>
> for (i=0; i ... a[i] ...
> }
>
> Here you can choose whether to define i as int, unsigned, long,
> unsigned long, size_t, etc. If you care for portability to 16-bit
> machines, size_t is a good idea here, otherwise long and unsigned long
> also are efficient.
Counted for() loops are somewhat special in that it is quite easy to
determine that the loop index never exceeds the range-limit of the
container.
> If n is unsigned, you can also choose unsigned,
> but then this code will be slow on RV64 (and MIPS64 and SPARC V9 and
> PowerPC64 and Alpha).
Example please !?!
> If n is int, you can also choose int, and there is actually enough
> information here to make the code efficient (even with -fwrapv),
> because in this code int overflow really cannot happen,
Consider the case where n is int64_t or uint64_t !?!
Consider the C-preprocessor with::
# define int (short int) // !!
in scope.
> but in code
> that's not much different from this one (e.g., using != instead of <),
> -fwrapv will result in an inserted sign extension on AMD64, and not
> using -fwrapv may result in unintended behaviour thanks to the
> compiler assuming that int overflow does not happen.
>
> ILP64 would have spared us all these considerations.
Agreed. I32LP64 is am abomination, especially if one is bothering to
ty to keep the number of instructions down.
> - anton
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
