Sujet : Re: My 66000 and High word facility
De : tkoenig (at) *nospam* netcologne.de (Thomas Koenig)
Groupes : comp.archDate : 17. Aug 2024, 23:05:03
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v9r6qf$22f31$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : slrn/1.0.3 (Linux)
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.