Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!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: Fri, 16 Aug 2024 04:30:54 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <v9mklt$1air0$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 Aug 2024 06:30:54 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3691f3be1b8f678f5088662d65994347";
	logging-data="1395552"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18m0khf4MZGBka0H7GnLCEe"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:ifFSB8yiT/wkI+9cz+aBZNFTOe4=
	sha1:FwZjjj8LQ9Ze/427T7chZVR0jFU=
Bytes: 3968

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 8/14/2024 5:54 PM, Brett wrote:
>> Brett <ggtgp@yahoo.com> wrote:
>>> MitchAlsup1 <mitchalsup@aol.com> wrote:
>>>> On Mon, 12 Aug 2024 2:23:00 +0000, Brett wrote:
>>>> 
>>>>> BGB <cr88192@gmail.com> wrote:
>>>>>> 
>>>>> 
>>>>> Another benefit of 64 registers is more inlining removing calls.
>>>>> 
>>>>> A call can cause a significant amount of garbage code all around that
>>>>> call,
>>>>> as it splits your function and burns registers that would otherwise get
>>>>> used.
>>>> 
>>>> What I see around calls is MOV instructions grabbing arguments from the
>>>> preserved registers and putting return values in to the proper preserved
>>>> register. Inlining does get rid of these MOVs, but what else ??
>>> 
>>> For middling functions, I spent my time optimizing heavy code, the 10% that
>>> matters.
>>> 
>>> The first half of a big function will have some state that has to be
>>> reloaded after a call, or worse yet saved and reloaded.
>>> 
>>> Inlining is limited by register count, with twice the registers the
>>> compiler will generate far larger leaf calls with less call depth. Which
>>> removes more of those MOVs.
>>> 
>>>>> I can understand the reluctance to go to 6 bit register specifiers, it
>>>>> burns up your opcode space and makes encoding everything more difficult.
>>>> 
>>>> I am on record as stating the proper number of bits in an instruction-
>>>> specifier is 34-bits. This is after designing Mc88K ISA, doing 3
>>>> generations
>>>> of SPARC chips, 7 years of x86-64, and Samsung GPU (and my own efforts)
>>>> Making the registers 6-bits would increase that count to 36-bits.
>> 
>> My 66000 hurts less with 6-bits as more constants bits get moved to
>> extension words, which is almost free by most metrics.
>> 
>> Only My 66000 can reasonably be able to implement 6-bits register
>> specifiers.
>> The market is yours for the taking.
>> 
>> 6-bits will make you stand out and get noticed.
>> 
>> The only down side I see is a few percent in code density.

Actually due to the removal of MOVs and reloads the code density may be
basically the same.

> Also longer context switch times, as more registers to save/restore.

The save is should be free, as the load from ram is so slow.
If the context is time critical it should be written to use the registers
that are reloaded first, first. In which case the code could start doing
work in the same amount of time regardless of register count. (I doubt the
CPU design is actually that smart, or that the people that program the
interrupts are.)