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