Sujet : Re: Why I've Dropped In
De : quadibloc (at) *nospam* gmail.com (quadibloc)
Groupes : comp.archDate : 11. Jun 2025, 18:34:54
Autres entêtes
Organisation : novaBBS
Message-ID : <bc81734a4df49aeb8c7e11c2ca5e99e4@www.novabbs.com>
References : 1 2 3 4 5 6 7
User-Agent : Rocksolid Light
On Wed, 11 Jun 2025 16:49:06 +0000, MitchAlsup1 wrote:
On Wed, 11 Jun 2025 14:12:04 +0000, quadibloc wrote:
Therefore, I reduced the index register and base register fields to
three bits each, using only some of the 32 integer registers for those
purposes.
This is going to hurt register allocation.
Yes. It will. Unfortunately.
Basically, as should be apparent by now, my overriding goal in defining
the Concertina II architecture - and its predecessor as well - was to
make it "just as good", or at least "just _about_ as good", as both the
68020 and the IBM System/360.
This meant that I had to be able to fit base plus index plus
displacement into 32 bits, since the System/360 did that, and I had to
have 16-bit displacements because the 68020, and indeed x86 and most
microprocessors did that.
And I had to have register-to-register operate instructions that fit
into only 16 bits. Because the System/360 had them, and indeed so do
many microprocessors.
Otherwise, my ISA would be clearly and demonstrably inferior. Where I
couldn't attain a full match, I tried to be at least "almost" as good.
So either my 16-bit operate instructions have to come in pairs, and have
a very restricted set of operations, or they require the overhead of a
block header. I couldn't attain the goal of matching the S/360
completely, but at least I stayed close.
So while having 32 registers like a RISC, I ended up having some
purposes for which I could only use a set of eight registers. Not great,
but it was the tradeoff that was left to me given the choice I made.
So here it is - an ISA that offers RISC-like simplicity of decoding, but
an instruction set that approaches CISC in code compactness - and which
offers a choice of RISC, CISC, or VLIW programming styles. Which may
lead to VLIW speed and efficiency on suitable implementations.
John Savard