Path: ...!weretis.net!feeder8.news.weretis.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: Sun, 11 Aug 2024 00:46:09 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <v991kh$vu8g$1@dont-email.me>
References: <v98asi$rulo$1@dont-email.me>
 <38055f09c5d32ab77b9e3f1c7b979fb4@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 Aug 2024 02:46:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5a4148bcb356f4e3fa048bfa129f7c8d";
	logging-data="1046800"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/TYYQ/UDYOsEO2WjSy7okH"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:UXFvC59671nZ74QTTJr/sFPSM3A=
	sha1:G1F3DTQQHH5r8dGpyNUIC+2a8Sk=
Bytes: 3937

MitchAlsup1 <mitchalsup@aol.com> wrote:
> On Sat, 10 Aug 2024 18:17:54 +0000, Brett wrote:
> 
>> 
>> My 66000 should look into the z/architecture High Word Facility as that
>> would give you another 65% more registers or so. You have the opcode
>> space and it is Another nice boost for some customers.
> 
> The article posted by Andy Glew was luke-warm at best. Now, while
> IBM has figured out that 16 GPRs is insufficient, there is scant
> data that 32 are insufficient {witness how few RISCs went with
> bigger files}
> 
> Since My 66000 is a 64-bit architecture with a modicum of support for
> 8-bit, 16-bit, and 32-bit stuff; and since 32-truely GPRs seems to be
> enough (compiler output), I think I will pass.
> 
> Due to significant access to constants, My 66000 with only 32-actual
> registers performs as well as RISC-V does with 32I+32F in most codes,
> so there does not seem to be an insufficient number of registers. I
> even have ASM examples where RISC-V runs out of registers where My
> 66000 does not !! Not wasting register to hold onto big immediates,
> big displacements, or big addresses goes a long way to thinning out
> the register count necessities.
> 
> In My 66000 one can utilize all 32 registers, with 0 reserved for
> {linking, splicing, GOT access,...} these "effective constants"
> become actual constants meaning one does not have to consume a
> register to have access through that constant address value.

These are excellent points and need to be in your marketing information.

Compilers love unrolling loops because it saves an instruction, which for a
short loop could mean 10% faster. Point out your code has more unrolls and
performance.

I don’t know if you are in the 14 gate delay market that makes high
registers a fail. Can’t find Andy Glew’s article on z/arch, but that arch
has limited opcode space that imposes constraints, you don’t.

High registers is mostly marketing vapor ware extension for you, see if
anyone cares and put them on a list for when a market for that extension
pops up.

The lack of CPU’s with 64 registers is what makes for a market, that 4%
that could benefit have no options to pick from. You would be happy to have
control of a market that big. Point customers at a compiler configured for
64 registers and say that with high registers and inline constants that is
what they could expect for code generation.

If there is demand for high registers you will probably just spin a CPU
arch with more registers, but that will never happen if you never ask. This
is the definition of vapor ware, a free market survey. You can even add
more registers as an incompatible extension, if fact you should.

>> IBM supports Linux, so the compiler support should exist. X86 solved the
>> aliasing issue with finer tracking.
> 
> Neither of which would worry me.
> 
>> 
>> Thanks,
>> Brett
>