Re: Misc: Ongoing status...

On Sat, 1 Feb 2025 1:56:16 +0000, BGB wrote:

On 1/31/2025 1:30 PM, MitchAlsup1 wrote:

>

Generally, around 95% of the function-local branches can hit in a Disp9,
vs 98% for Disp12. So, better to drop to Disp9.

>
DISP16 reaches farther...
>

>
But...
>
Disp16 is not going to fit into such a 32-bit encoding...

It fit in mine !

But, say, 16+6+5+3 = 30.
Would have burned the entire 32-bit encoding space on BccI ...

Which is why  one does not do CMP-BC in one instruction !
The best you can do only covers 60%-odd if the cases.
-------------------

>
In XG3's encoding scheme, a similar construct would give:
   Bcc  Imm17s, Rs, Disp10s
Or:
   Bcc  Rt, Rs, Disp33s
But, where Bcc can still encode R0..R63.
>
It is possible that a 96-bit encoding could be defined:
   Bcc Imm26s, Rs, Disp33  //RV+Jx
   Bcc Imm30s, Rs, Disp33  //XG3

Having not found a function that takes ¼GB of space, I remain
comfortable with 28-bit branch displacement range. I also have
CALL instructions that reach 32-bit or 64-bit VAS.
------------------------------

Granted, I understand a prefix as being fetched and decoded at the same
time as the instruction it modifies.

Instruction needs to be plural.

Some people seem to imagine prefixes as executing independently and then
setting up some sort of internal registers which carry state over to the
following instruction.

Instruction needs to be plural.
--------------

Ironically though, the GCC and Clang people, and RV people, are
seemingly also adverse to scenarios that involve using implicit runtime
calls.
>
Granted, looking at it, I suspect things like implicit runtime calls (or
call-threaded code), would be a potential "Achilles's Heel" situation
for GCC performance, as its register allocation strategy seems to prefer
using scratch registers and then to spill them on function calls (rather
than callee-save registers which don't require a spill).

I know of a senior compiler writer at CRAY who would argue that
callee-save registers are an anathema--and had a litany of reasons
thereto (now long forgotten by me).

So, if one emits chunks of code that are basically end-to-end function
calls, they may perform more poorly than they might have otherwise.

These lower-level supervisory routines are the ones least capable of
using callee save registers in a way that saves cycles--often trading
register MOV instructions for LD instructions setting up arguments
and putting (ST) results where they can be used later.