On 10/30/2023 8:36 AM, Scott Lurndal wrote:
> JimBrakefield <jim.brakefield@ieee.org> writes:
>> On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
>> wrote:
>>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
>> rote:=20
>>>> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
>>>>> I came late to this party, but I wanted to comment on a couple of thi=
>> ngs I saw:=20
>>>>> =20
>>>>> 1) An out of order (very) CISC stack machine was built and sold (usin=
>> g MECL III logic) 30 years ago.=20
>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a=
>> single "operation" and have=20
>>>>> up to 6 of them working in parallel. Unfortunately, the memory interf=
>> ace couldn't keep up with=20
>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs=
>> ).=20
>>>> I vaguely remember the A19, but I can't find any information on it=20
>>>> online. No mention in the Wikipedia article on Burroughs large scale=20
>>>> systems, nothing at bitsavers, etc. Do you know of any links for more=
>> =20
>>>> information?
>>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
>> fter the merger, so it was never a "Burroughs" system.=20
>>> =20
>>> From Bloomberg:=20
>>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
>> eaves-big-blue-in-the-dust=20
>>> =20
>>> "A mainframe processor due from Unisys Corp. late this year will employ a=
>> relatively new internal design that may give the struggling computer maker=
>> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
>> ques from scientific computers to execute many instructions concurrently. T=
>> he A19 can overlap as many as 140 operations, more than 10 times as many as=
>> conventional mainframes can."=20
>>> =20
>>> - Tim=20
>>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
>>> (And Unisys sold quite a few of them IIRC).
>>
>>
>> James Brakefield <jim.brakefield@ieee.org>
>> 9:59=E2=80=AFPM (24 minutes ago)
>> to comp.arch
>>
>> |>
>> |>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
>> after the merger, so it was never a "Burroughs" system.
>>
>>From looking at some of the manuals, appears to be a 36-bit word size,
>
> You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
> had a 36-bit word.
>
> All the burroughs large systems (B[567]xxx and A-series) had 48-bit
> words, dating back to the B5000/B5500 in the early 1960s.
>
> V-series was BCD, addressed to the nibble.

Not much comment on this, but this post (and a few others) does point
out something to me:
It seems recently, haven't been seeing any new posts from either Jim
Brakefield or Mitch Alsup...

It seems they have been posting, but their posts don't show up in my
newsreader.

I am using eternal-september and Thunderbird, no relevant filters in
place (apart from ones related to "ramdane" and ones for the various
thai characters to deal with the recent spam).

....

BGB <cr88192@gmail.com> writes:
>On 10/30/2023 8:36 AM, Scott Lurndal wrote:
>> JimBrakefield <jim.brakefield@ieee.org> writes:
>>> On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
>>> wrote:
>>>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
>>> rote:=20
>>>>> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
>>>>>> I came late to this party, but I wanted to comment on a couple of thi=
>>> ngs I saw:=20
>>>>>> =20
>>>>>> 1) An out of order (very) CISC stack machine was built and sold (usin=
>>> g MECL III logic) 30 years ago.=20
>>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a=
>>> single "operation" and have=20
>>>>>> up to 6 of them working in parallel. Unfortunately, the memory interf=
>>> ace couldn't keep up with=20
>>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs=
>>> ).=20
>>>>> I vaguely remember the A19, but I can't find any information on it=20
>>>>> online. No mention in the Wikipedia article on Burroughs large scale=20
>>>>> systems, nothing at bitsavers, etc. Do you know of any links for more=
>>> =20
>>>>> information?
>>>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
>>> fter the merger, so it was never a "Burroughs" system.=20
>>>> =20
>>>> From Bloomberg:=20
>>>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
>>> eaves-big-blue-in-the-dust=20
>>>> =20
>>>> "A mainframe processor due from Unisys Corp. late this year will employ a=
>>> relatively new internal design that may give the struggling computer maker=
>>> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
>>> ques from scientific computers to execute many instructions concurrently. T=
>>> he A19 can overlap as many as 140 operations, more than 10 times as many as=
>>> conventional mainframes can."=20
>>>> =20
>>>> - Tim=20
>>>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
>>>> (And Unisys sold quite a few of them IIRC).
>>>
>>>
>>> James Brakefield <jim.brakefield@ieee.org>
>>> 9:59=E2=80=AFPM (24 minutes ago)
>>> to comp.arch
>>>
>>> |>
>>> |>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
>>> after the merger, so it was never a "Burroughs" system.
>>>
>>>From looking at some of the manuals, appears to be a 36-bit word size,
>>
>> You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
>> had a 36-bit word.
>>
>> All the burroughs large systems (B[567]xxx and A-series) had 48-bit
>> words, dating back to the B5000/B5500 in the early 1960s.
>>
>> V-series was BCD, addressed to the nibble.
>
>
>Not much comment on this, but this post (and a few others) does point
>out something to me:
>It seems recently, haven't been seeing any new posts from either Jim
>Brakefield or Mitch Alsup...
>
>It seems they have been posting, but their posts don't show up in my
>newsreader.

I believe eternal-september was agressively filtering posts from GG.

On 10/30/23 12:40 PM, EricP wrote:
> Oh look... the denial of service attackers have started taking
> subject lines from real messages, making it even harder to filter.
> I noticed they switched from Thai sender names
> to ascii western ones to make filtering harder.
>
Worse, it is a reply to a the message in this thread.

As for names, I kept expecting to see "John Bigboote"

--
http://davesrocketworks.com
David Schultz

On 10/30/2023 12:56 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 10/30/2023 8:36 AM, Scott Lurndal wrote:
>>> JimBrakefield <jim.brakefield@ieee.org> writes:
>>>> On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
>>>> wrote:
>>>>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
>>>> rote:=20
>>>>>> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
>>>>>>> I came late to this party, but I wanted to comment on a couple of thi=
>>>> ngs I saw:=20
>>>>>>> =20
>>>>>>> 1) An out of order (very) CISC stack machine was built and sold (usin=
>>>> g MECL III logic) 30 years ago.=20
>>>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a=
>>>> single "operation" and have=20
>>>>>>> up to 6 of them working in parallel. Unfortunately, the memory interf=
>>>> ace couldn't keep up with=20
>>>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs=
>>>> ).=20
>>>>>> I vaguely remember the A19, but I can't find any information on it=20
>>>>>> online. No mention in the Wikipedia article on Burroughs large scale=20
>>>>>> systems, nothing at bitsavers, etc. Do you know of any links for more=
>>>> =20
>>>>>> information?
>>>>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
>>>> fter the merger, so it was never a "Burroughs" system.=20
>>>>> =20
>>>>> From Bloomberg:=20
>>>>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
>>>> eaves-big-blue-in-the-dust=20
>>>>> =20
>>>>> "A mainframe processor due from Unisys Corp. late this year will employ a=
>>>> relatively new internal design that may give the struggling computer maker=
>>>> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
>>>> ques from scientific computers to execute many instructions concurrently. T=
>>>> he A19 can overlap as many as 140 operations, more than 10 times as many as=
>>>> conventional mainframes can."=20
>>>>> =20
>>>>> - Tim=20
>>>>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
>>>>> (And Unisys sold quite a few of them IIRC).
>>>>
>>>>
>>>> James Brakefield <jim.brakefield@ieee.org>
>>>> 9:59=E2=80=AFPM (24 minutes ago)
>>>> to comp.arch
>>>>
>>>> |>
>>>> |>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
>>>> after the merger, so it was never a "Burroughs" system.
>>>>
>>> >From looking at some of the manuals, appears to be a 36-bit word size,
>>>
>>> You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
>>> had a 36-bit word.
>>>
>>> All the burroughs large systems (B[567]xxx and A-series) had 48-bit
>>> words, dating back to the B5000/B5500 in the early 1960s.
>>>
>>> V-series was BCD, addressed to the nibble.
>>
>>
>> Not much comment on this, but this post (and a few others) does point
>> out something to me:
>> It seems recently, haven't been seeing any new posts from either Jim
>> Brakefield or Mitch Alsup...
>>
>> It seems they have been posting, but their posts don't show up in my
>> newsreader.
>
> I believe eternal-september was agressively filtering posts from GG.
>

Yeah.

This newsgroup has now been pretty quiet recently on my end.
Seemingly only posts from you, David Brown, and EricP, are the only
recent posts I have seen within the past few days...

A few other posters on 10/27 and 10/28, but it appears mostly as-if
"everything mostly went quiet" some time around 10/26 (and some of the
more recent posts have been to posts I have not seen).

On Monday, October 30, 2023 at 12:25:09 PM UTC-5, BGB wrote:
> On 10/30/2023 8:36 AM, Scott Lurndal wrote:
> > JimBrakefield <jim.bra...@ieee.org> writes:
> >> On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
> >> wrote:
> >>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
> >> rote:=20
> >>>> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
> >>>>> I came late to this party, but I wanted to comment on a couple of thi=
> >> ngs I saw:=20
> >>>>> =20
> >>>>> 1) An out of order (very) CISC stack machine was built and sold (usin=
> >> g MECL III logic) 30 years ago.=20
> >>>>> It was called the Unisys A19. It could fuse up to 6 operations into a=
> >> single "operation" and have=20
> >>>>> up to 6 of them working in parallel. Unfortunately, the memory interf=
> >> ace couldn't keep up with=20
> >>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs=
> >> ).=20
> >>>> I vaguely remember the A19, but I can't find any information on it=20
> >>>> online. No mention in the Wikipedia article on Burroughs large scale=20
> >>>> systems, nothing at bitsavers, etc. Do you know of any links for more=
> >> =20
> >>>> information?
> >>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
> >> fter the merger, so it was never a "Burroughs" system.=20
> >>> =20
> >>> From Bloomberg:=20
> >>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
> >> eaves-big-blue-in-the-dust=20
> >>> =20
> >>> "A mainframe processor due from Unisys Corp. late this year will employ a=
> >> relatively new internal design that may give the struggling computer maker=
> >> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
> >> ques from scientific computers to execute many instructions concurrently. T=
> >> he A19 can overlap as many as 140 operations, more than 10 times as many as=
> >> conventional mainframes can."=20
> >>> =20
> >>> - Tim=20
> >>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
> >>> (And Unisys sold quite a few of them IIRC).
> >>
> >>
> >> James Brakefield <jim.bra...@ieee.org>
> >> 9:59=E2=80=AFPM (24 minutes ago)
> >> to comp.arch
> >>
> >> |>
> >> |>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
> >> after the merger, so it was never a "Burroughs" system.
> >>
> >>From looking at some of the manuals, appears to be a 36-bit word size,
> >
> > You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
> > had a 36-bit word.
> >
> > All the burroughs large systems (B[567]xxx and A-series) had 48-bit
> > words, dating back to the B5000/B5500 in the early 1960s.
> >
> > V-series was BCD, addressed to the nibble.
> Not much comment on this, but this post (and a few others) does point
> out something to me:
> It seems recently, haven't been seeing any new posts from either Jim
> Brakefield or Mitch Alsup...
>
> It seems they have been posting, but their posts don't show up in my
> newsreader.
>
> I am using eternal-september and Thunderbird, no relevant filters in
> place (apart from ones related to "ramdane" and ones for the various
> thai characters to deal with the recent spam).
>
> ...

|>
|>new posts from either Jim Brakefield

https://github.com/jimbrake/ROC32_8/blob/main/ROCnn_32_231022.docx
is what I'm working on. However not getting much done. See page three.
Also, FWIIW giving a talk on floating point:
https://events.vtools.ieee.org/m/381287 which should be available as a webinar

On 10/30/2023 1:25 PM, JimBrakefield wrote:
> On Monday, October 30, 2023 at 12:25:09 PM UTC-5, BGB wrote:
>> On 10/30/2023 8:36 AM, Scott Lurndal wrote:
>>> JimBrakefield <jim.bra...@ieee.org> writes:
>>>> On Sunday, October 29, 2023 at 7:42:15=E2=80=AFPM UTC-5, Timothy McCaffrey =
>>>> wrote:
>>>>> On Thursday, October 26, 2023 at 2:05:49=E2=80=AFPM UTC-4, Stephen Fuld w=
>>>> rote:=20
>>>>>> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:=20
>>>>>>> I came late to this party, but I wanted to comment on a couple of thi=
>>>> ngs I saw:=20
>>>>>>> =20
>>>>>>> 1) An out of order (very) CISC stack machine was built and sold (usin=
>>>> g MECL III logic) 30 years ago.=20
>>>>>>> It was called the Unisys A19. It could fuse up to 6 operations into a=
>>>> single "operation" and have=20
>>>>>>> up to 6 of them working in parallel. Unfortunately, the memory interf=
>>>> ace couldn't keep up with=20
>>>>>>> the CPU execution rate. (And you could configure it with up to 6 CPUs=
>>>> ).=20
>>>>>> I vaguely remember the A19, but I can't find any information on it=20
>>>>>> online. No mention in the Wikipedia article on Burroughs large scale=20
>>>>>> systems, nothing at bitsavers, etc. Do you know of any links for more=
>>>> =20
>>>>>> information?
>>>>> If you put "Unisys A19" into Google you get a lot. It was built 5 years a=
>>>> fter the merger, so it was never a "Burroughs" system.=20
>>>>> =20
>>>>> From Bloomberg:=20
>>>>> https://www.bloomberg.com/news/articles/1991-03-24/unisys-new-mainframe-l=
>>>> eaves-big-blue-in-the-dust=20
>>>>> =20
>>>>> "A mainframe processor due from Unisys Corp. late this year will employ a=
>>>> relatively new internal design that may give the struggling computer maker=
>>>> a much-needed shot in the arm. The new A19 relies on "super-scalar" techni=
>>>> ques from scientific computers to execute many instructions concurrently. T=
>>>> he A19 can overlap as many as 140 operations, more than 10 times as many as=
>>>> conventional mainframes can."=20
>>>>> =20
>>>>> - Tim=20
>>>>> (So, I may have gotten the concurrency numbers a bit wrong....)=20
>>>>> (And Unisys sold quite a few of them IIRC).
>>>>
>>>>
>>>> James Brakefield <jim.bra...@ieee.org>
>>>> 9:59=E2=80=AFPM (24 minutes ago)
>>>> to comp.arch
>>>>
>>>> |>
>>>> |>If you put "Unisys A19" into Google you get a lot. It was built 5 years =
>>>> after the merger, so it was never a "Burroughs" system.
>>>>
>>> >From looking at some of the manuals, appears to be a 36-bit word size,
>>>
>>> You found the wrong manuals, I think. The sperry/Unisys 1100/2200 systems
>>> had a 36-bit word.
>>>
>>> All the burroughs large systems (B[567]xxx and A-series) had 48-bit
>>> words, dating back to the B5000/B5500 in the early 1960s.
>>>
>>> V-series was BCD, addressed to the nibble.
>> Not much comment on this, but this post (and a few others) does point
>> out something to me:
>> It seems recently, haven't been seeing any new posts from either Jim
>> Brakefield or Mitch Alsup...
>>
>> It seems they have been posting, but their posts don't show up in my
>> newsreader.
>>
>> I am using eternal-september and Thunderbird, no relevant filters in
>> place (apart from ones related to "ramdane" and ones for the various
>> thai characters to deal with the recent spam).
>>
>> ...
>
> |>
> |>new posts from either Jim Brakefield
>
> https://github.com/jimbrake/ROC32_8/blob/main/ROCnn_32_231022.docx
> is what I'm working on. However not getting much done. See page three.
> Also, FWIIW giving a talk on floating point:
> https://events.vtools.ieee.org/m/381287 which should be available as a webinar

OK, I see this one...

I had thought I had seen Scott responding to a message I did not see...

Along with other instances where it looked like David Brown may have
been responding to messages I didn't see.

On Wed, 25 Oct 2023 04:05:35 -0700, Quadibloc wrote:

> I came up with an alternative that satisfied all the desiderata. Of
> course, it was pure evil, but that hadn't stopped me before...
>
> (0)
> (First 7 bits of first instruction)
> (0)
> (First 7 bits of second instruction)
> (Remaining 8 bits of first instruction)
> (Remaining 8 bits of second instruction)
>
> was the new format of a pair of 16-bit instructions in a 32-bit word.
> Only in the default case - whenever a header is present, indicating a
> pair of 16-bit instructions with some special feature in in a 32-bit
> word, then they're conventionally in the two contiguous 16-bit halves of
> that word.

However, while this sort of worked, I still really, really didn't like
encoding pairs of 16-bit instructions within a 32-bit instruction slot
in that fashion.

A light dawned, and I found a way to avoid it. The aligned load-store
instructions, except for the ones acting on byte operands, have one or
more fixed bits at the end of the 16-bit address field indicating the
length of the operand.

I could move the last bit of *that* to another portion of the instruction,
so as to move the remaining 15 bits of the address field one position to
the left, and then I could put _those_ instructions in the opcode space
which lacks a contiguous 16-bit span at the end in the case where the
16-bit instructions keep their conventional format!

Finally, happiness at last!

John Savard

On Mon, 30 Oct 2023 20:44:27 +0000, Quadibloc wrote:
> However, while this sort of worked, I still really, really didn't like
> encoding pairs of 16-bit instructions within a 32-bit instruction slot
> in that fashion.

One mistake I had to correct: now, there is a lot less opcode space
available for headers, so I had to change the header format, not merely
go back to the earlier one.

John Savard

On Thursday, October 26, 2023 at 2:05:49 PM UTC-4, Stephen Fuld wrote:
> On 10/26/2023 8:24 AM, Timothy McCaffrey wrote:

> > 3) If I ever had the spare (hah!) time to work on my own ISA, I think I would start with a "fat" encoding
> > of all the instructions (i.e. fixed length, easy to write an emulator for, etc.).
> But doesn't even that effectively "specify" some things about your ISA?
> Specifically, does it include two register specifiers or three? Is it a
> stack ISA (I put this in to warm your heart!), does fixed length rule
> out handling immediates like Mitch's My66000 does?

Well, ok, I suspect that my copious spare time architecture (CSTA :) ) would probably be
64 bit, 2s complement, byte addressable, word alignment not required, strong memory ordering (e.g. x86).
Likely to be some kind of register based arch, not really a big expression stack fan.
Everything else is stuff I would play with.

I have some ideas, but who knows which ones are any good?

> > Write the compiler, analyze the output,
> While this is very useful, it is very dependent on what program set you
> choose to compile. For example, do you expect "commercial" workloads to
> be important? Does the importance of scientific workloads justify
> instructions for transcendental functions? What about 128 bit floating
> point? It also doesn't directly help with things like address range, etc.

I wouldn't choose one workload.
Again, I would probably approach this incrementally.
The one thing everybody needs to be fast is the OS.
So, there are lots of gnarly little decisions that affect how efficient the OS is (Mitch has been trying to address that).
From efficient handling of interrupts (external) and exceptions/faults (internal), user/kernel state transitions, task/state switching, etc., etc.
There are also things I would like to see in an architecture, like user level accessible per-thread timers/counters and other features
that would allow the OS and/or user program to provide better security, auditing, etc.

After that, I would probably look at making the compiler run efficiently, because it is pretty representative of generic branchy code.

After that, I guess I would try to see what could be made faster (graphics, AI/neural net, HPC, etc)

100 years from now I should have an architecture that would have been great if it showed up 10 years ago :).

> > add/subtract instructions as required, and repeat.
> > When the ISA feature set had stabilized, THEN I would worry about the actual encoding.
> Agreed. You have to make some other basic decisions first.
>
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Mon, 30 Oct 2023 21:24:22 +0000, Quadibloc wrote:

> One mistake I had to correct: now, there is a lot less opcode space
> available for headers, so I had to change the header format, not merely
> go back to the earlier one.

Originally, I only modified the diagram of the header format. Now I
have also updated the text description of the header format on the
first page,

http://www.quadibloc.com/arch/ct17int.htm

John Savard

On Tue, 31 Oct 2023 03:36:56 +0000, Quadibloc wrote:

> Originally, I only modified the diagram of the header format. Now I have
> also updated the text description of the header format on the first
> page,

Another result of this latest round of changes is that the squeeze
on opcode space finally forced me to drop the "displaced instruction
header", which was that special header format I referred to earlier
which allowed a decode field to be indicated with essentially zero
overhead, by having a type of header which contained...

the decode field, required to allow pseudo-immediates, and
a position field, so that the instruction contained in this type of
header can be put between any two instruction slots in the remainder of
the block, and
an instruction.

The idea was to have eight 32-bit instructions in a block, and yet to
also have a decode field for pseudo-immediates.

John Savard

On Tue, 31 Oct 2023 03:56:47 +0000, Quadibloc wrote:

> Another result of this latest round of changes is that the squeeze on
> opcode space finally forced me to drop the "displaced instruction
> header",

That has been put back; now it's described with the header format,
instead of on the page on instruction formats, due to where I found the
opcode space for it.

However, now, not only is there no room for alternative condition code
sets, the opcode field is only seven bits long, so only the most basic
operate instructions may be inserted with immediates in this zero-overhead
fashion. None the less, that is better than not having this way to
have pseudo-immediates without the overhead of reserving 32 bits for
a header.

John Savard

On Friday, March 3, 2023 at 8:42:51 AM UTC-7, MitchAlsup wrote:

> I feel that you are frustrated that you can't have your cake and eat it too.

Very definitely. So I have gone to a great deal of effort to squeeze the
opcode space so as to minimize the unavoidable compromises that come
from trying to have a full set of CISC addressing modes, plus banks of 32
registers as in a RISC architecture, with 32-bit instructions.

The reasons why I use block headers:

- to allow switching from the plain RISC decoding of every single instruction
being exactly 32 bits long to allowing use of variable-length encodings while
still allowing instructions to be decoded in parallel (just decode the header
first, and you _immediately_ know where every instruction in the block is;

Yes, I know that it's possible to decode variable-length instructions quickly
enough so that the benefits of this may be illusory;

- to allow immediate values to be used of every type and size without that
burdening the scheme for decoding the lengths of instructions with excessive
complexity.

Now, the point you made about a header being optimum for one implementation
is certainly a concern to me. I did believe that this was perhaps the greatest flaw
in the Itanium.

However, while the header format is indeed complicated, it still avoids one aspect
of the complexity of the Itanium. The block format is still simple like that of the
Texas Instruments DSP chips - all the instructions, except for the header, are the
same in any block.

So the ISA is still capable of a wide variety of implementations. It does not have
to be implemented in an 8-wide fashion. It can be implemented on a chip that
fetches and decodes 32 instruction bits at a time, or one that fetches and decodes
128 bits at a time.

Or 512 bits at a time, although there provision has to be made for imposing serialization
between the two halves.

My goal has very definitely been to design an ISA that permits implementations
in a wide variety of sizes, just like the IBM System/360. I don't achieve this quite as
well, but then the smaller sizes aren't used as much these days.

John Savard