Re: My 66000 and High word facility

Brett <ggtgp@yahoo.com> schrieb:

MitchAlsup1 <mitchalsup@aol.com> wrote:

Anytime one removes more "MOVs and saves and restore" instructions
than the called subroutine contains within the prologue and epilogue
bounds, the subroutine should be inlined.

In principle, yes.

You can either use C++ headers, which result in huge compilation
times, or you can use LTO.  LTO, if done right, is a huge time-eater
(I was looking for an English translation of "Zeitgrab", literarlly
"time grave" or "time tomb", this was the best I could come up with).

[...]

When HW is doing the saves, it does them in a known order and
can mark the registers "in use" or "busy" instantaneously and
clear that status as data arrives. When SW is doing the same,
SW ahs to wait for the instruction to arrive and then do them
one-to-small numbers at a time. HW is not so constrained.

>
Ok, so the hardware is smart enough.
But has anyone told the software guys?

Software guys generally work with high-level languages where this is
irrelevant, except for...

Of course convincing programmers to RTFM is futile. ;(

...people writing operating systems or drivers, and they better
read the docs for the architecture they are working on.

So we are back to finding any downsides for 64 registers in My 66000.

Encoding space.  Not sure if you have Mitch's document, but having
one more bit per register would reduce the 16-bit data in the
offset to 14 (no way you can expand that by a factor of four),
would require eight instead of one major opcodes for the three-
register instructions, amd the four-register instructions like FMA...
you get the picture.

This would not matter if we were still living in a 36-bit world,
but the days of the IBM 704, the PDP-10 or the UNIVAC 1100 have
passed, except for emulation.