This is slightly hilarious, I assume they will have used a crowbar
to put it into their encoding (probably a two-byte prefix).

"Intel® APX doubles the number of general-purpose registers (GPRs)
from 16 to 32. This allows the compiler to keep more values in
registers; as a result, APX-compiled code contains 10% fewer loads
and more than 20% fewer stores than the same code compiled for an
Intel® 64 baseline.2 Register accesses are not only faster, but
they also consume significantly less dynamic power than complex
load and store operations."

https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html

Thomas Koenig <tkoenig@netcologne.de> writes:
>This is slightly hilarious, I assume they will have used a crowbar
>to put it into their encoding (probably a two-byte prefix).

The article seems to imply a single prefix byte (REX2), which may
be combined with existing prefix bytes to alter the interpretation
of the register field in the instructions. They also claim similar
code density to existing code.

"The performance features introduced so far will have limited
impact in workloads that suffer from a large number of conditional
branch mispredictions. As out-of-order CPUs continue to become
deeper and wider, the cost of mispredictions increasingly dominates
performance of such workloads. Branch predictor improvements can
mitigate this to a limited extent only as data-dependent branches
are fundamentally hard to predict."

So, they're adding additional conditional instructions along
the same lines as the existing CSET/CMOV.

The document finishes with

"Intel� APX demonstrates the advantage of the variable-length
instruction encodings of x86 - new features enhancing
the entire instruction set can be defined with only incremental
changes to the instruction-decode hardware."

On Tuesday, July 25, 2023 at 2:29:08 AM UTC-6, Thomas Koenig wrote:
> This is slightly hilarious, I assume they will have used a crowbar
> to put it into their encoding (probably a two-byte prefix).
>
> "Intel® APX doubles the number of general-purpose registers (GPRs)
> from 16 to 32. This allows the compiler to keep more values in
> registers; as a result, APX-compiled code contains 10% fewer loads
> and more than 20% fewer stores than the same code compiled for an
> Intel® 64 baseline.2 Register accesses are not only faster, but
> they also consume significantly less dynamic power than complex
> load and store operations."
>
> https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html

Oh, wow, Intel will be just as good as RISC!

Of course, there is room for further improvement. They already have, on the shelf, technology to
increase to 128 registers. If they find a way to improve performance still further when switching
to Itanium mode, then they will really dominate the field!

John Savard

On Tuesday, July 25, 2023 at 9:37:01 AM UTC-5, Scott Lurndal wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
> >This is slightly hilarious, I assume they will have used a crowbar
> >to put it into their encoding (probably a two-byte prefix).
> The article seems to imply a single prefix byte (REX2), which may
> be combined with existing prefix bytes to alter the interpretation
> of the register field in the instructions. They also claim similar
> code density to existing code.
<
Right, they save instructions but eat bytes in the instruction stream.
Net density is a wash.
<
When I was at AMD we looked at using the (then) REX prefix twice
to gain access to 32-registers.
<
But, here, Intel added another prefix to go from Ra = Ra op Rb into
Ra = Rb op Rc. {in case you missed it}
>
> "The performance features introduced so far will have limited
> impact in workloads that suffer from a large number of conditional
> branch mispredictions. As out-of-order CPUs continue to become
> deeper and wider, the cost of mispredictions increasingly dominates
> performance of such workloads. Branch predictor improvements can
> mitigate this to a limited extent only as data-dependent branches
> are fundamentally hard to predict."
>
> So, they're adding additional conditional instructions along
> the same lines as the existing CSET/CMOV.
>
> The document finishes with
>
> "Intel® APX demonstrates the advantage of the variable-length
> instruction encodings of x86 - new features enhancing
> the entire instruction set can be defined with only incremental
> changes to the instruction-decode hardware."
<
I have been advocating since about 2015 that RISC should go
with variable length instructions.

Thomas Koenig <tkoenig@netcologne.de> writes:
>This is slightly hilarious, I assume they will have used a crowbar
>to put it into their encoding (probably a two-byte prefix).

Somewhat. They have a 2-byte REX2 prefix for extending the existing
destructive instructions, which looks like what one would expect; the
bit3 bits are in the same place as in the REX prefix, and the bit4
bits are adjacent to them, which makes assembling and disassembling
slightly more complicated than if they had had two-bit fields.

They also have a 4-byte NDD prefix (from the EVEX encoding space) that
encodes the additional bits of the existing registers and a whole new
destination register to turn existing destructive instructions into
non-destructive instructions. There the encodings of many, but not
all bits are inverted, and the bits are distributed in an interesting
way (probably due to how EVEX has been previously defined, and how VEX
has been defined).

So an instruction with a REX2 prefix is at least three bytes long (and
five bytes is probably more typical). And instruction with a new
destination is at least two bytes longer. That's often still shorter
than prefixing the instruction with a register-register move (the
current idiom if you don't want a non-destructive use).

>https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html

So in 20 years we may be seeing this to become the new architecture,
or maybe not. Some time ago people proposed the x32 ABI, a 32-bit ABI
using the AMD64 instruction set. This was sold on better prerformance
then IA-32 (because of more registers) and AMD64 (because of fewer
cache misses). It did not take off.

So when in 20 years, APX is universally available, will people switch
to a new ABI for it? Doubtful.

Intel seems to doubt it themselves, so they recommend that the new
registers be caller-saved for compatibility with existing ABIs. If
that recommendation is followed, it also means that the additional
registers will be not as useful as they might otherwise be.

E.g., GCC does not use caller-saved registers for virtual-machine
registers in Gforth, even if they are used hundreds of times in
engine(), because these registers live across dozens of calls. As a
result GForth could not use more registers for virtual-machine
registers on Alpha than on AMD64 and barely more than on IA-32. So if
the recommendation is followed, the additional registers will be
hardly used in Gforth's engine().

OTOH, given the x32 experience, it's unlikely that we will see an
alternative ABI.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Tuesday, July 25, 2023 at 9:00:07 AM UTC-6, MitchAlsup wrote:

> Right, they save instructions but eat bytes in the instruction stream.
> Net density is a wash.

I looked into this new instruction set a bit more.

Intel recognized this issue. So for your prefix byte, instead of *just*
getting to use 32 registers instead of 16, you *also* get to refer to
three registers instead of just two in the instruction!

That may help a bit, but I suspect it won't be enough. However, it
could be that the instructions with 16 registers are stuff that came in
with the 386, and so those instructions had a prefix byte too. In which
case, the new instructions could just have a different prefix byte, and
not be a byte longer.

John Savard

On Tuesday, July 25, 2023 at 10:44:12 AM UTC-6, Anton Ertl wrote:

> So when in 20 years, APX is universally available, will people switch
> to a new ABI for it? Doubtful.

You're talking about this as if people have a _choice_.

Instead, it will probably go like this:

Intel puts this new feature in all their products next year.

Ten years from that, Microsoft starts using it to make Windows
run faster, and the hardware requirements for the latest upgrade
require a processor not more than ten years old from Intel.

Therefore, Intel will have immense leverage over AMD to get
them to license this new feature, so that they can stay in business
ten years from now.

John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:
>Intel recognized this issue. So for your prefix byte, instead of *just*
>getting to use 32 registers instead of 16, you *also* get to refer to
>three registers instead of just two in the instruction!

No. IA-32 already has three registers in the instruction, e.g.,

add ebx, 123[ecx+8*edx]

So AMD64 extended this with the REX prefix to support

add r8, 123[r9+8*r10]

and provides one extra bit for every register (as well as one bit for
indicating 64-bit operation).

With REX2 (2 bytes) you get two extra bits for each of these
registers, for a total of 5 bits.

Alternatively, you can use the NDD prefix from the EVEX encoding space
(4 bytes) to encode these 6 extra bits, plus five bits for a new
destination register.

The REX2 prefix contains one bit that selects between legacy map 0 and
1 (legacy maps 2 and 3 cannot use the REX2 prefix). Map 1 are the
instructions that start with a 0F escape, but not 0F38 nor 0F3A (maps
2 and 3). So with the REX2 prefix you replace the 0F prefix of the
map1 instructions. That's the advantage of having the REX2 prefix
over having two REX prefixes as AMD considered according to Mitch
Alsup. The disadvantage is that it occupies the D5 byte of AMD64
(which is AAD in IA-32, but apparently has been reserved in AMD64).

The NDD prefix contains three bits for opcode maps and replaces the OF
prefix byte (so it costs only three extra bytes in this case) as well
as the 0F38 and 0F3A prefixes (costing only two extra bytes in this
case). There is also space for four additional opcode maps when using
the NDD prefix (not used up to now).

I am not versed enough in the encoding of IA-32/AMD64 to know how
frequent the different encoding maps are used.

>However, it
>could be that the instructions with 16 registers are stuff that came in
>with the 386, and so those instructions had a prefix byte too.

No, the extension from 8+8 (GPR+SSE) registers (IA-32) to 16+16
registers came with AMD64, and yes, AMD64 used the REX prefix for
that.

>In which
>case, the new instructions could just have a different prefix byte, and
>not be a byte longer.

Instructions from map 0 become one byte longer with the REX2 prefix
than with the REX prefix. Instructions from map 1 (0F prefix) stay
the same length with the REX2 prefix as with the REX prefix.
Instructions from map 2 and map 3 become one byte longer with the NDD
prefix than with the REX prefix.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Quadibloc <jsavard@ecn.ab.ca> writes:
>On Tuesday, July 25, 2023 at 10:44:12=E2=80=AFAM UTC-6, Anton Ertl wrote:
>
>> So when in 20 years, APX is universally available, will people switch=20
>> to a new ABI for it? Doubtful.=20
>
>You're talking about this as if people have a _choice_.
>
>Instead, it will probably go like this:
>
>Intel puts this new feature in all their products next year.

I wish. AVX and AVX512 tell a different story. Intel still sells
CPUs (e.g., the Pentium Gold G6400) that willfully do not support AVX
(even though the hardware is capable of it). Maybe Intel marketing
will decide that APX is a premium feature and will disable it in the
less-expensive CPUs for a decade or two.

Meanwhile, AMD will put it into Zen6 or so, and support it across all
their CPUs from that point onwards, like they have done for AVX since
Bulldozer (2011) and Jaguar (2013), for AVX2 since Excavator (2015),
and for AVX-512 since Zen4 (2022).

>Ten years from that, Microsoft starts using it to make Windows
>run faster, and the hardware requirements for the latest upgrade
>require a processor not more than ten years old from Intel.
>
>Therefore, Intel will have immense leverage over AMD to get
>them to license this new feature, so that they can stay in business
>ten years from now.

Unlikely. Microsoft wants hardware at commodity prices in order to
make its software the premium feature, so they won't support APX
unless AMD also has it, because they don't want to give Intel more
monopoly power than it already has. So if Intel does not license APX
to AMD, Microsoft won't use APX, and most other software vendors will
not use it, either (except those paid by Intel; that would be the
premium-feature scenario, but then Intel probably won't support it on
their cheaper CPUs, either).

Apart from that Intel and AMD have patent exchange agreements, and AMD
probably has enough patents that are relevant for Intel that they
don't want to stop extending these agreements, so Intel probably
licenses APX to AMD as part of these agreements.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Quadibloc wrote:
> On Tuesday, July 25, 2023 at 10:44:12 AM UTC-6, Anton Ertl wrote:
>
>> So when in 20 years, APX is universally available, will people switch
>> to a new ABI for it? Doubtful.
>
> You're talking about this as if people have a _choice_.
>
> Instead, it will probably go like this:
>
> Intel puts this new feature in all their products next year.
>
> Ten years from that, Microsoft starts using it to make Windows
> run faster, and the hardware requirements for the latest upgrade
> require a processor not more than ten years old from Intel.

Possibly true.
>
> Therefore, Intel will have immense leverage over AMD to get
> them to license this new feature, so that they can stay in business
> ten years from now.

Rather the opposite: Intel have to persuade AMD to stay compatible,
otherwise there is zero chance of Microsoft ever making it a requirement.

BTW, when you guys are discussing 16 vs 32 general registers and 3 vs
2-reg instructions forms, you just have to look at the AVX2++
instruction sets! The SIMD part of the cpus got both of these features
several years ago, allowing the same for integer regs is probably a very
small update to the instructions decoders. (Unless the encodings are
incompatible, which I would dismiss as very unlikely.)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Quadibloc wrote:
>> On Tuesday, July 25, 2023 at 10:44:12 AM UTC-6, Anton Ertl wrote:
>>
>>> So when in 20 years, APX is universally available, will people switch
>>> to a new ABI for it? Doubtful.
>>
>> You're talking about this as if people have a _choice_.
>>
>> Instead, it will probably go like this:
>>
>> Intel puts this new feature in all their products next year.
>>
>> Ten years from that, Microsoft starts using it to make Windows
>> run faster, and the hardware requirements for the latest upgrade
>> require a processor not more than ten years old from Intel.
>
> Possibly true.
>>
>> Therefore, Intel will have immense leverage over AMD to get
>> them to license this new feature, so that they can stay in business
>> ten years from now.
>
> Rather the opposite: Intel have to persuade AMD to stay compatible,
> otherwise there is zero chance of Microsoft ever making it a requirement.

One problem I see is that all the new registers are caller-saved,
for compatibility with existing ABIs. This is needed due to stack
unwinding and setjmp/longjmp, but restricts their benefit due to
having to spill them across function calls. It might be possible
to set __attribute__((nothrow)) on functions where this cannot
happen, and change some caller-saved to callee-saved registers
in that case, but that could be an interesting discussion.

Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>> Quadibloc wrote:
>>> On Tuesday, July 25, 2023 at 10:44:12 AM UTC-6, Anton Ertl wrote:
>>>
>>>> So when in 20 years, APX is universally available, will people switch
>>>> to a new ABI for it? Doubtful.
>>>
>>> You're talking about this as if people have a _choice_.
>>>
>>> Instead, it will probably go like this:
>>>
>>> Intel puts this new feature in all their products next year.
>>>
>>> Ten years from that, Microsoft starts using it to make Windows
>>> run faster, and the hardware requirements for the latest upgrade
>>> require a processor not more than ten years old from Intel.
>>
>> Possibly true.
>>>
>>> Therefore, Intel will have immense leverage over AMD to get
>>> them to license this new feature, so that they can stay in business
>>> ten years from now.
>>
>> Rather the opposite: Intel have to persuade AMD to stay compatible,
>> otherwise there is zero chance of Microsoft ever making it a requirement.
>
> One problem I see is that all the new registers are caller-saved,
> for compatibility with existing ABIs. This is needed due to stack
> unwinding and setjmp/longjmp, but restricts their benefit due to
> having to spill them across function calls. It might be possible
> to set __attribute__((nothrow)) on functions where this cannot
> happen, and change some caller-saved to callee-saved registers
> in that case, but that could be an interesting discussion.
>

I'm not worried at all about this point: The only places where I really
want lots of registers are in big/complicated leaf functions!

If a function both needs lots of registers _and_ have to call any
non-inlined functions, then it really isn't that time critical.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:

>> One problem I see is that all the new registers are caller-saved,
>> for compatibility with existing ABIs. This is needed due to stack
>> unwinding and setjmp/longjmp, but restricts their benefit due to
>> having to spill them across function calls. It might be possible
>> to set __attribute__((nothrow)) on functions where this cannot
>> happen, and change some caller-saved to callee-saved registers
>> in that case, but that could be an interesting discussion.
>>
>
> I'm not worried at all about this point: The only places where I really
> want lots of registers are in big/complicated leaf functions!
>
> If a function both needs lots of registers _and_ have to call any
> non-inlined functions, then it really isn't that time critical.

Fortran can use lots of registers for its array descriptors,
and also can use lots of library calls for mathematical functions
(because most CPUs don't have Mitch's single instructions for them).
Fortran library functions are typically __attribute__((nothrow)),
so in that field being able to use more registers across calls
would be a good thing, generally.

On Wednesday, July 26, 2023 at 6:38:25 AM UTC-5, Terje Mathisen wrote:
> Thomas Koenig wrote:
> > Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >> Quadibloc wrote:
> >>> On Tuesday, July 25, 2023 at 10:44:12 AM UTC-6, Anton Ertl wrote:
> >>>
> >>>> So when in 20 years, APX is universally available, will people switch
> >>>> to a new ABI for it? Doubtful.
> >>>
> >>> You're talking about this as if people have a _choice_.
> >>>
> >>> Instead, it will probably go like this:
> >>>
> >>> Intel puts this new feature in all their products next year.
> >>>
> >>> Ten years from that, Microsoft starts using it to make Windows
> >>> run faster, and the hardware requirements for the latest upgrade
> >>> require a processor not more than ten years old from Intel.
> >>
> >> Possibly true.
> >>>
> >>> Therefore, Intel will have immense leverage over AMD to get
> >>> them to license this new feature, so that they can stay in business
> >>> ten years from now.
> >>
> >> Rather the opposite: Intel have to persuade AMD to stay compatible,
> >> otherwise there is zero chance of Microsoft ever making it a requirement.
> >
> > One problem I see is that all the new registers are caller-saved,
> > for compatibility with existing ABIs. This is needed due to stack
> > unwinding and setjmp/longjmp, but restricts their benefit due to
> > having to spill them across function calls. It might be possible
> > to set __attribute__((nothrow)) on functions where this cannot
> > happen, and change some caller-saved to callee-saved registers
> > in that case, but that could be an interesting discussion.
> >
> I'm not worried at all about this point: The only places where I really
> want lots of registers are in big/complicated leaf functions!
<
This is also my impression, non-leaf functions (but see caveat)
generally guide leaf functions through the calculations, while
leaf functions tend to grind on the data more than walk the
data structures.
<
Caveat 1: Elementary functions are used a lot in what would have
been a leaf function except for these intrinsics. {SIN(), COS(),
EXP(), Ln(),POW(,),...} Here the compiler could KNOW that those
registers are not damaged by that callee and pretend they are
callee-save. Making these OpCodes instead of Calls simplifies
this.
>
Caveat 2: Compilers could be given an __attribute__(NoDamage)
and not use the extended registers, thus alleviating the need to
save and/or restore.
<
> If a function both needs lots of registers _and_ have to call any
> non-inlined functions, then it really isn't that time critical.
<
The farther from the leaves you are, the more the code looks like
book-keeping and looping.
<
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>If a function both needs lots of registers _and_ have to call any
>non-inlined functions, then it really isn't that time critical.

Every interpreter calls non-inlined functions, and they often need a
lot of registers, or can make good use of them.

Now you may consider that to be not time-critical, but if you are
Intel and want to sell an interpreter user an Intel system, and it is
slow compared to the ARM64 or RISC-V systems, you will still lose the
sale.

Conversely, given that you spend so much time in your leaf function,
saving a few registers at the start and restoring them at the end
won't slow you down.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>> Thomas Koenig wrote:
>
>>> One problem I see is that all the new registers are caller-saved,
>>> for compatibility with existing ABIs. This is needed due to stack
>>> unwinding and setjmp/longjmp, but restricts their benefit due to
>>> having to spill them across function calls. It might be possible
>>> to set __attribute__((nothrow)) on functions where this cannot
>>> happen, and change some caller-saved to callee-saved registers
>>> in that case, but that could be an interesting discussion.
>>>
>>
>> I'm not worried at all about this point: The only places where I really
>> want lots of registers are in big/complicated leaf functions!
>>
>> If a function both needs lots of registers _and_ have to call any
>> non-inlined functions, then it really isn't that time critical.
>
> Fortran can use lots of registers for its array descriptors,
> and also can use lots of library calls for mathematical functions
> (because most CPUs don't have Mitch's single instructions for them).
> Fortran library functions are typically __attribute__((nothrow)),
> so in that field being able to use more registers across calls
> would be a good thing, generally.
>
If said Fortran code is really performance critical, like in an FFT,
then all the sin/cos function calls will be done up front and cached.

It is only when you have unique arguments that it can be faster to do
them inline, right?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Anton Ertl wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> If a function both needs lots of registers _and_ have to call any
>> non-inlined functions, then it really isn't that time critical.
>
> Every interpreter calls non-inlined functions, and they often need a
> lot of registers, or can make good use of them.
>
> Now you may consider that to be not time-critical, but if you are
> Intel and want to sell an interpreter user an Intel system, and it is
> slow compared to the ARM64 or RISC-V systems, you will still lose the
> sale.

I'm willing to be shown otherwise, but util then I'd consider any code
that runs under an actual interpreter to be non-performance-critical.

>
> Conversely, given that you spend so much time in your leaf function,
> saving a few registers at the start and restoring them at the end
> won't slow you down.

This is obviously true, and in the case of having non-saved registers
that you'd like to use across function calls, I would probably consider
writing wrappers for those function calls: The wrapper would do the
save, call the actual function, then restore and return.

This would be a win when you need to call the same function from many
locations since it would reduce the code space while still allowing all
regs to be used.

If, otoh, you aren't worried about the code space expansion, then mark
those wrapper functions as "inline_always" and do the save/restore
around every call site.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Anton Ertl wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>> If a function both needs lots of registers _and_ have to call any
>>> non-inlined functions, then it really isn't that time critical.
>>
>> Every interpreter calls non-inlined functions, and they often need a
>> lot of registers, or can make good use of them.
>>
>> Now you may consider that to be not time-critical, but if you are
>> Intel and want to sell an interpreter user an Intel system, and it is
>> slow compared to the ARM64 or RISC-V systems, you will still lose the
>> sale.
>
>I'm willing to be shown otherwise, but util then I'd consider any code
>that runs under an actual interpreter to be non-performance-critical.

I would likely argue that an interpreter is inherently performance-critical
in order to make the interpreted code useful.

Take a machine simulator as an example of performance-critical
interpreter (interpreting machine instructions rather than bytecode
or some intermediate tree representation). Booting linux on the
simulator, for example, is definitely performance critical from the
standpoint of the user waiting for a login prompt[*].

[*] Yet another thing systemd makes worse.

On Wednesday, July 26, 2023 at 3:45:58 PM UTC-5, Terje Mathisen wrote:
> Thomas Koenig wrote:
> > Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >> Thomas Koenig wrote:
> >
> >>> One problem I see is that all the new registers are caller-saved,
> >>> for compatibility with existing ABIs. This is needed due to stack
> >>> unwinding and setjmp/longjmp, but restricts their benefit due to
> >>> having to spill them across function calls. It might be possible
> >>> to set __attribute__((nothrow)) on functions where this cannot
> >>> happen, and change some caller-saved to callee-saved registers
> >>> in that case, but that could be an interesting discussion.
> >>>
> >>
> >> I'm not worried at all about this point: The only places where I really
> >> want lots of registers are in big/complicated leaf functions!
> >>
> >> If a function both needs lots of registers _and_ have to call any
> >> non-inlined functions, then it really isn't that time critical.
> >
> > Fortran can use lots of registers for its array descriptors,
> > and also can use lots of library calls for mathematical functions
> > (because most CPUs don't have Mitch's single instructions for them).
> > Fortran library functions are typically __attribute__((nothrow)),
> > so in that field being able to use more registers across calls
> > would be a good thing, generally.
> >
> If said Fortran code is really performance critical, like in an FFT,
> then all the sin/cos function calls will be done up front and cached.
<
Not just cached, but computed prior to loading the application.
>
> It is only when you have unique arguments that it can be faster to do
> them inline, right?
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Wednesday, July 26, 2023 at 4:06:48 PM UTC-5, Scott Lurndal wrote:
> Terje Mathisen <terje.m...@tmsw.no> writes:
> >Anton Ertl wrote:
> >> Terje Mathisen <terje.m...@tmsw.no> writes:
> >>> If a function both needs lots of registers _and_ have to call any
> >>> non-inlined functions, then it really isn't that time critical.
> >>
> >> Every interpreter calls non-inlined functions, and they often need a
> >> lot of registers, or can make good use of them.
> >>
> >> Now you may consider that to be not time-critical, but if you are
> >> Intel and want to sell an interpreter user an Intel system, and it is
> >> slow compared to the ARM64 or RISC-V systems, you will still lose the
> >> sale.
> >
> >I'm willing to be shown otherwise, but util then I'd consider any code
> >that runs under an actual interpreter to be non-performance-critical.
<
> I would likely argue that an interpreter is inherently performance-critical
> in order to make the interpreted code useful.
>
> Take a machine simulator as an example of performance-critical
> interpreter (interpreting machine instructions rather than bytecode
> or some intermediate tree representation). Booting linux on the
> simulator, for example, is definitely performance critical from the
> standpoint of the user waiting for a login prompt[*].
<
As someone who has actually done this (1999), what we did was to
take portions (~= basic blocks) of code and compile them into traces
complete with CPU/cache/TLB statistics updates, and then run 95%±
of the interpreter as native code.
<
Is this still simulation ? obviously
but it is more like JIT than interpretation.
and eliminated most of the overhead of interpretation.
<
Obviously this is easier of target and computer are of the same architecture
but one could do Mc 88100 ISA on a SPARC V8 without much hassle {or
x86-64 on a SPARC V9,...}.
>
> [*] Yet another thing systemd makes worse.

On Wednesday, July 26, 2023 at 4:30:20 PM UTC-5, MitchAlsup wrote:
> On Wednesday, July 26, 2023 at 4:06:48 PM UTC-5, Scott Lurndal wrote:
> > Terje Mathisen <terje.m...@tmsw.no> writes:
> > >Anton Ertl wrote:
> > >> Terje Mathisen <terje.m...@tmsw.no> writes:
> > >>> If a function both needs lots of registers _and_ have to call any
> > >>> non-inlined functions, then it really isn't that time critical.
> > >>
> > >> Every interpreter calls non-inlined functions, and they often need a
> > >> lot of registers, or can make good use of them.
> > >>
> > >> Now you may consider that to be not time-critical, but if you are
> > >> Intel and want to sell an interpreter user an Intel system, and it is
> > >> slow compared to the ARM64 or RISC-V systems, you will still lose the
> > >> sale.
> > >
> > >I'm willing to be shown otherwise, but util then I'd consider any code
> > >that runs under an actual interpreter to be non-performance-critical.
> <
> > I would likely argue that an interpreter is inherently performance-critical
> > in order to make the interpreted code useful.
> >
> > Take a machine simulator as an example of performance-critical
> > interpreter (interpreting machine instructions rather than bytecode
> > or some intermediate tree representation). Booting linux on the
> > simulator, for example, is definitely performance critical from the
> > standpoint of the user waiting for a login prompt[*].
> <
> As someone who has actually done this (1999), what we did was to
> take portions (~= basic blocks) of code and compile them into traces
> complete with CPU/cache/TLB statistics updates, and then run 95%±
> of the interpreter as native code.
> <
> Is this still simulation ? obviously
> but it is more like JIT than interpretation.
> and eliminated most of the overhead of interpretation.
> <
> Obviously this is easier of target and computer are of the same architecture
> but one could do Mc 88100 ISA on a SPARC V8 without much hassle {or
> x86-64 on a SPARC V9,...}.
> >
> > [*] Yet another thing systemd makes worse.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Wednesday, July 26, 2023 at 4:06:48=E2=80=AFPM UTC-5, Scott Lurndal wrot=
>e:
>> Terje Mathisen <terje.m...@tmsw.no> writes:=20
>> >Anton Ertl wrote:=20
>> >> Terje Mathisen <terje.m...@tmsw.no> writes:=20
>> >>> If a function both needs lots of registers _and_ have to call any=20
>> >>> non-inlined functions, then it really isn't that time critical.=20
>> >>=20
>> >> Every interpreter calls non-inlined functions, and they often need a=
>=20
>> >> lot of registers, or can make good use of them.=20
>> >>=20
>> >> Now you may consider that to be not time-critical, but if you are=20
>> >> Intel and want to sell an interpreter user an Intel system, and it is=
>=20
>> >> slow compared to the ARM64 or RISC-V systems, you will still lose the=
>=20
>> >> sale.=20
>> >=20
>> >I'm willing to be shown otherwise, but util then I'd consider any code=
>=20
>> >that runs under an actual interpreter to be non-performance-critical.
><
>> I would likely argue that an interpreter is inherently performance-critic=
>al=20
>> in order to make the interpreted code useful.=20
>>=20
>> Take a machine simulator as an example of performance-critical=20
>> interpreter (interpreting machine instructions rather than bytecode=20
>> or some intermediate tree representation). Booting linux on the=20
>> simulator, for example, is definitely performance critical from the=20
>> standpoint of the user waiting for a login prompt[*].=20
><
>As someone who has actually done this (1999)

We had a simulator for the Burroughs mainframe in the 70's
that we used to test instruction set changes (it was in Burroughs
Algol and ran on a B7900).

I currently work on an SoC simulator which simulates (functionally)
the entire SoC: ARM64 cores (dozens), peripheral controllers (e.g. SATA,
SPI, EMMC, I2C/I3C, networking), microcontrollers, accelerator blocks, PCI, etc.

Performance is key.

, what we did was to
>take portions (~=3D basic blocks) of code and compile them into traces
>complete with CPU/cache/TLB statistics updates, and then run 95%=C2=B1=20
>of the interpreter as native code.=20
><
>Is this still simulation ? obviously
>but it is more like JIT than interpretation.

Most modern simulators (e.g. qemu) use jit-like mechanisms,
as did AMDs SimNow! back in the 2000s.

Scott Lurndal wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> On Wednesday, July 26, 2023 at 4:06:48=E2=80=AFPM UTC-5, Scott Lurndal wrot=
>> e:
>>> Terje Mathisen <terje.m...@tmsw.no> writes:=20
>>>> Anton Ertl wrote:=20
>>>>> Terje Mathisen <terje.m...@tmsw.no> writes:=20
>>>>>> If a function both needs lots of registers _and_ have to call any=20
>>>>>> non-inlined functions, then it really isn't that time critical.=20
>>>>> =20
>>>>> Every interpreter calls non-inlined functions, and they often need a=
>> =20
>>>>> lot of registers, or can make good use of them.=20
>>>>> =20
>>>>> Now you may consider that to be not time-critical, but if you are=20
>>>>> Intel and want to sell an interpreter user an Intel system, and it is=
>> =20
>>>>> slow compared to the ARM64 or RISC-V systems, you will still lose the=
>> =20
>>>>> sale.=20
>>>> =20
>>>> I'm willing to be shown otherwise, but util then I'd consider any code=
>> =20
>>>> that runs under an actual interpreter to be non-performance-critical.
>> <
>>> I would likely argue that an interpreter is inherently performance-critic=
>> al=20
>>> in order to make the interpreted code useful.=20
>>> =20
>>> Take a machine simulator as an example of performance-critical=20
>>> interpreter (interpreting machine instructions rather than bytecode=20
>>> or some intermediate tree representation). Booting linux on the=20
>>> simulator, for example, is definitely performance critical from the=20
>>> standpoint of the user waiting for a login prompt[*].=20
>> <
>> As someone who has actually done this (1999)
>
> We had a simulator for the Burroughs mainframe in the 70's
> that we used to test instruction set changes (it was in Burroughs
> Algol and ran on a B7900).
>
> I currently work on an SoC simulator which simulates (functionally)
> the entire SoC: ARM64 cores (dozens), peripheral controllers (e.g. SATA,
> SPI, EMMC, I2C/I3C, networking), microcontrollers, accelerator blocks, PCI, etc.
>
> Performance is key.
>
>
> , what we did was to
>> take portions (~=3D basic blocks) of code and compile them into traces
>> complete with CPU/cache/TLB statistics updates, and then run 95%=C2=B1=20
>> of the interpreter as native code.=20
>> <
>> Is this still simulation ? obviously
>> but it is more like JIT than interpretation.
>
> Most modern simulators (e.g. qemu) use jit-like mechanisms,
> as did AMDs SimNow! back in the 2000s.

Exactly my point: Those JIT-style traces can obviously use all the regs,
as can any other leaf code.

It is only when you want to use the new regs for the core interpreter
code that you run into trouble.

All this said, I strongly suspect that the variable sys save/restore
opcodes wil be capable of handling everything, as long as the OS
initializes it properly. I.e. promise that the save areas will be large
enough.

It would still probably be better performance wise to make those
save/restore functions partially lazy, so that code which never touches
the extended regs don't need the save/restore. OTOH, we have seen this
tried multiple times over the years, and we typically end up with the
much cleaner "grab everything" approach because it is easier to make
bug-free.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Wednesday, July 26, 2023 at 8:03:00 AM UTC+2, Anton Ertl wrote:
> So with the REX2 prefix you replace the 0F prefix of the
> map1 instructions. That's the advantage of having the REX2 prefix
> over having two REX prefixes as AMD considered according to Mitch
> Alsup. The disadvantage is that it occupies the D5 byte of AMD64

That is exactly as what the 2x REX scheme could have done. REX2 has a payload of 8 bits. 2x REX has a payload of 4+4=8 bits. You need W + 2x3 extra bits for the register numbers. Then you have one bit left over, which REX2 uses for the map selection. 2x REX could have done exactly the same -- what would you need two W bits for?

-Peter

PS: It's nice to get tidbits like that, even with the inevitable decade+ delay. I wonder what AMD had considered using the extra W bit for...

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>>> Thomas Koenig wrote:
>>
>>>> One problem I see is that all the new registers are caller-saved,
>>>> for compatibility with existing ABIs. This is needed due to stack
>>>> unwinding and setjmp/longjmp, but restricts their benefit due to
>>>> having to spill them across function calls. It might be possible
>>>> to set __attribute__((nothrow)) on functions where this cannot
>>>> happen, and change some caller-saved to callee-saved registers
>>>> in that case, but that could be an interesting discussion.
>>>>
>>>
>>> I'm not worried at all about this point: The only places where I really
>>> want lots of registers are in big/complicated leaf functions!
>>>
>>> If a function both needs lots of registers _and_ have to call any
>>> non-inlined functions, then it really isn't that time critical.
>>
>> Fortran can use lots of registers for its array descriptors,
>> and also can use lots of library calls for mathematical functions
>> (because most CPUs don't have Mitch's single instructions for them).
>> Fortran library functions are typically __attribute__((nothrow)),
>> so in that field being able to use more registers across calls
>> would be a good thing, generally.
>>
> If said Fortran code is really performance critical, like in an FFT,
> then all the sin/cos function calls will be done up front and cached.

If you're doing lots of chemical reaction calculation, it is
not possible to pre-compute the Arrhenius equation coefficients
(and their Jacobians).

There's more to life than FFT :-)