Kent Dickey <kegs@provalid.com> schrieb:
> In article <ubpr3d$2iugr$1@newsreader4.netcologne.de>,
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>Kent Dickey <kegs@provalid.com> schrieb:
>>
>>> It's just that most of the code is full of register reloads around function
>>> calls, most of which would go away with just a few more preserved registers.
>>
>>It would be good to have an option for the linker to do away with
>>load/stores even in the absence of full LTO.
>>
>>The discussion here led me to propse this on the gcc mailing list, with
>>the feedback that it could be useful, but would be a handful of work.
>>
>>A compiler could annotate spill/restore instructions, something like
>>this:
>>
>>
>> .spill r17
>> std r17,120(sp)
>>[...]
>> call foo
>>
>>[...]
>>
>> .restore r17
>> ldd r17,120(sp)
>>
>>and foo would then have someting like
>>
>>.type foo,@function
>>.useregs foo,r12,r13,r14,r15
>>foo:
>>
>>If the linker finds what the assembler puts into the object file
>>for these assembly statements, it could then infer that r17 is not
>>used in foo, and remove the corresponding std and ldd statements
>>(with all the potential issues that this has).
>
> I think it's not a great idea to push this to the compiler/linker when
> it's a trivial thing to fix in documentation.

How would you fix the documentation change which registers are used?

> But the real problem is a solution like this is more complex: the linker
> needs to know all the functions foo() could call, and track the register
> use through all of them as well.

Correct. It would face the same thing of problem as LTO, but on a
much lower level.

On 8/19/2023 10:02 AM, EricP wrote:

snipped discussion on caller vs callee saved registers

> The compiler could export a summary file describing the registers
> used by each routine. This summary would be imported by the compiler
> of callers to those routines so it could allocate registers not used
> by the callee to the caller. Also the summary could be produced by
> scanning a .OBJ or .DLL.
>
> Such a mechanism does not require modifications to source and
> is also language independent.
>
> It does create a dependency between the caller and a particular
> (timestamped) instance of a callee in a .OBJ or .DLL file.

Not necessarily. If the compiler of the calling program also exported
the used register lists of the routines it called when compiling the
code, then the linker could check that the routines actually linked to
did not use more registers than the caller assumed. This would work even
if the called program was compiled at a different time than the one used
at the main routine's compile time. (I hope this is clear. The
language can get confusing.)

Of course, the question arises, what if a called routine does use more
registers than the calling program was told at its compile time. There
are several possibilities, abort the link, create trampoline routines to
save and restore the newly used registers, perhaps others. The choice
should certainly be made by the programmer.

In fact, if at link time, the called program used fewer registers than
the one assumed at compile time, that should be brought to the
programmers attention as information, so perhaps the calling program
could be recompiled and, by using more registers, be more efficient.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Mon, 21 Aug 2023 17:09:37 -0000 (UTC), kegs@provalid.com (Kent
Dickey) wrote:

>I don't know how to browse google groups without logging in ...

Using a search engine (even Google itself), search for the group's
name. That will get you to the first page.

From there you can search "Conversations" within the group if you know
the names of threads, keywords, authors, etc.

Note that you CAN'T do a global search [of "all groups and messages"]
or try to go to the Groups home page as either of these will require
you to login. If you want to switch to another group, you have to go
back through the search engine.

Hope this helps.

Kent Dickey <kegs@provalid.com> schrieb:
> In article <c61a30d4-9e83-41ce-91a7-72c296f22b20n@googlegroups.com>,
> Michael S <already5chosen@yahoo.com> wrote:
>>On Monday, August 21, 2023 at 4:26:55 AM UTC+3, Kent Dickey wrote:
>>> What I am VERY interested in is for someone to make the case for so many
>>> scratch registers. Show me some code which needs 19 scratch registers,
>>> and would run noticeably slower with 14 scratch registers.
>>>
>>
>>There is other side of the same argument: can you show me (or more
>>relevantly to designers of aarch64 ABI) some code which needs 16
>> callee-saved registers, and would run noticeably slower with 11
>> callee-saved registers ?
>>
>>> I think this is just an architecture issue no one gives much thought to.
>>
>>I tend to think that they tried to give a deep thought, but in the process
>>quickly came to conclusion that it matters very little.
>
> I've already provided an example in September, 2020 in the post:
><TOGdnf-OgvSdue_CnZ2dnUU7-R3NnZ2d@giganews.com> (you can read it at
> http://al.howardknight.net/?L=EN>). I don't know how to browse google groups
> without logging in, if someone posts a link, that would be helpful.
>
> Here is the code again. I'm trying to keep it as short as possible to show
> the problem, so I don't plan to respond to nitpicks about the particulars
> of this code.

[...]

The issue of the frame pointer register not being used shows up in the
code on godbolt, even with recent gcc trunk.

I have submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096 for
this.

Stephen Fuld wrote:
> On 8/19/2023 10:02 AM, EricP wrote:
>
> snipped discussion on caller vs callee saved registers
>
>> The compiler could export a summary file describing the registers
>> used by each routine. This summary would be imported by the compiler
>> of callers to those routines so it could allocate registers not used
>> by the callee to the caller. Also the summary could be produced by
>> scanning a .OBJ or .DLL.
>>
>> Such a mechanism does not require modifications to source and
>> is also language independent.
>>
>> It does create a dependency between the caller and a particular
>> (timestamped) instance of a callee in a .OBJ or .DLL file.
>
> Not necessarily. If the compiler of the calling program also exported
> the used register lists of the routines it called when compiling the
> code, then the linker could check that the routines actually linked to
> did not use more registers than the caller assumed. This would work even
> if the called program was compiled at a different time than the one used
> at the main routine's compile time. (I hope this is clear. The
> language can get confusing.)

Yes, its clear.
I'm not so concerned about coordinating between separately compiled .OBJ
as they would just need to be compiled and summarized in the right order.

But a lot of leaf routines like math or string are in DLL shared libraries.
It would be a bit fragile and kinda defeats the whole purpose of shared
libraries if you have to recompile all your application code when a new
version of a DLL shows up.

So I thought it was worth noting, particularly for math library users
as those applications are the ones most likely to benefit from more
preserved registers across calls to sine, log, pow, etc.

> Of course, the question arises, what if a called routine does use more
> registers than the calling program was told at its compile time. There
> are several possibilities, abort the link, create trampoline routines to
> save and restore the newly used registers, perhaps others. The choice
> should certainly be made by the programmer.
>
> In fact, if at link time, the called program used fewer registers than
> the one assumed at compile time, that should be brought to the
> programmers attention as information, so perhaps the calling program
> could be recompiled and, by using more registers, be more efficient.

For modules that are part of a project and separately compiled then one
just recompiles them. The problem is for DLL's: detecting that a change
has occurred and then what to do about it (customers won't have source
code to recompile).

As a practical matter, apps wanting to do this optimization should
only use link (.OBJ) libraries for math, strings, etc and not DLL's.
(And let's just forget I mentioned DLL's at all.)

On Tuesday, August 22, 2023 at 9:04:23 AM UTC-5, EricP wrote:
> Stephen Fuld wrote:
> > On 8/19/2023 10:02 AM, EricP wrote:
> >
> > snipped discussion on caller vs callee saved registers
> >
> >> The compiler could export a summary file describing the registers
> >> used by each routine. This summary would be imported by the compiler
> >> of callers to those routines so it could allocate registers not used
> >> by the callee to the caller. Also the summary could be produced by
> >> scanning a .OBJ or .DLL.
> >>
> >> Such a mechanism does not require modifications to source and
> >> is also language independent.
> >>
> >> It does create a dependency between the caller and a particular
> >> (timestamped) instance of a callee in a .OBJ or .DLL file.
> >
> > Not necessarily. If the compiler of the calling program also exported
> > the used register lists of the routines it called when compiling the
> > code, then the linker could check that the routines actually linked to
> > did not use more registers than the caller assumed. This would work even
> > if the called program was compiled at a different time than the one used
> > at the main routine's compile time. (I hope this is clear. The
> > language can get confusing.)
> Yes, its clear.
<
> I'm not so concerned about coordinating between separately compiled .OBJ
> as they would just need to be compiled and summarized in the right order.
>
> But a lot of leaf routines like math or string are in DLL shared libraries.
> It would be a bit fragile and kinda defeats the whole purpose of shared
> libraries if you have to recompile all your application code when a new
> version of a DLL shows up.
<
Don't allow the new version of the DLL to use more registers than the
previous in any groupings.
>
> So I thought it was worth noting, particularly for math library users
> as those applications are the ones most likely to benefit from more
> preserved registers across calls to sine, log, pow, etc.
<
All of these "function calls" end up being instructions in My 66000 ISA.
But, even those that are not functions take "way less code" than similar
RISC-V compilations of those codes--mainly because these codes are
polynomials with constant coefficients. For example r8_erf() from
polpack only needs 43% as many instructions as it needs in RISC-V
and when the compiler limit on constants in registers limitations are
removed, better still. {and as a side note:: this is a function where
RISC-V with separate GPR and FPR registers files needs spill/fill
code, whereas My 66000 with integrated GPR does not--entirely du
to universal constants}.
<
Straightforward polynomial evaluation (Horner, Estrin) only needs 6-ish
registers (index, pointer, coefficient, power, product and summation)::
SIN(), COS(), Ln() family, exp() family, ATAN(), and POW() all fall into
this general category. I suspect many more straightforward polynomial
evaluations do too.
<
> > Of course, the question arises, what if a called routine does use more
> > registers than the calling program was told at its compile time. There
> > are several possibilities, abort the link, create trampoline routines to
> > save and restore the newly used registers, perhaps others. The choice
> > should certainly be made by the programmer.
> >
> > In fact, if at link time, the called program used fewer registers than
> > the one assumed at compile time, that should be brought to the
> > programmers attention as information, so perhaps the calling program
> > could be recompiled and, by using more registers, be more efficient.
<
> For modules that are part of a project and separately compiled then one
> just recompiles them. The problem is for DLL's: detecting that a change
> has occurred and then what to do about it (customers won't have source
> code to recompile).
<
DLLs have a defined interface--what you need is for that definition to
include the number of registers in each group and never change that
definition. A side effect is that the compiler will need flag-inputs to
specify those register groups.
>
> As a practical matter, apps wanting to do this optimization should
> only use link (.OBJ) libraries for math, strings, etc and not DLL's.
> (And let's just forget I mentioned DLL's at all.)
<
Do you really want 462 copies of SIN() and COS() occupying memory ??
{{Also note: My 66000 ISA can call DLLs using no more instructions
than local functions. No trampolines required.}}

In article <ublni6$3s8o9$1@dont-email.me>,
Kent Dickey <kegs@provalid.com> wrote:
>It is a mistake to make these new registers caller save. There are ways
>to make them callee save.

For unlimited performance, a port can statically mark call used/call
saved registers into the type system and code-gen is then perfect at
the expense of requiring source code annotations. We did this on our
last port of llvm, not that hard to do, and when there is uncertainty
around exactly the right trade off between call used and call saved.

This is mainly useful in code where performance is important and the
user is doing all the kernel work and not using pre-built libraries.

The benefit, no LTO cost, easy to see, audit in the source code,
direct control over exactly which registers are saved/used, if needed.
Downside, people using the system have to have stronger asm skills and
know what registers are. :-)

On 8/22/2023 7:03 AM, EricP wrote:
> Stephen Fuld wrote:
>> On 8/19/2023 10:02 AM, EricP wrote:
>>
>> snipped discussion on caller vs callee saved registers
>>
>>> The compiler could export a summary file describing the registers
>>> used by each routine. This summary would be imported by the compiler
>>> of callers to those routines so it could allocate registers not used
>>> by the callee to the caller. Also the summary could be produced by
>>> scanning a .OBJ or .DLL.
>>>
>>> Such a mechanism does not require modifications to source and
>>> is also language independent.
>>>
>>> It does create a dependency between the caller and a particular
>>> (timestamped) instance of a callee in a .OBJ or .DLL file.
>>
>> Not necessarily. If the compiler of the calling program also exported
>> the used register lists of the routines it called when compiling the
>> code, then the linker could check that the routines actually linked to
>> did not use more registers than the caller assumed. This would work
>> even if the called program was compiled at a different time than the
>> one used at the main routine's compile time. (I hope this is clear.
>> The language can get confusing.)
>
> Yes, its clear.
> I'm not so concerned about coordinating between separately compiled .OBJ
> as they would just need to be compiled and summarized in the right order.
>
> But a lot of leaf routines like math or string are in DLL shared
libraries.
> It would be a bit fragile and kinda defeats the whole purpose of shared
> libraries if you have to recompile all your application code when a new
> version of a DLL shows up.

Again, not necessarily. As Mitch pointed out, you just need to assure
that the new version of the DLL uses no more registers than the older
one. So you need a compiler option to retrieve the relevant information
that was exported from the previous version of the file being compiled,
and stick to the same registers. Perhaps a little ugly for the compiler
internally, but I suspect that many/most changes to a DLL are modest
fixes that wouldn't require more registers, thus needed recompiles would
be rare.

Of course, you do need to have a check at initial DLL load time, similar
to the check made at link time for statically linked libraries, to
verify compatibility of the callee with the caller.

snip

> For modules that are part of a project and separately compiled then one
> just recompiles them. The problem is for DLL's: detecting that a change
> has occurred and then what to do about it (customers won't have source
> code to recompile).

But they have the source code for their own programs. So if the
compiler retrieved the "registers used" information for any DLLs called,
similar to what it does for non-dynamically linked libraries,
recompiling the user program with the new DLL version available will
"automatically" fix the problem.

I realize this means that compiling a program on a system with a
differently register using versions of a DLL than the one the program
ultimately executes on could cause a problem. For this reason, the
compiler should have an option to restrict its register usage to the
ones specified in the registers used information for the previous
version of the program. This could at least, minimize, and perhaps
eliminate the problem.

> As a practical matter, apps wanting to do this optimization should
> only use link (.OBJ) libraries for math, strings, etc and not DLL's.
> (And let's just forget I mentioned DLL's at all.)

While DLLs do add some complexity, I think it can be handled without too
much additional work.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

MitchAlsup wrote:
> On Tuesday, August 22, 2023 at 9:04:23 AM UTC-5, EricP wrote:
>> Stephen Fuld wrote:
>>> On 8/19/2023 10:02 AM, EricP wrote:
>>>
>>> snipped discussion on caller vs callee saved registers
>>>
>>>> The compiler could export a summary file describing the registers
>>>> used by each routine. This summary would be imported by the compiler
>>>> of callers to those routines so it could allocate registers not used
>>>> by the callee to the caller. Also the summary could be produced by
>>>> scanning a .OBJ or .DLL.
>>>>
>>>> Such a mechanism does not require modifications to source and
>>>> is also language independent.
>>>>
>>>> It does create a dependency between the caller and a particular
>>>> (timestamped) instance of a callee in a .OBJ or .DLL file.
>>> Not necessarily. If the compiler of the calling program also exported
>>> the used register lists of the routines it called when compiling the
>>> code, then the linker could check that the routines actually linked to
>>> did not use more registers than the caller assumed. This would work even
>>> if the called program was compiled at a different time than the one used
>>> at the main routine's compile time. (I hope this is clear. The
>>> language can get confusing.)
>> Yes, its clear.
> <
>> I'm not so concerned about coordinating between separately compiled .OBJ
>> as they would just need to be compiled and summarized in the right order.
>>
>> But a lot of leaf routines like math or string are in DLL shared libraries.
>> It would be a bit fragile and kinda defeats the whole purpose of shared
>> libraries if you have to recompile all your application code when a new
>> version of a DLL shows up.
> <
> Don't allow the new version of the DLL to use more registers than the
> previous in any groupings.
>> So I thought it was worth noting, particularly for math library users
>> as those applications are the ones most likely to benefit from more
>> preserved registers across calls to sine, log, pow, etc.
> <
> All of these "function calls" end up being instructions in My 66000 ISA.
> But, even those that are not functions take "way less code" than similar
> RISC-V compilations of those codes--mainly because these codes are
> polynomials with constant coefficients. For example r8_erf() from
> polpack only needs 43% as many instructions as it needs in RISC-V
> and when the compiler limit on constants in registers limitations are
> removed, better still. {and as a side note:: this is a function where
> RISC-V with separate GPR and FPR registers files needs spill/fill
> code, whereas My 66000 with integrated GPR does not--entirely du
> to universal constants}.
> <
> Straightforward polynomial evaluation (Horner, Estrin) only needs 6-ish
> registers (index, pointer, coefficient, power, product and summation)::
> SIN(), COS(), Ln() family, exp() family, ATAN(), and POW() all fall into
> this general category. I suspect many more straightforward polynomial
> evaluations do too.

Even with your transcendental instructions, would not these still be
implemented as non-inlined subroutines? Because for different languages,
Fortran, C, the math functions in particular have different ways of
interacting with the run-time environment to report errors.

Eg C/C++ math functions can set errno which is a TLS variable.
I don't know what GCC Fortran does for its error status reporting.
VAX Fortran language math functions threw an exception for error conditions,
however VAX library math functions returned a function status code.

> <
>>> Of course, the question arises, what if a called routine does use more
>>> registers than the calling program was told at its compile time. There
>>> are several possibilities, abort the link, create trampoline routines to
>>> save and restore the newly used registers, perhaps others. The choice
>>> should certainly be made by the programmer.
>>>
>>> In fact, if at link time, the called program used fewer registers than
>>> the one assumed at compile time, that should be brought to the
>>> programmers attention as information, so perhaps the calling program
>>> could be recompiled and, by using more registers, be more efficient.
> <
>> For modules that are part of a project and separately compiled then one
>> just recompiles them. The problem is for DLL's: detecting that a change
>> has occurred and then what to do about it (customers won't have source
>> code to recompile).
> <
> DLLs have a defined interface--what you need is for that definition to
> include the number of registers in each group and never change that
> definition. A side effect is that the compiler will need flag-inputs to
> specify those register groups.
>> As a practical matter, apps wanting to do this optimization should
>> only use link (.OBJ) libraries for math, strings, etc and not DLL's.
>> (And let's just forget I mentioned DLL's at all.)
> <
> Do you really want 462 copies of SIN() and COS() occupying memory ??
> {{Also note: My 66000 ISA can call DLLs using no more instructions
> than local functions. No trampolines required.}}

There are not multiple copies, unless one inlines routines
and we are not talking about inlined code.

If I link with an object OBJ library I get *one* copy of a routine
included in my EXE. However that code is not shared with other apps that
also link with that same routine (eg each app has its own sin routine).

If I link with a shared DLL library then I do not get a copy of that
routine in my EXE, I get a call to a routine in the DLL, of which there
is a single instance for all applications (eg one sin routine shared
between all applications).

But as I said, even if technically possible its probably better to
take DLL's out of consideration and just use link libraries.

On Tuesday, August 22, 2023 at 12:27:19 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Tuesday, August 22, 2023 at 9:04:23 AM UTC-5, EricP wrote:
> >> Stephen Fuld wrote:
> >>> On 8/19/2023 10:02 AM, EricP wrote:
> >>>
> >>> snipped discussion on caller vs callee saved registers
> >>>
> >>>> The compiler could export a summary file describing the registers
> >>>> used by each routine. This summary would be imported by the compiler
> >>>> of callers to those routines so it could allocate registers not used
> >>>> by the callee to the caller. Also the summary could be produced by
> >>>> scanning a .OBJ or .DLL.
> >>>>
> >>>> Such a mechanism does not require modifications to source and
> >>>> is also language independent.
> >>>>
> >>>> It does create a dependency between the caller and a particular
> >>>> (timestamped) instance of a callee in a .OBJ or .DLL file.
> >>> Not necessarily. If the compiler of the calling program also exported
> >>> the used register lists of the routines it called when compiling the
> >>> code, then the linker could check that the routines actually linked to
> >>> did not use more registers than the caller assumed. This would work even
> >>> if the called program was compiled at a different time than the one used
> >>> at the main routine's compile time. (I hope this is clear. The
> >>> language can get confusing.)
> >> Yes, its clear.
> > <
> >> I'm not so concerned about coordinating between separately compiled .OBJ
> >> as they would just need to be compiled and summarized in the right order.
> >>
> >> But a lot of leaf routines like math or string are in DLL shared libraries.
> >> It would be a bit fragile and kinda defeats the whole purpose of shared
> >> libraries if you have to recompile all your application code when a new
> >> version of a DLL shows up.
> > <
> > Don't allow the new version of the DLL to use more registers than the
> > previous in any groupings.
> >> So I thought it was worth noting, particularly for math library users
> >> as those applications are the ones most likely to benefit from more
> >> preserved registers across calls to sine, log, pow, etc.
> > <
> > All of these "function calls" end up being instructions in My 66000 ISA..
> > But, even those that are not functions take "way less code" than similar
> > RISC-V compilations of those codes--mainly because these codes are
> > polynomials with constant coefficients. For example r8_erf() from
> > polpack only needs 43% as many instructions as it needs in RISC-V
> > and when the compiler limit on constants in registers limitations are
> > removed, better still. {and as a side note:: this is a function where
> > RISC-V with separate GPR and FPR registers files needs spill/fill
> > code, whereas My 66000 with integrated GPR does not--entirely du
> > to universal constants}.
> > <
> > Straightforward polynomial evaluation (Horner, Estrin) only needs 6-ish
> > registers (index, pointer, coefficient, power, product and summation)::
> > SIN(), COS(), Ln() family, exp() family, ATAN(), and POW() all fall into
> > this general category. I suspect many more straightforward polynomial
> > evaluations do too.
> Even with your transcendental instructions, would not these still be
> implemented as non-inlined subroutines? Because for different languages,
> Fortran, C, the math functions in particular have different ways of
> interacting with the run-time environment to report errors.
>
> Eg C/C++ math functions can set errno which is a TLS variable.
> I don't know what GCC Fortran does for its error status reporting.
> VAX Fortran language math functions threw an exception for error conditions,
> however VAX library math functions returned a function status code.
> > <
> >>> Of course, the question arises, what if a called routine does use more
> >>> registers than the calling program was told at its compile time. There
> >>> are several possibilities, abort the link, create trampoline routines to
> >>> save and restore the newly used registers, perhaps others. The choice
> >>> should certainly be made by the programmer.
> >>>
> >>> In fact, if at link time, the called program used fewer registers than
> >>> the one assumed at compile time, that should be brought to the
> >>> programmers attention as information, so perhaps the calling program
> >>> could be recompiled and, by using more registers, be more efficient.
> > <
> >> For modules that are part of a project and separately compiled then one
> >> just recompiles them. The problem is for DLL's: detecting that a change
> >> has occurred and then what to do about it (customers won't have source
> >> code to recompile).
> > <
> > DLLs have a defined interface--what you need is for that definition to
> > include the number of registers in each group and never change that
> > definition. A side effect is that the compiler will need flag-inputs to
> > specify those register groups.
> >> As a practical matter, apps wanting to do this optimization should
> >> only use link (.OBJ) libraries for math, strings, etc and not DLL's.
> >> (And let's just forget I mentioned DLL's at all.)
> > <
> > Do you really want 462 copies of SIN() and COS() occupying memory ??
> > {{Also note: My 66000 ISA can call DLLs using no more instructions
> > than local functions. No trampolines required.}}
<
> There are not multiple copies, unless one inlines routines
> and we are not talking about inlined code.
<
Nor was I:: System is running 462 applications simultaneously that
call various transcendental functions, and each application has its
static copy of the transcendentals it uses. It is still 462 copies, even
when not inlined, being included in the object module is enough to
to be a unique instantiation of the <shareable> function.
>
> If I link with an object OBJ library I get *one* copy of a routine
<
per application.
<
> included in my EXE. However that code is not shared with other apps that
> also link with that same routine (eg each app has its own sin routine).
>
my point exactly.
>
> If I link with a shared DLL library then I do not get a copy of that
> routine in my EXE, I get a call to a routine in the DLL, of which there
> is a single instance for all applications (eg one sin routine shared
> between all applications).
<
Thus saving memory, and in my system to taking any more instructions
to perform the call and return.
>
> But as I said, even if technically possible its probably better to
> take DLL's out of consideration and just use link libraries.
<
Each instance suffering its own ICache misses because the code is
not shared.

According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>Not necessarily. If the compiler of the calling program also exported
>the used register lists of the routines it called when compiling the
>code, then the linker could check that the routines actually linked to
>did not use more registers than the caller assumed. This would work even
>if the called program was compiled at a different time than the one used
>at the main routine's compile time. (I hope this is clear. The
>language can get confusing.)

Ah, you mean signatures for calling points. It's an old trick dating
back to the 1970s used to check that the arguments passed from the
caller match the ones the callee expects. No reason you couldn't do
the same think to check for compatible register sets.

>Of course, the question arises, what if a called routine does use more
>registers than the calling program was told at its compile time. There
>are several possibilities, abort the link, create trampoline routines to
>save and restore the newly used registers, perhaps others. The choice
>should certainly be made by the programmer.

This is why sensible libraries use version numbers with major numbers
meaning an interface change and minor numbers just a bug fix. You
relink your code to use a new major version of the library. Every Unix
and Linux system does this.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Kent Dickey wrote:
> typedef unsigned int u32;
> typedef unsigned long long u64;
>
> u64 do_op(u64 out0, u64 in0, u64 in1, u32 opcode, int size);
>
> void
> calc_loop(u64 *optr, u64 *iptr0, u64 *iptr1, u32 opcode, int size, int len)
> {
> u64 o0, i0, i1, val, result;
> int num, shift, pos;
> int i, j;
>
> // size is 0,1,2,3 representing 8,16,32,64 bytes
> num = 8 >> size; // 8,4,2,1
> shift = 8 << size; // 8,16,32,64
> for(i = 0; i < len; i++) {
> o0 = optr[i];
> i0 = iptr0[i];
> i1 = iptr1[i];
> result = 0;
> pos = 0;
> for(j = 0; j < num; j++) {
> val = do_op(o0, i0, i1, opcode, size);

How expensive is do_op()? If it takes 100+ cycles, then calc_loop
doesn't really matter, right? So I'll assume do_op is sub-10 cycles and
small enough to be inlined!

> result = result | (val << pos);
pos cannot be >= 64?
> pos += shift;
> if(shift < 64) {
The branch above could be replaced with masked shifts:
> o0 = o0 >> shift;
o0 >>= (shift & 63);
> i0 = i0 >> shift;
i0 >>= (shift & 63);
> i1 = i1 >> shift;
i1 >>= (shift & 63);
> }

On x86 the compiler will probably elide the &63 operations since that is
a hw feature of the shift ops.

> }
> optr[i] = result;
> }
> }
>
> The idea is the outer 'i' loop iterates over 64-bit entries, and the
> inner 'j' loop iterates over each element, and the element size is encoded
> as size=0->byte; size=1->16-bit; size=2->32-bit, size=3->64-bit.
> The code keeps three arrays, one "out" array (which is used as an input
> sometimes), and two "in" arrays.

Would it be possible to allocate optr[], iptr0[], iptr1[] either
interleaved or concatenated so that a single base register to point to
optr[] and the two other being at fixed offsets?

Terje

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

On 8/22/2023 12:07 PM, John Levine wrote:
> According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>> Not necessarily. If the compiler of the calling program also exported
>> the used register lists of the routines it called when compiling the
>> code, then the linker could check that the routines actually linked to
>> did not use more registers than the caller assumed. This would work even
>> if the called program was compiled at a different time than the one used
>> at the main routine's compile time. (I hope this is clear. The
>> language can get confusing.)
>
> Ah, you mean signatures for calling points. It's an old trick dating
> back to the 1970s used to check that the arguments passed from the
> caller match the ones the callee expects. No reason you couldn't do
> the same think to check for compatible register sets.

Good point. I hadn't thought of that connection, but yes.

>> Of course, the question arises, what if a called routine does use more
>> registers than the calling program was told at its compile time. There
>> are several possibilities, abort the link, create trampoline routines to
>> save and restore the newly used registers, perhaps others. The choice
>> should certainly be made by the programmer.
>
> This is why sensible libraries use version numbers with major numbers
> meaning an interface change and minor numbers just a bug fix. You
> relink your code to use a new major version of the library. Every Unix
> and Linux system does this.

But it isn't clear that changing the registers used internally is an
"interface change". It certainly isn't a change in the source code of
the interface. Or, to put it another way, a "bug fix" may change the
register usage without changing what is typically called the "interface".

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>>> Of course, the question arises, what if a called routine does use more
>>> registers than the calling program was told at its compile time. There
>>> are several possibilities, abort the link, create trampoline routines to
>>> save and restore the newly used registers, perhaps others. The choice
>>> should certainly be made by the programmer.
>>
>> This is why sensible libraries use version numbers with major numbers
>> meaning an interface change and minor numbers just a bug fix. You
>> relink your code to use a new major version of the library. Every Unix
>> and Linux system does this.
>
>But it isn't clear that changing the registers used internally is an
>"interface change". It certainly isn't a change in the source code of
>the interface. Or, to put it another way, a "bug fix" may change the
>register usage without changing what is typically called the "interface".

If the register sets have to match between caller and callee, that seems
to me to be an interface by definition.

There's be some tool building work to be check that the register sets
don't change when rebuilding a library if we make them part of the
interface. But it doesn't seem that hard, just compare old and new
libraries and fail if the new one is more restrictive. Then of course
there's the issue of what to do, probably a new compiler flag or
pragma saying only use these registers, which I would be ugly.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

In article <uc32c1$2ho1k$1@dont-email.me>,
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>Kent Dickey wrote:

You removed my comment saying I wasn't going to entertain nitpicks, but
you have one reasonable request.

>> typedef unsigned int u32;
>> typedef unsigned long long u64;
>>
>> u64 do_op(u64 out0, u64 in0, u64 in1, u32 opcode, int size);
>>
>> void
>> calc_loop(u64 *optr, u64 *iptr0, u64 *iptr1, u32 opcode, int size, int len)
>> {
>> u64 o0, i0, i1, val, result;
>> int num, shift, pos;
>> int i, j;
>>
>> // size is 0,1,2,3 representing 8,16,32,64 bytes
>> num = 8 >> size; // 8,4,2,1
>> shift = 8 << size; // 8,16,32,64
>> for(i = 0; i < len; i++) {
>> o0 = optr[i];
>> i0 = iptr0[i];
>> i1 = iptr1[i];
>> result = 0;
>> pos = 0;
>> for(j = 0; j < num; j++) {
>> val = do_op(o0, i0, i1, opcode, size);
>
>How expensive is do_op()? If it takes 100+ cycles, then calc_loop
>doesn't really matter, right? So I'll assume do_op is sub-10 cycles and
>small enough to be inlined!

do_op() is a giant switch with 50+ entries. It's an ALU simulation:

switch(opcode) {
case 0:
return i0 + i1;
case 1:
return i0 - i1;
....
case 49:
return i0 * i1;
}

So it's just a few instructions dynamically (the opcode isn't changing
in the loop, so it should get predicted after a few iterations to go to
the opcode of interest, which is generally one instruction). But it's
hundreds of instructions in total size. In a different file.

>> result = result | (val << pos);
>pos cannot be >= 64?

pos cannot be >= 64 when this shift is executed. Pos can be set to 64
in the next statement, but then this inner loop will end right after.

>> pos += shift;
>> if(shift < 64) {
>The branch above could be replaced with masked shifts:
>> o0 = o0 >> shift;
> o0 >>= (shift & 63);
>> i0 = i0 >> shift;
> i0 >>= (shift & 63);
>> i1 = i1 >> shift;
> i1 >>= (shift & 63);
>> }

I mentioned doing & 63 in my 2020 post, this is a flaw in C standard which
is beyond the scope of this post.

>
>On x86 the compiler will probably elide the &63 operations since that is
>a hw feature of the shift ops.
>
>> }
>> optr[i] = result;
>> }
>> }
>>
>> The idea is the outer 'i' loop iterates over 64-bit entries, and the
>> inner 'j' loop iterates over each element, and the element size is encoded
>> as size=0->byte; size=1->16-bit; size=2->32-bit, size=3->64-bit.
>> The code keeps three arrays, one "out" array (which is used as an input
>> sometimes), and two "in" arrays.
>
>Would it be possible to allocate optr[], iptr0[], iptr1[] either
>interleaved or concatenated so that a single base register to point to
>optr[] and the two other being at fixed offsets?

I was trying to show a short routine that needs about 16 registers to avoid
spills, since someone immediately doubted that such a thing existed.

The code is written in a careful way to allow the compiler to optimize it
to be nearly optimum, but in this case, there just aren't enough registers,
so something I expected to be short and fast isn't that short.

You are approaching this as a microbenchmark, where this routine is 80%
of the runtime, and making it faster is worth the effort. Instead, I
have 1000 functions like this, each 0.04% of the runtime, and I don't
have time or resources to micro optimize each of them. So I care about
overall performance, but I cannot hand optimize each function. I need
to rely on the compiler to do a good job.

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

Kent

EricP <ThatWouldBeTelling@thevillage.com> schrieb:
> MitchAlsup wrote:

>> All of these "function calls" end up being instructions in My 66000 ISA.
>> But, even those that are not functions take "way less code" than similar
>> RISC-V compilations of those codes--mainly because these codes are
>> polynomials with constant coefficients. For example r8_erf() from
>> polpack only needs 43% as many instructions as it needs in RISC-V
>> and when the compiler limit on constants in registers limitations are
>> removed, better still. {and as a side note:: this is a function where
>> RISC-V with separate GPR and FPR registers files needs spill/fill
>> code, whereas My 66000 with integrated GPR does not--entirely du
>> to universal constants}.
>> <
>> Straightforward polynomial evaluation (Horner, Estrin) only needs 6-ish
>> registers (index, pointer, coefficient, power, product and summation)::
>> SIN(), COS(), Ln() family, exp() family, ATAN(), and POW() all fall into
>> this general category. I suspect many more straightforward polynomial
>> evaluations do too.
>
> Even with your transcendental instructions, would not these still be
> implemented as non-inlined subroutines? Because for different languages,
> Fortran, C, the math functions in particular have different ways of
> interacting with the run-time environment to report errors.

C actually has no requirement of setting errno on out-of-range
calls to mathematical functions. You can use -fno-math-errno to
get this behavior from gcc (and, I believe, clang). Apple chose
not to include setting errno in MacOS, and they made the right
decision there - thread safety and vectorization make setting errno
a performance limiter.

Anybody making a new implementation is equally free to not set
errno on math functions, and this makes good sense on My 666000.

> Eg C/C++ math functions can set errno which is a TLS variable.
> I don't know what GCC Fortran does for its error status reporting.

Since Fortran has no errno, gfortran in effect just uses
-fno-math-errno. Range errors are usually treated by returning NaN.

Michael S <already5chosen@yahoo.com> writes:
>There is other side of the same argument: can you show me (or more
>relevantly to designers of aarch64 ABI) some code which needs 16
> callee-saved registers, and would run noticeably slower with 11
> callee-saved registers ?

I think that a number of virtual-machine (VM) interpreters (a common
programming language implementation technique) would benefit. An
example is Gforth, and I am one of its implementors.

In Gforth we have the following virtual-machine registers:

ip VM instruction pointer
CFA Current word (VM instruction or other)
sp data stack pointer
fp FP stack pointer
rp return stack pointer
lp locals pointer
op object pointer (this/self)
up user pointer (base of thread-local variables)
TOS top of data stack
FTOS top of FP stack (in FP register)

Apart from TOS, these VM registers all live across many function
calls, and therefore gcc either puts them in caller-saved registers,
or, if it runs out of those, puts them in memory.

TOS is a special case: It is usually dead during most of the VM
instruction execution. The exception are VM instructions that have no
data-stack effect (e.g., FP instructions like FSIN). And there are
apparently few enough of those in the engine function that gcc manages
to put TOS in a caller-saved register (r8 in the engine that I am
currently looking at) and save and restore TOS around the few
functions where it lives.

So this means that we already have 8 VM registers for which gcc needs
caller-saved registers.

We have had some ideas that would have introduced additional VM
registers to enhance performance (if enough caller-saved registers
were available), but given the dearth of caller-saved registers on
most platforms, we usually have not implemented these ideas.

There is, however, one case where we implemented such an idea: We use
additional registers for keeping data-stack items in registers,
providing significant speedups. You can read about it in
[ertl&gregg05].

If more caller-saved registers were widely available, we would have
implemented additional ideas, which might have provided additional
speedups. E.g., we could have kept the top of the return stack in a
register, which also serves as the counter of counted loops,
increasing the performance of counted loops.

And Gforth uses a simple virtual machine. I expect that virtual
machines for more sophisticated languages, like Prolog, can make good
use of more VM registers and thus more callee-saved register.
Unfortunately, it is over 30 years since I implemented a virtual
machine interpreter for Prolog, so I'll skip the details.

CPython (the main Python implementation) also use a virtual machine
interpreter, and the CPython implementors have various projects to
make this interpreter faster; I expect that more callee-saved
registers would benefit them quite a bit.

@InProceedings{ertl&gregg05,
author = {M. Anton Ertl and David Gregg},
title = {Stack Caching in {Forth}},
crossref = {euroforth05},
pages = {6--15},
url = {http://www.complang.tuwien.ac.at/papers/ertl%26gregg05.ps.gz},
pdfurl = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/ertl%26gregg05.pdf},
OPTnote = {not refereed},
abstract = {Stack caching speeds Forth up by keeping stack items
in registers, reducing the number of memory accesses
for stack items. This paper describes our work on
extending Gforth's stack caching implementation to
support more than one register in the canonical
state, and presents timing results for the resulting
Forth system. For single-representation stack
caches, keeping just one stack item in registers is
usually best, and provides speedups up to a factor
of 2.84 over the straight-forward stack
representation. For stack caches with multiple stack
representations, using the one-register
representation as canonical representation is
usually optimal, resulting in an overall speedup of
up to a factor of 3.80 (and up to a factor of 1.53
over single-representation stack caching).}
} @Proceedings{euroforth05,
title = {21st EuroForth Conference},
booktitle = {21st EuroForth Conference},
year = {2005},
key = {EuroForth'05},
editor = {M. Anton Ertl},
url = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/proceedings.pdf}
}

>I tend to think that they tried to give a deep thought, but in the process=
>=20
>quickly came to conclusion that it matters very little.

Based on what?

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

On Wednesday, August 23, 2023 at 9:12:54 AM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >There is other side of the same argument: can you show me (or more
> >relevantly to designers of aarch64 ABI) some code which needs 16
> > callee-saved registers, and would run noticeably slower with 11
> > callee-saved registers ?
> I think that a number of virtual-machine (VM) interpreters (a common
> programming language implementation technique) would benefit. An
> example is Gforth, and I am one of its implementors.
>
> In Gforth we have the following virtual-machine registers:
>
> ip VM instruction pointer
> CFA Current word (VM instruction or other)
> sp data stack pointer
> fp FP stack pointer
> rp return stack pointer
> lp locals pointer
> op object pointer (this/self)
> up user pointer (base of thread-local variables)
> TOS top of data stack
> FTOS top of FP stack (in FP register)
>
> Apart from TOS, these VM registers all live across many function
> calls, and therefore gcc either puts them in caller-saved registers,
> or, if it runs out of those, puts them in memory.
>
> TOS is a special case: It is usually dead during most of the VM
> instruction execution. The exception are VM instructions that have no
> data-stack effect (e.g., FP instructions like FSIN). And there are
> apparently few enough of those in the engine function that gcc manages
> to put TOS in a caller-saved register (r8 in the engine that I am
> currently looking at) and save and restore TOS around the few
> functions where it lives.
>
> So this means that we already have 8 VM registers for which gcc needs
> caller-saved registers.
>
> We have had some ideas that would have introduced additional VM
> registers to enhance performance (if enough caller-saved registers
> were available), but given the dearth of caller-saved registers on
> most platforms, we usually have not implemented these ideas.
>
> There is, however, one case where we implemented such an idea: We use
> additional registers for keeping data-stack items in registers,
> providing significant speedups. You can read about it in
> [ertl&gregg05].
>
> If more caller-saved registers were widely available, we would have
> implemented additional ideas, which might have provided additional
> speedups.
> E.g., we could have kept the top of the return stack in a
> register, which also serves as the counter of counted loops,
> increasing the performance of counted loops.
>

Did you try to experiment on POWER in order to see whether the speed
up is noticeable?

> And Gforth uses a simple virtual machine. I expect that virtual
> machines for more sophisticated languages, like Prolog, can make good
> use of more VM registers and thus more callee-saved register.
> Unfortunately, it is over 30 years since I implemented a virtual
> machine interpreter for Prolog, so I'll skip the details.
>
> CPython (the main Python implementation) also use a virtual machine
> interpreter, and the CPython implementors have various projects to
> make this interpreter faster; I expect that more callee-saved
> registers would benefit them quite a bit.
>
> @InProceedings{ertl&gregg05,
> author = {M. Anton Ertl and David Gregg},
> title = {Stack Caching in {Forth}},
> crossref = {euroforth05},
> pages = {6--15},
> url = {http://www.complang.tuwien.ac.at/papers/ertl%26gregg05.ps.gz},
> pdfurl = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/ertl%26gregg05.pdf},
> OPTnote = {not refereed},
> abstract = {Stack caching speeds Forth up by keeping stack items
> in registers, reducing the number of memory accesses
> for stack items. This paper describes our work on
> extending Gforth's stack caching implementation to
> support more than one register in the canonical
> state, and presents timing results for the resulting
> Forth system. For single-representation stack
> caches, keeping just one stack item in registers is
> usually best, and provides speedups up to a factor
> of 2.84 over the straight-forward stack
> representation. For stack caches with multiple stack
> representations, using the one-register
> representation as canonical representation is
> usually optimal, resulting in an overall speedup of
> up to a factor of 3.80 (and up to a factor of 1.53
> over single-representation stack caching).}
> }
> @Proceedings{euroforth05,
> title = {21st EuroForth Conference},
> booktitle = {21st EuroForth Conference},
> year = {2005},
> key = {EuroForth'05},
> editor = {M. Anton Ertl},
> url = {http://www.complang.tuwien.ac.at/anton/euroforth2005/papers/proceedings.pdf}
> }
>
> >I tend to think that they tried to give a deep thought, but in the process=
> >=20
> >quickly came to conclusion that it matters very little.
> Based on what?
>

Based on the corpus of benchmarks they have.
For 'other' industry players I would guess that it's primarily SpecInt.
In specific case of Arm Inc. - I don't know.

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

Michael S <already5chosen@yahoo.com> writes:
>On Wednesday, August 23, 2023 at 9:12:54=E2=80=AFAM UTC+3, Anton Ertl wrote=
>:
>> If more caller-saved registers were widely available, we would have=20
>> implemented additional ideas, which might have provided additional=20
>> speedups.
>> E.g., we could have kept the top of the return stack in a=20
>> register, which also serves as the counter of counted loops,=20
>> increasing the performance of counted loops.=20
>>=20
>
>Did you try to experiment on POWER in order to see whether the speed=20
>up is noticeable?

No. From a product POV, Power/PowerPC is too insignificant as a
platform to invest that much effort (plus the effort to make it an
optional feature) even if we see a good speedup there. And I don't
think that this work would be considered sufficiently original and
relevant to be publishable as a research paper, so I also did not do
it as research, either.

>Based on the corpus of benchmarks they have.
>For 'other' industry players I would guess that it's primarily SpecInt.=20
>In specific case of Arm Inc. - I don't know.

With that methodology, I would expect the number of callee-saved
registers to be very similar across architectures. But they diverge
wildly.

OTOH, when most architectures were introduced, Hennessy&Patterson had
not written CA:AQA, so maybe the architects used handwawing for these
decisions (although, at least for HPPA, a quantitative approach was
reported for deciding which instructions to include. HPPA has
gr3..gr18 as callee-saved registers, i.e., 16 callee-saved registers).
Only AMD64, ARM A64, and RISC-V are significantly younger than CA:AQA.
For MIPS O32, derived from Stanford MIPS, one might also expect a
quantitative approach, but the benchmarks they used for Stanford MIPS
were not significant applications, but instead small integer
benchmarks, so one should not be surprised that they did not see a
benefit from more than 8 callee-saved registers.

For AMD64 the low number of callee-saved registers may be due to the
lack of registers overall (although even with stack pointer, frame
pointer, and six argument/return registers, 8 registers could be
callee-saved (9 with --fomit-frame-pointer).

For ARM A64 and RISC-V, the number may indeed be due to catering for
benchmarks, and indeed primarily for SPEC CPU and the like.

In this case: So decades of register-starved architectures (IA-32,
AMD64) and architectures with very few callee-saved registers (MIPS,
Alpha) have led to applications that are tuned to use few callee-saved
registers. And then such applications are used as benchmarks that
lead architects to have few callee-saved registers. It's a vicious
circle.

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

On Wednesday, August 23, 2023 at 11:59:30 AM UTC+3, Anton Ertl wrote:
> Michael S <already...@yahoo.com> writes:
> >On Wednesday, August 23, 2023 at 9:12:54=E2=80=AFAM UTC+3, Anton Ertl wrote=
> >:
> >> If more caller-saved registers were widely available, we would have=20
> >> implemented additional ideas, which might have provided additional=20
> >> speedups.
> >> E.g., we could have kept the top of the return stack in a=20
> >> register, which also serves as the counter of counted loops,=20
> >> increasing the performance of counted loops.=20
> >>=20
> >
> >Did you try to experiment on POWER in order to see whether the speed=20
> >up is noticeable?
>
> No. From a product POV, Power/PowerPC is too insignificant as a
> platform to invest that much effort (plus the effort to make it an
> optional feature) even if we see a good speedup there. And I don't
> think that this work would be considered sufficiently original and
> relevant to be publishable as a research paper, so I also did not do
> it as research, either.
> >Based on the corpus of benchmarks they have.
> >For 'other' industry players I would guess that it's primarily SpecInt.=20
> >In specific case of Arm Inc. - I don't know.
> With that methodology, I would expect the number of callee-saved
> registers to be very similar across architectures.

Not if, as I suspect, the curve in range [10:20] is almost flat.

> But they diverge wildly.

If curve is flat then decision is arbitrary == influenced by something else.

>
> OTOH, when most architectures were introduced, Hennessy&Patterson had
> not written CA:AQA, so maybe the architects used handwawing for these
> decisions (although, at least for HPPA, a quantitative approach was
> reported for deciding which instructions to include. HPPA has
> gr3..gr18 as callee-saved registers, i.e., 16 callee-saved registers).
> Only AMD64, ARM A64, and RISC-V are significantly younger than CA:AQA.
> For MIPS O32, derived from Stanford MIPS, one might also expect a
> quantitative approach, but the benchmarks they used for Stanford MIPS
> were not significant applications, but instead small integer
> benchmarks, so one should not be surprised that they did not see a
> benefit from more than 8 callee-saved registers.
>
> For AMD64 the low number of callee-saved registers may be due to the
> lack of registers overall (although even with stack pointer, frame
> pointer, and six argument/return registers, 8 registers could be
> callee-saved (9 with --fomit-frame-pointer).
>
> For ARM A64 and RISC-V, the number may indeed be due to catering for
> benchmarks, and indeed primarily for SPEC CPU and the like.
>
> In this case: So decades of register-starved architectures (IA-32,
> AMD64) and architectures with very few callee-saved registers (MIPS,
> Alpha) have led to applications that are tuned to use few callee-saved
> registers. And then such applications are used as benchmarks that
> lead architects to have few callee-saved registers. It's a vicious
> circle.

I hope that coding style in SpecCpu suite is mostly influenced by factors
not related to micro-optimizations of such low-level sort.

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

Thomas Koenig <tkoenig@netcologne.de> writes:
>EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>> MitchAlsup wrote:
>
>>> All of these "function calls" end up being instructions in My 66000 ISA.
>>> But, even those that are not functions take "way less code" than similar
>>> RISC-V compilations of those codes--mainly because these codes are
>>> polynomials with constant coefficients. For example r8_erf() from
>>> polpack only needs 43% as many instructions as it needs in RISC-V
>>> and when the compiler limit on constants in registers limitations are
>>> removed, better still. {and as a side note:: this is a function where
>>> RISC-V with separate GPR and FPR registers files needs spill/fill
>>> code, whereas My 66000 with integrated GPR does not--entirely du
>>> to universal constants}.
>>> <
>>> Straightforward polynomial evaluation (Horner, Estrin) only needs 6-ish
>>> registers (index, pointer, coefficient, power, product and summation)::
>>> SIN(), COS(), Ln() family, exp() family, ATAN(), and POW() all fall into
>>> this general category. I suspect many more straightforward polynomial
>>> evaluations do too.
>>
>> Even with your transcendental instructions, would not these still be
>> implemented as non-inlined subroutines? Because for different languages,
>> Fortran, C, the math functions in particular have different ways of
>> interacting with the run-time environment to report errors.
>
>C actually has no requirement of setting errno on out-of-range
>calls to mathematical functions. You can use -fno-math-errno to
>get this behavior from gcc (and, I believe, clang). Apple chose
>not to include setting errno in MacOS, and they made the right
>decision there - thread safety and vectorization make setting errno
>a performance limiter.

C doesn't. POSIX has an optional requirement to set errno.

"For all the functions in the <math.h> header, an application
wishing to check for error situations should set errno to 0 and
call feclearexcept(FE_ALL_EXCEPT) before calling the function.
On return, if errno is non-zero or
fetestexcept( FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW)
is non-zero, an error has occurred."

Thread safety requires a thread-local version of errno, which is
pretty efficient in modern implementations (e.g. an address relative to
an otherwise unused segment register on intel).

Michael S <already5chosen@yahoo.com> writes:
>On Wednesday, August 23, 2023 at 11:59:30=E2=80=AFAM UTC+3, Anton Ertl wrot=
>e:
>> In this case: So decades of register-starved architectures (IA-32,=20
>> AMD64) and architectures with very few callee-saved registers (MIPS,=20
>> Alpha) have led to applications that are tuned to use few callee-saved=20
>> registers. And then such applications are used as benchmarks that=20
>> lead architects to have few callee-saved registers. It's a vicious=20
>> circle.
>
>I hope that coding style in SpecCpu suite is mostly influenced by factors
>not related to micro-optimizations of such low-level sort.

If any performance work was done at all on these applications that
actually checked whether the changes were effective (i.e., if any
performance work was competently done), natural selection would have
steered the programmers away from programs that need many variables
that live across calls.

And after a while the programmers might learn something; probably not
the real cause, but some twisted caricature of it (e.g." "use only
seven locals, because ..." (twisted and completely nonfactual
explanation elided)), but anyway, it would steer them away from
writing programs in a way that would benefit from more callee-saved
registers. If more callee-saved registers were available on the
platforms they use, they would learn something different.

E.g., when I first explored the idea of stack caching (more than just
using TOS) in Gforth on MIPS and Alpha, I quickly found out that it
would not provide a benefit, and did not go there. However, it was
hard to swallow that these two architectures with their 31 registers
are as starved of usable registers as IA-32 with 8, so eventually I
explored the idea again on PowerPC, and there things looked much
better, so I continued.

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

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>OTOH, when most architectures were introduced, Hennessy&Patterson had
>not written CA:AQA, so maybe the architects used handwawing for these
>decisions ...

I believe the first architecture that was designed using simulations
of workloads was S/360. After they considered a lot of options
including a stack, it ended up with 16 registers. In retrospect, they
made a few mistakes (no relative branches and the botched floating
point), but having a lot of registers, and making them all usable as
both accumulators and index or base registers was a good move.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, August 23, 2023 at 12:35:18 AM UTC-5, Thomas Koenig wrote:
> EricP <ThatWould...@thevillage.com> schrieb:
> > MitchAlsup wrote:
>
> >> All of these "function calls" end up being instructions in My 66000 ISA.
> >> But, even those that are not functions take "way less code" than similar
> >> RISC-V compilations of those codes--mainly because these codes are
> >> polynomials with constant coefficients. For example r8_erf() from
> >> polpack only needs 43% as many instructions as it needs in RISC-V
> >> and when the compiler limit on constants in registers limitations are
> >> removed, better still. {and as a side note:: this is a function where
> >> RISC-V with separate GPR and FPR registers files needs spill/fill
> >> code, whereas My 66000 with integrated GPR does not--entirely du
> >> to universal constants}.
> >> <
> >> Straightforward polynomial evaluation (Horner, Estrin) only needs 6-ish
> >> registers (index, pointer, coefficient, power, product and summation)::
> >> SIN(), COS(), Ln() family, exp() family, ATAN(), and POW() all fall into
> >> this general category. I suspect many more straightforward polynomial
> >> evaluations do too.
> >
> > Even with your transcendental instructions, would not these still be
> > implemented as non-inlined subroutines? Because for different languages,
> > Fortran, C, the math functions in particular have different ways of
> > interacting with the run-time environment to report errors.
<
> C actually has no requirement of setting errno on out-of-range
> calls to mathematical functions. You can use -fno-math-errno to
> get this behavior from gcc (and, I believe, clang). Apple chose
> not to include setting errno in MacOS, and they made the right
> decision there - thread safety and vectorization make setting errno
> a performance limiter.
<
I would suggest that any/all functions taking all arguments {-Infinity
...+infinity, qNaN, and sNaN} and deliver IEEE 754-2019 compatible/
compliant results needs no errno.
>
> Anybody making a new implementation is equally free to not set
> errno on math functions, and this makes good sense on My 666000.
<
Too many 6's
<
> > Eg C/C++ math functions can set errno which is a TLS variable.
> > I don't know what GCC Fortran does for its error status reporting.
<
> Since Fortran has no errno, gfortran in effect just uses
> -fno-math-errno. Range errors are usually treated by returning NaN.

On Wednesday, August 23, 2023 at 8:54:57 AM UTC-5, Scott Lurndal wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
> >EricP <ThatWould...@thevillage.com> schrieb:
> >> MitchAlsup wrote:
> >
> >>> All of these "function calls" end up being instructions in My 66000 ISA.
> >>> But, even those that are not functions take "way less code" than similar
> >>> RISC-V compilations of those codes--mainly because these codes are
> >>> polynomials with constant coefficients. For example r8_erf() from
> >>> polpack only needs 43% as many instructions as it needs in RISC-V
> >>> and when the compiler limit on constants in registers limitations are
> >>> removed, better still. {and as a side note:: this is a function where
> >>> RISC-V with separate GPR and FPR registers files needs spill/fill
> >>> code, whereas My 66000 with integrated GPR does not--entirely du
> >>> to universal constants}.
> >>> <
> >>> Straightforward polynomial evaluation (Horner, Estrin) only needs 6-ish
> >>> registers (index, pointer, coefficient, power, product and summation)::
> >>> SIN(), COS(), Ln() family, exp() family, ATAN(), and POW() all fall into
> >>> this general category. I suspect many more straightforward polynomial
> >>> evaluations do too.
> >>
> >> Even with your transcendental instructions, would not these still be
> >> implemented as non-inlined subroutines? Because for different languages,
> >> Fortran, C, the math functions in particular have different ways of
> >> interacting with the run-time environment to report errors.
> >
> >C actually has no requirement of setting errno on out-of-range
> >calls to mathematical functions. You can use -fno-math-errno to
> >get this behavior from gcc (and, I believe, clang). Apple chose
> >not to include setting errno in MacOS, and they made the right
> >decision there - thread safety and vectorization make setting errno
> >a performance limiter.
> C doesn't. POSIX has an optional requirement to set errno.
>
> "For all the functions in the <math.h> header, an application
> wishing to check for error situations should set errno to 0 and
> call feclearexcept(FE_ALL_EXCEPT) before calling the function.
<
So, only if an instruction takes an exception (note not raises; takes)
then errno gets set. I am perfectly happy to have the math exception
handlers set errno.
<
> On return, if errno is non-zero or
> fetestexcept( FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW)
> is non-zero, an error has occurred."
<
This remains compliant since an instruction does not set errno
but when it raises an exception which is disabled, these flags are set.
>
> Thread safety requires a thread-local version of errno, which is
> pretty efficient in modern implementations (e.g. an address relative to
> an otherwise unused segment register on intel).
<
TLS eats R16 in My 66000 ABI.