Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Brett <ggtgp@yahoo.com>
Newsgroups: comp.arch
Subject: Re: My 66000 and High word facility
Date: Sat, 17 Aug 2024 20:40:55 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <v9r1sn$21mtt$1@dont-email.me>
References: <v98asi$rulo$1@dont-email.me>
 <38055f09c5d32ab77b9e3f1c7b979fb4@www.novabbs.org>
 <v991kh$vu8g$1@dont-email.me>
 <2024Aug11.163333@mips.complang.tuwien.ac.at>
 <v9b57p$2rkrq$1@dont-email.me>
 <v9brm4$33kmd$1@dont-email.me>
 <e369e386b23628e5388e95b5a92af62d@www.novabbs.org>
 <v9jij9$lk6a$1@dont-email.me>
 <v9jjjn$lofu$1@dont-email.me>
 <v9k38n$rg2a$1@dont-email.me>
 <v9mklt$1air0$1@dont-email.me>
 <1bf2c13fc41cf8aeca4a746052c03ce3@www.novabbs.org>
 <v9oqjo$1k775$1@dont-email.me>
 <v9pkdh$1r0i3$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 17 Aug 2024 22:40:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="44da523f0d83d67e9646a2e5871de716";
	logging-data="2153405"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Akw8H0C75+M5vooAiSmD9"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:piAxPRAnZE1omqfMQRFNHk2m5BU=
	sha1:zjyTGQivwMrOopad/nz/hJp6M+w=
Bytes: 4311

Thomas Koenig <tkoenig@netcologne.de> wrote:
> 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, 

Section 4.1 Instruction Template, Figure 25, page 33-179

> 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),

14 is plenty, you can actually do 12 and pack those instructions in with
shifts which have a pair of 6 bit fields, width and offset. This would
expand some constants but you make it back in shorter code with less MOVs
and more performance.

> would require eight instead of one major opcodes for the three-
> register instructions, 

Mitch gloats about how many major opcodes he has free, in his 7 bit opcode
he has the greater part of a bit free, so we are a good part of the way
there.

Conceptually some of the modifier bits move into the opcode space, not as
clean but you have to squeeze those bits hard. One can come up with a few 
patterns that are not hard to decode, and spread across several instruction
types.

> and the four-register instructions like FMA...

Trying to wave a red flag in front of Mitch. ;)

This is a pain point.
I would sacrifice most or all of XCOM6 the predicate instructions.

Does it fit or does one look at extended opcodes for FMA.

> 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.
>