On Thursday, March 16, 2023 at 8:36:37 PM UTC-6, Quadibloc wrote:

> Of course, though, the only "rational" reason I can *really* think of for
> having this feature is that it would make porting of programs written
> for the PowerPC simpler

This is definitely a good reason for dropping this feature, because it
has one important cost: it increases the size of the machine state,
which gets saved on every interrupt. Just because there are some bits
available doesn't mean I need to use them for something right away...

In any case, after doing some more slight tweaks, one thing about this
ISA came to my attention. Yes, it's definitely not orthogonal, to a degree
that would seem to make writing a compiler for it a nightmare.

But one thing that has really been a part of the design all along should
be noted: the design does have multiple orthogonal _subsets_. So there
are features that aren't available in all addressing modes. One can choose
to do without the addressing modes in which it isn't available, or one can
do without the feature, and in either case, what remains is orthogonal.

One instruction set. That fits into the available opcode space. And that offers
a seemingly-impossible degree of versatility.

John Savard

On Thursday, March 16, 2023 at 9:36:37 PM UTC-5, Quadibloc wrote:
> On Thursday, March 16, 2023 at 8:41:04 AM UTC-6, Quadibloc wrote:
> > On Thursday, March 16, 2023 at 7:43:58 AM UTC-6, Quadibloc wrote:
> >
> > > But in addition, for operate instructions, three of those five bits indicate
> > > *one of eight sets of condition codes* - after all, if the PowerPC ISA
> > > found this feature useful, presumably that means it must be worthwhile
> > > to have!
> >
> > I have now added a very few instruction formats which support these
> > alternate condition code bits in the regular instruction set as well. Most
> > importantly, there is now a 32-bit version of the _Set Flag_ instruction
> > which also supports the alternate condition code bits, so that full use
> > can be made of the fact that there are *both* eight sets of condition
> > code bits *and* sixteen flag bits that can be used for instruction
> > predication - so that, if required, the results of twenty-four instructions
> > can be in flight at one time and used for determining the subsequent
> > flow of control.
> >
> Of course, though, the only "rational" reason I can *really* think of for
> having this feature is that it would make porting of programs written
> for the PowerPC simpler - just as having System/360 style string and
> packed decimal memory to memory operations (and there will also be
> floating point operations on that alrchitecture's floating-point type) make
> conversion of programs from that architecture simpler.
<
Just how are System 360's string handling usefully better than the
string and memory library found in C ???
<
Also, why would anyone want to go back to System 360 Floating Point ??
>
> John Savard

On Friday, March 17, 2023 at 11:04:09 AM UTC-6, MitchAlsup wrote:

> Just how are System 360's string handling usefully better than the
> string and memory library found in C ???

I think that compares apples with oranges. Machine instructions don't
replace subroutines.

> Also, why would anyone want to go back to System 360 Floating Point ??

The architecture supports IEEE 754 as its primary floating-point type, so
people aren't being asked to "go back to" what is obviously an inferior
floating-point type.

A great deal of software has been written for IBM System/360 computers.

Directly supporting the functionality of System/360 instructions in hardware
allows programs similar to Hercules to run faster. And having all this hardware
on the chip, of course, suggests going even further in emulation support.

John Savard

On 3/17/2023 10:34 AM, Quadibloc wrote:
> On Friday, March 17, 2023 at 11:04:09 AM UTC-6, MitchAlsup wrote:
>
>> Just how are System 360's string handling usefully better than the
>> string and memory library found in C ???
>
> I think that compares apples with oranges. Machine instructions don't
> replace subroutines.

Sure they can. On S/360, I expect the C compiler would emit a MVC
instruction for the Memmove subroutine, and probably inline the
instruction rather than call a subroutine.

>> Also, why would anyone want to go back to System 360 Floating Point ??
>
> The architecture supports IEEE 754 as its primary floating-point type, so
> people aren't being asked to "go back to" what is obviously an inferior
> floating-point type.
>
> A great deal of software has been written for IBM System/360 computers.

Sure, but given that IBM supports this software with its processors, why
would a potential customer choose your chip, which would probably run
the software slower than a current IBM chip, and because of all the
extra silicon devoted to non-S/360 stuff, probably cost more?

>
> Directly supporting the functionality of System/360 instructions in hardware
> allows programs similar to Hercules to run faster. And having all this hardware
> on the chip, of course, suggests going even further in emulation support.

OK, so let's say you can directly execute every S/360 instruction.
Again, why would someone choose your chip over IBMs?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Friday, March 17, 2023 at 12:34:24 PM UTC-5, Quadibloc wrote:
> On Friday, March 17, 2023 at 11:04:09 AM UTC-6, MitchAlsup wrote:
>
> > Just how are System 360's string handling usefully better than the
> > string and memory library found in C ???
<
> I think that compares apples with oranges. Machine instructions don't
> replace subroutines.
<
My point was and is that modern applications have been using C's str*
library for 3-4 decades, and the porting pool of applications is strongly
in the camp of using those libraries and not (so much) using System 360
notions of strings (fixed length, 255 character maximum, ...).
<
> > Also, why would anyone want to go back to System 360 Floating Point ??
> The architecture supports IEEE 754 as its primary floating-point type, so
> people aren't being asked to "go back to" what is obviously an inferior
> floating-point type.
>
> A great deal of software has been written for IBM System/360 computers.
<
Almost none of it using System 360 floating point -- that has not been ported
already to IEEE 754.
>
> Directly supporting the functionality of System/360 instructions in hardware
> allows programs similar to Hercules to run faster. And having all this hardware
> on the chip, of course, suggests going even further in emulation support.
<
Ha ha ha ha ha ha ha <catch breath> maybe you do stand up comedy.
>
> John Savard

On Friday, March 17, 2023 at 3:06:46 PM UTC-5, Stephen Fuld wrote:
> On 3/17/2023 10:34 AM, Quadibloc wrote:
> > On Friday, March 17, 2023 at 11:04:09 AM UTC-6, MitchAlsup wrote:
> >
> >> Just how are System 360's string handling usefully better than the
> >> string and memory library found in C ???
> >
> > I think that compares apples with oranges. Machine instructions don't
> > replace subroutines.
<
> Sure they can. On S/360, I expect the C compiler would emit a MVC
> instruction for the Memmove subroutine, and probably inline the
> instruction rather than call a subroutine.
<
Brian's compiler already does.
<
> >> Also, why would anyone want to go back to System 360 Floating Point ??
> >
> > The architecture supports IEEE 754 as its primary floating-point type, so
> > people aren't being asked to "go back to" what is obviously an inferior
> > floating-point type.
> >
> > A great deal of software has been written for IBM System/360 computers.
<
> Sure, but given that IBM supports this software with its processors, why
> would a potential customer choose your chip, which would probably run
> the software slower than a current IBM chip, and because of all the
> extra silicon devoted to non-S/360 stuff, probably cost more?
> >
> > Directly supporting the functionality of System/360 instructions in hardware
> > allows programs similar to Hercules to run faster. And having all this hardware
> > on the chip, of course, suggests going even further in emulation support.
<
> OK, so let's say you can directly execute every S/360 instruction.
> Again, why would someone choose your chip over IBMs?
>
Are you going to have a "fix it person" on call who answers the phone at 4:15 AM
like the IBM repair guy ?? and can arrive in 15 minutes ?? If not, then who is going
to buy your chip ??
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

MitchAlsup <MitchAlsup@aol.com> writes:
>On Friday, March 17, 2023 at 12:34:24=E2=80=AFPM UTC-5, Quadibloc wrote:
>> On Friday, March 17, 2023 at 11:04:09=E2=80=AFAM UTC-6, MitchAlsup wrote:=

>> Directly supporting the functionality of System/360 instructions in hardw=
>are=20
>> allows programs similar to Hercules to run faster. And having all this ha=
>rdware=20
>> on the chip, of course, suggests going even further in emulation support.=
>=20
><
>Ha ha ha ha ha ha ha <catch breath> maybe you do stand up comedy.

You should read some of Quaddie's missives on e.g. rec.arts.sf.written.

On Friday, March 17, 2023 at 2:06:46 PM UTC-6, Stephen Fuld wrote:

> OK, so let's say you can directly execute every S/360 instruction.
> Again, why would someone choose your chip over IBMs?

I think that's a simple question to answer. IBM PCs, Raspberry Pi single
board computers, and similar systems based on the RISC-V chip are
much less expensive than z/Architecture computers from IBM.

John Savard

On Friday, March 17, 2023 at 2:47:26 PM UTC-6, MitchAlsup wrote:
> On Friday, March 17, 2023 at 12:34:24 PM UTC-5, Quadibloc wrote:

> > Directly supporting the functionality of System/360 instructions in hardware
> > allows programs similar to Hercules to run faster. And having all this hardware
> > on the chip, of course, suggests going even further in emulation support.
> <
> Ha ha ha ha ha ha ha <catch breath> maybe you do stand up comedy.

So, since I've now removed the "remainder" field from the free-format block
header, I could use those three bits to indicate the instruction set.

So seven 256-bit instruction blocks, each containing one 32-bit free-format
header with 1 or 7 in that field could contain 48 (rather than 49, for simplicity)
32 bit words of System/360 or /370 instructions, and these would be further
organized into blocks containing 512 32-bit words of System/360 or /370
instructions - 77 instruction blocks in eleven groups of seven, each containing
48 32-bit words, and one additional instruction block in which only four of the
seven available 32-bit words are used.

The _decode_ fields in the blocks would be used to indicate how many 32-bit
words in the block are used, so that address conversion would only be needed
when branching.

So emulation support is defintely possible. Basically, the paging mechanism
would also have to mark the distinction between code and data segments so
that it's clear where address conversion is required - only in the code segments.
Of course, only the code segments have unused space that can easily be used
for the protection keys...

But if the CPU has to "know" that it's executing 360 code, it might as well just
go into a full-on 360 mode, instead of attempting to represent 360 code as part
of the existing instruction set without a mode...

John Savard

On Friday, March 17, 2023 at 5:48:44 PM UTC-6, John Dallman wrote:

> That creates an incentive for a compiler writer to use such a subset, or
> to offer a choice from several different subsets. Making sure that code
> compiled for /different/ subsets is compatible becomes a new and quite
> complex problem. That creates an incentive to treat the subsets like
> modes, which means that much of the versatility of your ISA is wasted.

One option is to use a calling convention that uses things which are
commonly available. Thus, while 16-bit displacements in memory-reference
instructions are not available if one uses a subset that allows the use of
some features more easily, there's one base register that goes with a 15-bit
displacement that's always available. So that could always be the return
register for the relative jump to subroutine instruction that begins a routine
to give it its first base register value. (Like the BALR that begins a System/360
routine.)

The subsets are still parts of the same instruction set. So it is possible
for a routine to call another routine that happens to be coded differently
as long as they use the same calling convention, and take care of saving
state in a sensible way.

While you raise a good point, if we're talking about one operating
system, which sets certain standards, and different compilers that
emit different kinds of code that all run within that operating system,
it can be made to work.

So a subroutine library might be heavily optimized, and make full use
of the VLIW features, for example, but be callable even from naive
free-format code.

John Savard

On Friday, March 17, 2023 at 2:50:06 PM UTC-6, MitchAlsup wrote:

> Are you going to have a "fix it person" on call who answers the phone at 4:15 AM
> like the IBM repair guy ?? and can arrive in 15 minutes ?? If not, then who is going
> to buy your chip ??

Oh, not the people who need a real mainframe and the support that comes with
it.

Of course, if my chip is successful, and proves its reliability, perhaps some
people might use it to build servers, which *they* could support. I mean,
Unisys is already building mainframes out of Intel chips.

John Savard

On 3/17/2023 7:17 PM, Quadibloc wrote:
> On Friday, March 17, 2023 at 2:06:46 PM UTC-6, Stephen Fuld wrote:
>
>> OK, so let's say you can directly execute every S/360 instruction.
>> Again, why would someone choose your chip over IBMs?
>
> I think that's a simple question to answer. IBM PCs, Raspberry Pi single
> board computers, and similar systems based on the RISC-V chip are
> much less expensive than z/Architecture computers from IBM.

Wait a minute. I thought you said a big advantage of your chip was that
it could run S/360 instructions. None of the designs you mention above
can do that. Certainly, if a customer wants primarily inexpensive MIPS,
he would go with one of those, not IBM, nor your chip.

BTW, are you going to be an exact emulation (including privileged
instructions, etc.) of some version of S/360 and descendants, such that
you can run an IBM OS? And how current a version of the HW and the OS?

If you are saying exact IBM compatibility at lower cost, see Amdahl,
Magnusen (SP?), IPL, Nixdorf, Hitachi, etc. Didn't work out too well
for them.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>If you are saying exact IBM compatibility at lower cost, see Amdahl,
>Magnusen (SP?), IPL, Nixdorf, Hitachi, etc. Didn't work out too well
>for them.

It worked for a time. Then the more cost-concious customers switched
to microprocessor systems, and the "money is no object" mainframe
customers had stayed with IBM all the time, so the business for the
compatible mainframes dried up.

BTW, I find nothing about IPL, and ICL apparently did not really
compete in the IBM-compatible space ("For some sites a microcode
floppy was available that would make the system work as an IBM 360
running the IBM operating system, although this entailed changing the
removable hard drives as the formats were completely different."
<https://en.wikipedia.org/wiki/International_Computers_Limited#2903_range>).

And the computer firms from the mainframe age (except maybe IBM) were
all outcompeted by Unix servers and later PC-based servers, and
several of them were taken over by Fujitsu (who apparently manages to
run the remnants without significant losses). Similarly, the Unix
manufacturers from the 1980s were outcompeted by PCs and all
eventually dropped their own architectures in favour of IA-32/AMD64.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

According to Quadibloc <jsavard@ecn.ab.ca>:
>On Friday, March 17, 2023 at 2:06:46 PM UTC-6, Stephen Fuld wrote:
>
>> OK, so let's say you can directly execute every S/360 instruction.
>> Again, why would someone choose your chip over IBMs?
>
>I think that's a simple question to answer. IBM PCs, Raspberry Pi single
>board computers, and similar systems based on the RISC-V chip are
>much less expensive than z/Architecture computers from IBM.

Back in the day, IBM sold several kinds of PC 360, PCs with boards
that could run S/360 code. They really worked, and within their
limited memory and disk you could boot up and run mainframe software.

None of them were other than niche products, because the CPU is not
the interesting part of a mainframe. The interesting part is all the
other stuff that lets them run a decade (really) between reboots. I
think the main reason that people bought them was a quirk in software
licensing that made them cheaper than adding another 3270 to a real
mainframe.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 3/18/2023 1:47 AM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> If you are saying exact IBM compatibility at lower cost, see Amdahl,
>> Magnusen (SP?), IPL, Nixdorf, Hitachi, etc. Didn't work out too well
>> for them.
>
> It worked for a time. Then the more cost-concious customers switched
> to microprocessor systems, and the "money is no object" mainframe
> customers had stayed with IBM all the time, so the business for the
> compatible mainframes dried up.

Yup. So what makes John think his system will succeed when all of these
have failed?

> BTW, I find nothing about IPL, and ICL apparently did not really
> compete in the IBM-compatible space ("For some sites a microcode
> floppy was available that would make the system work as an IBM 360
> running the IBM operating system, although this entailed changing the
> removable hard drives as the formats were completely different."
> <https://en.wikipedia.org/wiki/International_Computers_Limited#2903_range>).

I meant IPL. I too couldn't find anything about them on the web, but
the company I worked for had one for a few years in the early 1980s.
It was a low end, hence relatively low cost, system, that we used as a
test bed to develop a specialized IBM compatible disk systems. My
recollection is that they were founded by someone named Steve Iplito
(hence the name), and IIRC were based in Boston. The system worked, but
we abandoned our effort and I think they went out of business after a
few years. They were a competitor in the low end S/370 market with
Magnuson computer systems, which also failed.

https://en.wikipedia.org/wiki/Magnuson_Computer_Systems

> And the computer firms from the mainframe age (except maybe IBM) were
> all outcompeted by Unix servers and later PC-based servers, and
> several of them were taken over by Fujitsu (who apparently manages to
> run the remnants without significant losses).

I think you should distinguish here between the IBM PCM mainframes and
the BUNCH. Most of the IBM PCM mainframes were out-competed by IBM
itself with the 4300s taking out the low end systems. And apparently
Amdahl gave up after they decided not to spend the R&D money to develop
systems compatible with IBM's 64 bit systems.

https://www.computerworld.com/article/2589047/amdahl-planning-to-exit-mainframe-business.html

The rise of Unix servers certainly hurt the BUNCH, but that was one
among several factors leading to their decline or demise.

> Similarly, the Unix
> manufacturers from the 1980s were outcompeted by PCs and all
> eventually dropped their own architectures in favour of IA-32/AMD64.

Yup.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Saturday, March 18, 2023 at 11:04:05 AM UTC-6, Stephen Fuld wrote:

> Yup. So what makes John think his system will succeed when all of these
> have failed?

I'm not trying to succeed at that. The goal for my system is to be a viable
alternative to ARM and x86, just like RISC-V. The ability to handle S/360
floats - and *maybe* even do emulation - is just a minor nice feature to make
the chip more attractive in that market.

John Savard

On Saturday, March 18, 2023 at 11:16:02 AM UTC-6, Quadibloc wrote:
> On Saturday, March 18, 2023 at 11:04:05 AM UTC-6, Stephen Fuld wrote:
>
> > Yup. So what makes John think his system will succeed when all of these
> > have failed?
>
> I'm not trying to succeed at that. The goal for my system is to be a viable
> alternative to ARM and x86, just like RISC-V. The ability to handle S/360
> floats - and *maybe* even do emulation - is just a minor nice feature to make
> the chip more attractive in that market.
>
Basically, the history you note showed that the companies that tried to compete
with IBM mainframes with somewhat less expensive mainframes failed, instead
everyone used PCs.

I'm just proposing a cheap microchip - which , because it can handle data
formats resembling those of the System/360, can handle its dusty decks better
than other cheap microchips.

John Savard

On Saturday, March 18, 2023 at 4:29:52 AM UTC-5, Anton Ertl wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >If you are saying exact IBM compatibility at lower cost, see Amdahl,
> >Magnusen (SP?), IPL, Nixdorf, Hitachi, etc. Didn't work out too well
> >for them.
> It worked for a time. Then the more cost-concious customers switched
> to microprocessor systems, and the "money is no object" mainframe
> customers had stayed with IBM all the time, so the business for the
> compatible mainframes dried up.
<
The business dried up because Z-System was too difficult to copy and
fortified with reams of patents. {I was attached at the hip to Fujitsu at
this point in time.}
>
> BTW, I find nothing about IPL, and ICL apparently did not really
> compete in the IBM-compatible space ("For some sites a microcode
> floppy was available that would make the system work as an IBM 360
> running the IBM operating system, although this entailed changing the
> removable hard drives as the formats were completely different."
> <https://en.wikipedia.org/wiki/International_Computers_Limited#2903_range>).
>
> And the computer firms from the mainframe age (except maybe IBM) were
> all outcompeted by Unix servers and later PC-based servers, and
> several of them were taken over by Fujitsu (who apparently manages to
> run the remnants without significant losses). Similarly, the Unix
> manufacturers from the 1980s were outcompeted by PCs and all
> eventually dropped their own architectures in favour of IA-32/AMD64.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 3/18/2023 10:16 AM, Quadibloc wrote:
> On Saturday, March 18, 2023 at 11:04:05 AM UTC-6, Stephen Fuld wrote:
>
>> Yup. So what makes John think his system will succeed when all of these
>> have failed?
>
> I'm not trying to succeed at that. The goal for my system is to be a viable
> alternative to ARM and x86, just like RISC-V. The ability to handle S/360
> floats - and *maybe* even do emulation - is just a minor nice feature to make
> the chip more attractive in that market.

OK. But compared to those competitors, your chip has more circuitry,
thus will be larger, which means it will cost more, and probably be
slower. So what will make your chip succeed against those competitors?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Saturday, March 18, 2023 at 2:50:52 PM UTC-5, Stephen Fuld wrote:
> On 3/18/2023 10:16 AM, Quadibloc wrote:
> > On Saturday, March 18, 2023 at 11:04:05 AM UTC-6, Stephen Fuld wrote:
> >
> >> Yup. So what makes John think his system will succeed when all of these
> >> have failed?
> >
> > I'm not trying to succeed at that. The goal for my system is to be a viable
> > alternative to ARM and x86, just like RISC-V. The ability to handle S/360
> > floats - and *maybe* even do emulation - is just a minor nice feature to make
> > the chip more attractive in that market.
<
> OK. But compared to those competitors, your chip has more circuitry,
> thus will be larger, which means it will cost more, and probably be
> slower. So what will make your chip succeed against those competitors?
<
AND
<
due to the added complexities and "just plain extra stuff", it takes longer
to design, debug; burns more power; and takes a larger design team, ...
All of which are working against your architecture.
<
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Saturday, March 18, 2023 at 12:16:02 PM UTC-5, Quadibloc wrote:
> On Saturday, March 18, 2023 at 11:04:05 AM UTC-6, Stephen Fuld wrote:
>
> > Yup. So what makes John think his system will succeed when all of these
> > have failed?
> I'm not trying to succeed at that. The goal for my system is to be a viable
> alternative to ARM and x86, just like RISC-V. The ability to handle S/360
> floats - and *maybe* even do emulation - is just a minor nice feature to make
> the chip more attractive in that market.
>
> John Savard
If it was me, I'd try for a ISA that makes it easy to add all kinds of instruction set add-ons.
There are commercial products in this area, there are ARM based FPGAs, various soft cores, etc.
For a original ISA, I'd suggest a minimal basic, high code density ISA that also supports a large
instruction format, say 40 to 48-bits, that can in one instruction drive an elaborate add-on?

On Saturday, March 18, 2023 at 4:08:50 PM UTC-5, JimBrakefield wrote:
> On Saturday, March 18, 2023 at 12:16:02 PM UTC-5, Quadibloc wrote:
> > On Saturday, March 18, 2023 at 11:04:05 AM UTC-6, Stephen Fuld wrote:
> >
> > > Yup. So what makes John think his system will succeed when all of these
> > > have failed?
> > I'm not trying to succeed at that. The goal for my system is to be a viable
> > alternative to ARM and x86, just like RISC-V. The ability to handle S/360
> > floats - and *maybe* even do emulation - is just a minor nice feature to make
> > the chip more attractive in that market.
> >
> > John Savard
> If it was me, I'd try for a ISA that makes it easy to add all kinds of instruction set add-ons.
> There are commercial products in this area, there are ARM based FPGAs, various soft cores, etc.
<
This is why one should be preserving future OpCode space, providing lots of room to grow into
the future. My 66000 uses only 36 of the 64 slots in the Major OpCode table, and less than ½
of the 2-register memory and 2-register calculation subGroups, less than 1/64 of the 1-operand
but 3/4 of the 3-operand instruction subgroups.
<
This is another reason not to clutter up your OpCode map with Vector instructions (300+) or with
SIMD instructions (1300+).
<
So, if you have a reason to need an instruction with a 16-bit immediate, there is fresh space
available.
<
> For a original ISA, I'd suggest a minimal basic, high code density ISA that also supports a large
> instruction format, say 40 to 48-bits, that can in one instruction drive an elaborate add-on?
<
My 66000 has better code density without 16-bit instructions than RISC-V has with 16-bit
instructions. I have instructions from 1-word in size to 5-words in size (although I have yet
to see a 5-word instruction emitted by Brian's compiler).
<
I also have STM instruction than can store up to 31 registers to an MMI/O area in a single
transaction on the bus (that is ATOMICally).

On Saturday, March 18, 2023 at 4:56:14 PM UTC-5, MitchAlsup wrote:
> On Saturday, March 18, 2023 at 4:08:50 PM UTC-5, JimBrakefield wrote:
> > On Saturday, March 18, 2023 at 12:16:02 PM UTC-5, Quadibloc wrote:
> > > On Saturday, March 18, 2023 at 11:04:05 AM UTC-6, Stephen Fuld wrote:
> > >
> > > > Yup. So what makes John think his system will succeed when all of these
> > > > have failed?
> > > I'm not trying to succeed at that. The goal for my system is to be a viable
> > > alternative to ARM and x86, just like RISC-V. The ability to handle S/360
> > > floats - and *maybe* even do emulation - is just a minor nice feature to make
> > > the chip more attractive in that market.
> > >
> > > John Savard
> > If it was me, I'd try for a ISA that makes it easy to add all kinds of instruction set add-ons.
> > There are commercial products in this area, there are ARM based FPGAs, various soft cores, etc.
> <
> This is why one should be preserving future OpCode space, providing lots of room to grow into
> the future. My 66000 uses only 36 of the 64 slots in the Major OpCode table, and less than ½
> of the 2-register memory and 2-register calculation subGroups, less than 1/64 of the 1-operand
> but 3/4 of the 3-operand instruction subgroups.
> <
> This is another reason not to clutter up your OpCode map with Vector instructions (300+) or with
> SIMD instructions (1300+).
> <
> So, if you have a reason to need an instruction with a 16-bit immediate, there is fresh space
> available.
> <
> > For a original ISA, I'd suggest a minimal basic, high code density ISA that also supports a large
> > instruction format, say 40 to 48-bits, that can in one instruction drive an elaborate add-on?
> <
> My 66000 has better code density without 16-bit instructions than RISC-V has with 16-bit
> instructions. I have instructions from 1-word in size to 5-words in size (although I have yet
> to see a 5-word instruction emitted by Brian's compiler).

I'm a fan of 24-bit RISC instructions, ugh, which is more difficult for multiple issue etc.
The x86 adventure shows that this (non-32-bit alignment) is not a show stopper.
At what silicon cost??

> <
> I also have STM instruction than can store up to 31 registers to an MMI/O area in a single
> transaction on the bus (that is ATOMICally).

On Saturday, March 18, 2023 at 7:34:52 PM UTC-5, JimBrakefield wrote:
> On Saturday, March 18, 2023 at 4:56:14 PM UTC-5, MitchAlsup wrote:
> > On Saturday, March 18, 2023 at 4:08:50 PM UTC-5, JimBrakefield wrote:
> > > On Saturday, March 18, 2023 at 12:16:02 PM UTC-5, Quadibloc wrote:
> > > > On Saturday, March 18, 2023 at 11:04:05 AM UTC-6, Stephen Fuld wrote:
> > > >
> > > > > Yup. So what makes John think his system will succeed when all of these
> > > > > have failed?
> > > > I'm not trying to succeed at that. The goal for my system is to be a viable
> > > > alternative to ARM and x86, just like RISC-V. The ability to handle S/360
> > > > floats - and *maybe* even do emulation - is just a minor nice feature to make
> > > > the chip more attractive in that market.
> > > >
> > > > John Savard
> > > If it was me, I'd try for a ISA that makes it easy to add all kinds of instruction set add-ons.
> > > There are commercial products in this area, there are ARM based FPGAs, various soft cores, etc.
> > <
> > This is why one should be preserving future OpCode space, providing lots of room to grow into
> > the future. My 66000 uses only 36 of the 64 slots in the Major OpCode table, and less than ½
> > of the 2-register memory and 2-register calculation subGroups, less than 1/64 of the 1-operand
> > but 3/4 of the 3-operand instruction subgroups.
> > <
> > This is another reason not to clutter up your OpCode map with Vector instructions (300+) or with
> > SIMD instructions (1300+).
> > <
> > So, if you have a reason to need an instruction with a 16-bit immediate, there is fresh space
> > available.
> > <
> > > For a original ISA, I'd suggest a minimal basic, high code density ISA that also supports a large
> > > instruction format, say 40 to 48-bits, that can in one instruction drive an elaborate add-on?
> > <
> > My 66000 has better code density without 16-bit instructions than RISC-V has with 16-bit
> > instructions. I have instructions from 1-word in size to 5-words in size (although I have yet
> > to see a 5-word instruction emitted by Brian's compiler).
<
> I'm a fan of 24-bit RISC instructions, ugh, which is more difficult for multiple issue etc.
> The x86 adventure shows that this (non-32-bit alignment) is not a show stopper.
> At what silicon cost??
<
Actually, once you buy off on the fact you have variable length instructions (AND in this
context CoIssue, Instruction Fusing, Prefixes, Postfixes,...) are all versions of variable
length instructions; Once you know you have VLI, you develop pipeline structures which
deal with the VL nature of the beast. Things like:
a) wide fetch:: 4-wide on a 1-wide machine, pairs of 8-wide on a 6-wide machine
b) add a parse stage to the pipeline,
c) configure means to send constants directly to function units without forwarding,
d) configure predictor means to indicate that inst[5] from the current decode point
..... is being predicted by the predictor just read based on the fetch at IP..
<
An instruction buffer capable of holding 8 fetched units from the ICache is invisible
in silicon real estate these days, certainly smaller than the branch predictor, and
maybe about as valuable.
<
But once you have these things, all of a sudden, you don't need other things;
things like::
1) instructions that past bits together to make large constants.
2) instructions that add bits to IP for PIC data referencing
3) instructions that LD a constant from memory just to feed it to a FU,
4) instructions that LD a label from memory just to feed it to IP,
<
Leaving room for other stuff that actually gets work done..........

On Saturday, March 18, 2023 at 3:56:14 PM UTC-6, MitchAlsup wrote:

> My 66000 has better code density without 16-bit instructions than RISC-V has with 16-bit
> instructions.

I believe you. RISC-V does *not* have great code density.

One of the goals of Concertina II, though, is to achieve a level of code density that
approaches the theoretical maximum achievable... for a simple, straightforward
computer.

John Savard