Re: My 66000 and High word facility

On 8/12/2024 8:23 PM, MitchAlsup1 wrote:

On Tue, 13 Aug 2024 0:34:55 +0000, BGB wrote:
 

On 8/12/2024 5:35 PM, MitchAlsup1 wrote:

On Mon, 12 Aug 2024 20:58:45 +0000, BGB wrote:
>

On 8/12/2024 3:12 PM, MitchAlsup1 wrote:

>

See polpak:: r8_erf()
>
>
r8_erf:                                 ; @r8_erf

<snip>

>
Why don't yuo download polpack, compile it, and state how many
instructions it takes and how many words of storage it takes ??

>
Found what I assume you are talking about.
>
Needed to add "polpak_test.c" as otherwise BGBCC lacks a main and prunes
everything;
Also needed to hack over some compiler holes related to "complex
_Double" to get it to build;
Also needed to stub over some library functions that were added in C99
but missing in my C library.

 I only ask for r8_erf()

>

<snip>
 

As for "r8_erf()":
>
<===
>
r8_erf:

<snip>
 I count 283 instructions compared to my 85 including the 104
instructions
it takes your compiler to get to the 1st instruction in My 66000 code !!
 

Yeah, this is a compiler issue...
It might have been less if the code was like:
   static const double somearr[8]={ ... };
But, this would still have used memory loads.
Getting the constants into expressions would likely require using #define or similar...
This is admittedly more how I would have imagined performance-oriented code to be written. Not so much with dynamically initialized arrays.

In the middle I see much the same problems as RISC-V has:: while you
have
the ability to poof constants, you can't use them without wasting
registers
and in general an inefficient FP instruction set {no FMAC, no sign
control
on operands, no transcendental instructions, and at least you are not as
poor of FP compare-branches as RISC-V}
 

There are a few FPU immediate cases in there, but they are a minority in the generated example...
Mostly because the compiler isn't clever enough to realize that most of the constants exist.

It is true that LLVM can unroll loops and when the loop is consuming
only
constants Brian's compiler just emits the polynomial directly with nary
a LD or ST, just constants as operands, whereas your compiler poofs
constants into existence rather than forwarding them directly into
execution. Every poof cost you an instruction, mine just cost
instruction
space not pipeline delay.
 

For the most part, BGBCC isn't clever enough to unroll loops either.
I had tried it in the past, but getting consistent results (such as not breaking stuff) and not causing code sizes to get out of control is harder (and there a lot of potential gotchas here, ...).
Well, also it is mostly incapable of inline functions.
...
But, at least luckily the code seemed mostly free of long register MOV chains, or excessive amounts of spill and fill, ...

I think this demonstrates my point perfectly--universal constants inside
a RISC instruction set is a BIG WIN.
 It also illustrates the fact that a RIOSC ISA needs a good compiler.

Will not claim that BGBCC has a particularly strong optimizer...
But, as I will note, even with this general level of lackluster code generation, have still been managing to often beat RV64G performance...
But, I guess this is weaker when RV64 is often getting its crap handed to it when facing off against 64-bit ARM.
But, seemingly, RV32IMAC and similar can seemingly mostly hold their ground in terms of performance when compared with Thumb and Thumb2, though Thumb and Thumb2 still hold the code-density crown.