Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: My 66000 and High word facility
Date: Sat, 17 Aug 2024 22:05:03 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <v9r6qf$22f31$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>
 <v9r1sn$21mtt$1@dont-email.me>
Injection-Date: Sun, 18 Aug 2024 00:05:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0f2c0b1d7192356798dc70471fe96c6c";
	logging-data="2178145"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+yjOie94w91mWMiK9T9H+BNV+OI4sW20U="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:e14PxozfVnryT2ZznnrdxyvVlC8=
Bytes: 4469

Brett <ggtgp@yahoo.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Brett <ggtgp@yahoo.com> schrieb:

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

16 is better.

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

Hmm... I am not convinced.

Do you have code to back up your claims?

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

It's 6 for the major opcode, actually.

> he has the greater part of a bit free, so we are a good part of the way
> there.

That sentence no parse.

> Conceptually some of the modifier bits move into the opcode space, not as
> clean but you have to squeeze those bits hard

It is very fine point of semantics if the modifier bits are part
of the opcode space or not.  I happen to think that they are,
they are just in a (somehwat) different place and spelled a bit
differently, but it does not really matter how you look at it -
you need the bits to encode them.

> One can come up with a few 
> patterns that are not hard to decode, and spread across several instruction
> types.

So, go right ahead.  Find an encoding that a) encompasses all of
Mitch's functionality, b) has six bits for registers everywhere,
and c) does not drive the assembler writer crazy (that's me,
for Mitch's design) or hardware designer bonkers (where Mitch has
the experience).

Let's start with the... BB1 instruction, which branches on bit
set in a register, so it needs a major opcode, a bit number, a
register number and a displacement.  How do you propose to do that?
Shave one bit off the displacement?

>
>> and the four-register instructions like FMA...
>
> Trying to wave a red flag in front of Mitch. ;)

I just happen to like FMA :-)

Of course, it might be possible to code FMA like AVX does, with
only three registers - 18 bits for three registers, plus two bits
for which one of them gets smashed for the result.

But - just making offhand suggestions won't cut it.  You will
have to think about the layout of the instructions, how everything
fits in, and needing one to four more bits per instruction
can be accomodated.