Path: ...!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: Thu, 15 Aug 2024 00:54:15 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <v9jjjn$lofu$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 15 Aug 2024 02:54:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9844e6c1be8896d9ffbfc4442195ade4";
	logging-data="713214"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/zuv8SZCjHrBzEOFFOWgmG"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:+mbUdmUKwwzuffqp8+8zFBFeWVc=
	sha1:QgAsaQGYdLKUOJIAkCk8oSV4YEE=
Bytes: 3599

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.

All the customer will see is more registers, more performance, on top of
all your other substantial improvements.

>> 34-bits comes from having enough Entropy to encode what needs encoding
>> and making careful data-driven choices on "what to put in and what to
>> leave out" and finding a clever means to access vectorization and multi-
>> precision calculations. Without both of those 36-would likely be the
>> best option for the 32-register variants.