The current iteration of Concertina II has a block header format that is quite
a bit simpler than those of previous iterations.
It does have at least one complicated thing that I am thinking about
dropping: a header format that indicates 36-bit instructions. I want to
avoid excessive complexity, and having a second version of the
instruction set which includes all the things I had to leave out to squeeze
the instruction set into 32 bits adds huge complexity.
But the change I've made now is this:
I included in the instruction set another complete instruction set
where there were three bits in the instruction available for extra information.
The idea was to have the number of unused instruction slots which
instead contain pseudo-immediates specified with essentially zero overhead.
Well, if I already have that instruction format...
why not use it, in the instruction slots, as a way to specify predication?
That idea led to the "alternate II" instruction format.
Six bits that these instructions don't use (the three for the number of
unused instruction slots, plus another three that distinguished this small
fraction of the instruction set from the whole) can serve _either_ for
predication or for detailed indication of instruction dependencies.
So the VLIW stuff that in earlier iterations led to block header formats
with perhaps twenty or thirty different forms... now, with the
restriction that it can only be applied to a subset of the instruction set
in which 16-bit displacements are given up... are now back without
causing "excessive" complexity, by my low standards.

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

et. seq..

John Savard

On Friday, March 3, 2023 at 4:16:24 AM UTC-6, Quadibloc wrote:
> The current iteration of Concertina II has a block header format that is quite
> a bit simpler than those of previous iterations.
<
> It does have at least one complicated thing that I am thinking about
> dropping: a header format that indicates 36-bit instructions. I want to
> avoid excessive complexity, and having a second version of the
> instruction set which includes all the things I had to leave out to squeeze
> the instruction set into 32 bits adds huge complexity.
<
Only when you insist on putting too many instructions into that space,
or consuming bits in headers, preventing you from encoding your instruc-
tions in a straightforward manner.
<
I feel that you are frustrated that you can't have your cake and eat it too..
<
In my efforts, I recognized that the 1% instructions did not deserve their
own encoding, but by having a mechanism to express these 1%-ers gets
you almost as far as having 36-bits at the start, and without breaking the
32-bit bank. I call these support instructions "instruction-modifiers" with
CARRY being the most obvious case, but perhaps VEC-LOOP also qualify.
<
> But the change I've made now is this:
> I included in the instruction set another complete instruction set
> where there were three bits in the instruction available for extra information.
<
This seems at odds with simplicity and elegance.
<
On the other hand, there are RISC architectures with upwards of 1,300 instructions.
<
> The idea was to have the number of unused instruction slots which
> instead contain pseudo-immediates specified with essentially zero overhead.
> Well, if I already have that instruction format...
> why not use it, in the instruction slots, as a way to specify predication?
> That idea led to the "alternate II" instruction format.
> Six bits that these instructions don't use (the three for the number of
> unused instruction slots, plus another three that distinguished this small
> fraction of the instruction set from the whole) can serve _either_ for
> predication or for detailed indication of instruction dependencies.
<
Every time you speak of headers it gives me the shivers. Headers are
only optimal for exactly one implementation, and become a burden
for all future implementations (assuming you keep ISA intact.)
<
What if you wanted to build a 1-wide machine with on-line arithmetic
(1 bit at a time) as your lowest possible implementation, for a smallest
possible LUT count implementation ??? Do headers help you here !?!
<
What if you wanted a family with a 1-wide, 2-wide, 3-wide, 4-wide, 5-wide
implementations?
<
What if you got far into implementation with a header based instruction
packetizer and then due to silicon resources you had to chop 1 instruction
from the packet/bundle/whatever ?????
<
Can your ISA absorb this kind of hit ??
Probably not.
Mine can.............And (thanks to Brian) I have a working compiler for my ISA.
When will you get one for yours ??
<
You see, there is a point at which you quit diddling with your ISA and go
out and start building stuff:: simulators, Verilog, compilers, operating
system, ..... the stuff that makes the architecture something other than
a toy.
<
> So the VLIW stuff that in earlier iterations led to block header formats
> with perhaps twenty or thirty different forms... now, with the
> restriction that it can only be applied to a subset of the instruction set
> in which 16-bit displacements are given up... are now back without
> causing "excessive" complexity, by my low standards.
<
My ISA has 7 instruction formats, 4 if you combine all the 2-operand
with out the second register into one, and use bits those instructions
can't use from their 16-bit immediate as OpCode bits.
<
Yet, my near-RISC ISA only requires 75% the instruction count as RISC-V
ISA requires, both static and dynamic.
>
> http://www.quadibloc.com/arch/ct17int.htm
<
Concertina II in its 17 iteration........
>
> et. seq..
>
> 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.

Well, the equivalent of baking two cakes is precisely the revolutionary
technical innovation I'm aiming at here.

(quoting me)
> > But the change I've made now is this:
> > I included
long previously to the current change
> > in the instruction set another complete instruction set
> > where there were three bits in the instruction available for extra information.

> This seems at odds with simplicity and elegance.
> <
> On the other hand, there are RISC architectures with upwards of 1,300 instructions.

> Every time you speak of headers it gives me the shivers. Headers are
> only optimal for exactly one implementation, and become a burden
> for all future implementations (assuming you keep ISA intact.)

Yes, I suppose that _is_ the lesson to be learned from the Itanium.

I _have_ tried, none the less, to design the ISA to be susceptible to a
range of implementations, even as the ISA of the System/360 was.

In the lowest-end implementations, the VLIW features wouldn't
work, and in the highest-end implementations, they would not
be necessary, as OoO would automatically do what they're there to
assist in.

Unlike the Itanium, headers are _optional_.

A block of eight instruction slots can begin in *three* ways:

1) Just a plain instruction. Then the next seven instruction slots
will also have plain instructions in them.

2) A shortened instruction, with three _decode_ bits also present.
In that case, some of the instruction slots may be indicated as
unused by instructions, so that pseudo-immediates can be placed
in them.

3) A header. Then you can have all the other VLIW goodies:
predicated instructions, explicit indications of instruction
dependencies. Also, you can have certain non-VLIW stuff, like
indications of instructions longer than 32 bits.

> What if you got far into implementation with a header based instruction
> packetizer and then due to silicon resources you had to chop 1 instruction
> from the packet/bundle/whatever ?????
> <
> Can your ISA absorb this kind of hit ??
> Probably not.

Absolutely not. If the packets are other than 256 bits long, it would need
to be a different ISA. That I must admit.

> You see, there is a point at which you quit diddling with your ISA and go
> out and start building stuff:: simulators, Verilog, compilers, operating
> system, ..... the stuff that makes the architecture something other than
> a toy.

But that time comes _after_ the ISA actually becomes potentially
useful. Given how deeply flawed it seems to be, it seems reasonable
to conclude that time is not quite yet.

John Savard

On Friday, March 3, 2023 at 11:13:25 AM UTC-6, Quadibloc wrote:
> 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.
> Well, the equivalent of baking two cakes is precisely the revolutionary
> technical innovation I'm aiming at here.
>
> (quoting me)
> > > But the change I've made now is this:
> > > I included
> long previously to the current change
> > > in the instruction set another complete instruction set
> > > where there were three bits in the instruction available for extra information.
>
> > This seems at odds with simplicity and elegance.
> > <
> > On the other hand, there are RISC architectures with upwards of 1,300 instructions.
> > Every time you speak of headers it gives me the shivers. Headers are
> > only optimal for exactly one implementation, and become a burden
> > for all future implementations (assuming you keep ISA intact.)
> Yes, I suppose that _is_ the lesson to be learned from the Itanium.
>
> I _have_ tried, none the less, to design the ISA to be susceptible to a
> range of implementations, even as the ISA of the System/360 was.
>
> In the lowest-end implementations, the VLIW features wouldn't
> work, and in the highest-end implementations, they would not
> be necessary, as OoO would automatically do what they're there to
> assist in.
>
> Unlike the Itanium, headers are _optional_.
>
> A block of eight instruction slots can begin in *three* ways:
>
> 1) Just a plain instruction. Then the next seven instruction slots
> will also have plain instructions in them.
>
> 2) A shortened instruction, with three _decode_ bits also present.
> In that case, some of the instruction slots may be indicated as
> unused by instructions, so that pseudo-immediates can be placed
> in them.
>
> 3) A header. Then you can have all the other VLIW goodies:
> predicated instructions, explicit indications of instruction
> dependencies. Also, you can have certain non-VLIW stuff, like
> indications of instructions longer than 32 bits.
> > What if you got far into implementation with a header based instruction
> > packetizer and then due to silicon resources you had to chop 1 instruction
> > from the packet/bundle/whatever ?????
> > <
> > Can your ISA absorb this kind of hit ??
> > Probably not.
> Absolutely not. If the packets are other than 256 bits long, it would need
> to be a different ISA. That I must admit.
> > You see, there is a point at which you quit diddling with your ISA and go
> > out and start building stuff:: simulators, Verilog, compilers, operating
> > system, ..... the stuff that makes the architecture something other than
> > a toy.
<
> But that time comes _after_ the ISA actually becomes potentially
> useful. Given how deeply flawed it seems to be, it seems reasonable
> to conclude that time is not quite yet.
<
A year ago,.. I had an ISA that used 12% fewer instructions than RISC-V
A year later, I have an ISA that uses 25% fewer instructions than RISC-V
<
All of this progress is because Brian got the compiler working well enough
that I could read hundreds of thousands of lines of code, reason about the
ISA, reason about compilation, and make adjustments to ISA.
<
Both ends towards the middle is best.
>
> John Savard

On Friday, March 3, 2023 at 10:48:50 AM UTC-7, MitchAlsup wrote:

> Both ends towards the middle is best.

Oh, I'm sure that trying to implement will suggest minor changes that
bring true improvement.

But one has to reach a certain point before implementation - or
even completing the description of the instruction set - is worth
starting.

I've finally completed this round of updates by correcting the 16-bit
instructions after simplifying the long instructions (at the cost of some
code density in very rarely used instructions).

John Savard

jgd@cix.co.uk (John Dallman) writes:
> After that, a virtual server with Ubuntu, one CPU, 4GB RAM and 100GB disk,
> is US$0.137/hour. <https://cloud.ibm.com/vpc-ext/provision/vs>

Is it awesomely fast? Because I calculate that as $100/month, and that seems
pretty low spec for that much money.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

According to Andy Valencia <vandys@vsta.org>:
>jgd@cix.co.uk (John Dallman) writes:
>> After that, a virtual server with Ubuntu, one CPU, 4GB RAM and 100GB disk,
>> is US$0.137/hour. <https://cloud.ibm.com/vpc-ext/provision/vs>
>
>Is it awesomely fast? Because I calculate that as $100/month, and that seems
>pretty low spec for that much money.

They say it's $85/mo with some discounts. Their Intel offerings seem
about half the price.

I think the message here is that if you want a zSeries mainframe, you
want a zSeries mainframe, and $85/mo is a steal compared to buying or
leasing one.

--
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

John Levine <johnl@taugh.com> writes:
>According to Andy Valencia <vandys@vsta.org>:
>>jgd@cix.co.uk (John Dallman) writes:
>>> After that, a virtual server with Ubuntu, one CPU, 4GB RAM and 100GB disk,
>>> is US$0.137/hour. <https://cloud.ibm.com/vpc-ext/provision/vs>
>>
>>Is it awesomely fast? Because I calculate that as $100/month, and that seems
>>pretty low spec for that much money.
>
>They say it's $85/mo with some discounts. Their Intel offerings seem
>about half the price.
>
>I think the message here is that if you want a zSeries mainframe, you
>want a zSeries mainframe, and $85/mo is a steal compared to buying or
>leasing one.

If they want to cash in on the remaining captive mainframe customers,
that's the way to go.

OTOH, if they want to expand their mainframe business to a wider
audience, they should offer prices that are at least competetive with
other cloud providers. Hetzner offers 2 "Standard" Intel vCPUs with
4GB RAM, and 20TB/mo of traffic for EUR 6,37, or two "Dedicated vCPUs"
(Intel or AMD) with 8GB RAM and 20TB/mo traffic for EUR 26, or a
dedicated server (Ryzen 3600, 64GB RAM, no traffic volume specified)
for EUR 44,39. Not sure what a decicated vCPU is, though.

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

On Sunday, March 5, 2023 at 12:26:43 PM UTC-7, John Dallman wrote:
> In article <7fb66351-9136-492e...@googlegroups.com>,
> jsa...@ecn.ab.ca (Quadibloc) wrote:
>
> > http://www.quadibloc.com/arch/ct17int.htm
>
> Reading over some of your pages, I found an interesting line at
> <http://www.quadibloc.com/arch/arcint.htm>:
>
> > I certainly would like to see some sort of CISC big-endian
> > architecture with pipeline vector instructions become available
> > at prices, and with a complement of software, reflecting the
> > benefits of a mass market.
>
> You can rent time on one cheaply. It's IBM z/Architecture. IBM are keen
> to promote it, and offer cloud instances with Linux at very reasonable
> prices.

That's not quite true, I'm afraid.

The current z/Architecture machines do have vector instructions, but those
are vector instructions of exactly the same type as the SSE and AVX vector
instructions which are included in the x86 machine on which I'm typing this
message.

By "pipeline vector instructions", I meant vector instructions like those of
the Cray I computer and its successors. At one time, IBM did offer an add-on
feature for certain later System/370 computers which provided those kinds
of vector instructions: the IBM System/370 vector facility, which was offered
for the IBM 3090 and I believe a few other models as well.

John Savard

On Friday, March 3, 2023 at 2:51:07 PM UTC-7, Quadibloc wrote:

> I've finally completed this round of updates by correcting the 16-bit
> instructions after simplifying the long instructions (at the cost of some
> code density in very rarely used instructions).

I've changed what I do for the long instructions again. I've freed up
enough opcode space by doing so that, theoretically, I could swipe
another idea from Mitch Alsup: making instructions that start with 0000
and 1111 invalild so as to provide an extra layer of protection against
executing typical integer constants as code. (Floating-point numbers
would tend to start with 01000..., 00111..., 11000..., and 10111 due to
being in sign-magnitude representation with an excess-n exponent.)

But to do so, I would have to change the format of pairs of 16-bit instructions
in a 32 bit word from 0...0... to 01... or 10..., which is even more unattractive
now because of the changes I've made to the long instructions.

John Savard

On Mon, 06 Mar 2023 10:08:36 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

> ... Not sure what a dedicated vCPU is, though.

The hypervisor creates a virtual CPU (vCPU) per core / per SMT thread
(if applicable) ... so, e.g., a 64-core hyperthreaded Intel server
might offer 128 vCPUs.

"dedicated" means that the vCPUs are together in a cpuset, affinity
bound to cores executing them and all runnable simultaneously. It's
the same as dedicating real cores (or real CPUs) to a program - just
done with virtual CPUs instead.

Theoretically, having all the vCPUs able to be runnable simultaneously
can improve performance for certain workloads, even if affinity alone
buys little/nothing due to cache effects from context switching. On
this, mileage may vary considerably.

George

On Friday, March 3, 2023 at 3:16:24 AM UTC-7, Quadibloc wrote:

> It does have at least one complicated thing that I am thinking about
> dropping: a header format that indicates 36-bit instructions. I want to
> avoid excessive complexity, and having a second version of the
> instruction set which includes all the things I had to leave out to squeeze
> the instruction set into 32 bits adds huge complexity.

I did drop that, of course, and, although it took two attempts, I came
up with a format for instructions longer than 32 bits which seemed
reasonable to me for compactness and simplicity. No longer was it
necessary to have a second version of all the other instructions to accomodate
long instructions.

But one thing I gave up was the ability to have free-format code, where one
can just sequence instructions of all the different lengths in any order;
instead, normally, 16-bit instructions must be in pairs, or a 16-bit instruction
must precede a 48-bit or 80-bit instruction, so that everything is on 32-bit
boundaries.

I have now added a new format to the headers which overcomes this
limitation, and brings back free-format code, but this time the free-format
code uses (essentially) exactly the same instructions as the normal
mode. (The 48-bit and 80-bit instructions could be considered to have
been tweaked, but not by much.)

So the desired features have all been returned, but this time without
complexity which even I thought was excessive. Not that the architecture
is not still horribly complex, but it at least seems to have avoided going
to _utterly_ ridiculous lengths. (Of course, an ISA that is merely *quite*
ridiculous is not really much of an achievement...)

John Savard

On Monday, March 6, 2023 at 11:48:22 PM UTC-7, Quadibloc wrote:

> So the desired features have all been returned, but this time without
> complexity which even I thought was excessive. Not that the architecture
> is not still horribly complex, but it at least seems to have avoided going
> to _utterly_ ridiculous lengths. (Of course, an ISA that is merely *quite*
> ridiculous is not really much of an achievement...)

Incidentally, note that five of a possible eight short header clauses are
currently defined, and there's also opcode space in the header for other
things after the headers for free-format blocks.

In addition to putting things in the empty space from the _beginning_
for future extensions to the architecture, one could add *model-dependent*
features from the end.

So one could have a block format where a 32-bit header is followed by
four 56-bit instructions... in four different instruction sets, reflecting
different sections of the hardware that are available to be employed in
parallel.

Yes. There's "room" to go full-Itanium, if someone were so perverse
as to wish to build an ISA around that idea. I, at least for the moment,
definitely am not.

John Savard

On Monday, March 6, 2023 at 3:32:12 AM UTC-7, Quadibloc wrote:
> On Friday, March 3, 2023 at 2:51:07 PM UTC-7, Quadibloc wrote:
>
> > I've finally completed this round of updates by correcting the 16-bit
> > instructions after simplifying the long instructions (at the cost of some
> > code density in very rarely used instructions).
> I've changed what I do for the long instructions again. I've freed up
> enough opcode space by doing so that, theoretically, I could swipe
> another idea from Mitch Alsup: making instructions that start with 0000
> and 1111 invalild so as to provide an extra layer of protection against
> executing typical integer constants as code. (Floating-point numbers
> would tend to start with 01000..., 00111..., 11000..., and 10111 due to
> being in sign-magnitude representation with an excess-n exponent.)
>
> But to do so, I would have to change the format of pairs of 16-bit instructions
> in a 32 bit word from 0...0... to 01... or 10..., which is even more unattractive
> now because of the changes I've made to the long instructions.

At this point, instructions starting with 1110 and 1111 were unused.

Now, I'm using 1110 for a 16-bit header format.

But I still found other ways to tweak the instruction set so as to leave
instructions starting with a substantial number of zeroes unused, thus
allowing me to copy another one of Mitch's ideas - into an architecture
which, of course, mostly abominable by his sights, and, I must admit,
for good reason.

John Savard

On Tuesday, March 7, 2023 at 12:26:49 AM UTC-7, Quadibloc wrote:

> But I still found other ways to tweak the instruction set so as to leave
> instructions starting with a substantial number of zeroes unused, thus
> allowing me to copy another one of Mitch's ideas - into an architecture
> which, of course, mostly abominable by his sights, and, I must admit,
> for good reason.

I've rolled back that modification, finding its cost to be too high in its
present form. Perhaps I'll eventually figure out another, better, way to do
this.

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.

On the one hand, I've just discovered that my normal 32-bit instructions,
since they don't use the ones starting with 1110 and 1111, and they also
use only half of the instructions of the form 0...1... would actually fit together
in 31 bits - so a CISC version of the same instruction set, where the 16-bit
instructions start with 0, and the 32-bit instructions start with 1, is possible.

On the other hand, trying to squeeze more into a given space than is reasonable
is... not a bug, but an intended feature, if I can succeed in doing so.

But there _is_ one price I am paying for doing so that I don't find acceptable,
and in my opinion is the worst flaw of the Concertina II architecture.

I'm using multiple options for indicating the number of instruction slots not
to decode in a block.

The intent is to, by offering these options, reduce to an absolute minimum the
amount of overhead this imposes for code th at needs unused instruction slots -
because some instructions have pseudo-immediate values.

But it appears to make it extremely complicated for a compiler to generate
code that would use those options well.

I think there are three ways to approach code generation for the system that
would be manageable:

1) Don't use the base registers that are for 64K segments. Use the one base
register that supports a 32K segment as the main one, and the ones for 4K
segments for everything else.

That way, the special instructions that leave room for a 3-bit offset field
are nearly always usable, and so the compiler succeeds in efficiently
lowering overhead to an absolute minimum.

2) Be content with some wasted space; if it's unavoidable, putting a
lot of effort into trying to avoid it some of the time isn't worth it.

3) Normally, getting an instruction that can be replaced with one of the
shorter instructions that leaves room for the decode field... is not too
difficult if the code is written with several threads interlaced, using
different subsets of the 32 available registers.

It's intended for code to be written like that, and usually the register-to-register
instructions can be shrunk this way without problems, and they should outnumber
the memory-reference instructions by far.

These three... workarounds... or points... suggest I may be worrying about
a non-problem. But certainly the complexity of the suite of offerings provided
for block header types could be off-putting to some taking a look at the ISA.

Of course, the header scheme is much more simple than it *had* been in
previous iterations of Concertina II.

Now, all there is - is this:

1) A 32-bit header, which offers the various special functions that need a
header;

2) A 16-bit header - 32 bits, with the header plus a 16-bit instruction - if
all you need is one of the fancy features, not two of them;

3) A shrunken version of the 32-bit instruction set, if all you need is the
3-bit "decode" field which allows pseudo-immediates, and want to minimize
the overhead price paid for that;

4) One of the fancy options if header styles (1) or (2) are chosen put
some information formerly put in the header - and making the list of
possible header formats long and complicated - in the instructions
instead. Since I have created a shortened form of the instructions,
I use it to solve the problem of putting either five bits of predication information
or three bits of dependency information with every instruction.

How do I do that with a shortened form of the instruction that gives extra space
only for a three-bit decode field?

Well, those shortened instructions only got to take up 1/8 of the total opcode
space of the regular instruction set. So if I mark instruction slots that instead
must have one of those instructions with the special meaning for that field,
that's three extra bits, making six bits, which is just what I need.

It's vastly simpler than what went before.

But it's still clearly not simple _enough_. Or at least I have the nagging
feeling that it's not simple enough.

Explaining that certain features are for optimized VLIW-style code, and
are not useful otherwise would... help. A little.

Perhaps I just have to reconcile myself to the fact that if I'm trying
to do more than should be (or is) possible, I'm not going to be able to do it *well*.

But I keep hoping there is some solution I'm overlooking that will
make it all make sense.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> 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.
>
> On the one hand, I've just discovered that my normal 32-bit instructions,
> since they don't use the ones starting with 1110 and 1111, and they also
> use only half of the instructions of the form 0...1... would actually fit together
> in 31 bits - so a CISC version of the same instruction set, where the 16-bit
> instructions start with 0, and the 32-bit instructions start with 1, is possible.
>
> On the other hand, trying to squeeze more into a given space than is reasonable
> is... not a bug, but an intended feature, if I can succeed in doing so.

That would be a problem if anybody decided to extend your ISA at a later
date.

Look at POWER, where they ran out of encoding space and had to
restrict load and stores to their vector registers to indexed loads,
so they have to waste^H^H^H^H^Huse a register for loading a constant,
then do the indexed load.

> But there _is_ one price I am paying for doing so that I don't find acceptable,
> and in my opinion is the worst flaw of the Concertina II architecture.
>
> I'm using multiple options for indicating the number of instruction slots not
> to decode in a block.
>
> The intent is to, by offering these options, reduce to an absolute minimum the
> amount of overhead this imposes for code th at needs unused instruction slots -
> because some instructions have pseudo-immediate values.
>
> But it appears to make it extremely complicated for a compiler to generate
> code that would use those options well.

I don't suppose you have ever tried writing a compiler for your
architecture.

Maybe you should try writing an assembler first - that also lets you
know a lot about the quirks of your architecture.

> I think there are three ways to approach code generation for the system that
> would be manageable:
>
> 1) Don't use the base registers that are for 64K segments. Use the one base
> register that supports a 32K segment as the main one, and the ones for 4K
> segments for everything else.

Hm. You may want large offsets for

- the stack pointer
- the frame pointer
- the PC, for PC-relative stuff
- The Global Offset Table (GOT)
- The Procedure Linkage Table (PLT)

One register does not sound like enough.

> That way, the special instructions that leave room for a 3-bit offset field
> are nearly always usable, and so the compiler succeeds in efficiently
> lowering overhead to an absolute minimum.
>
> 2) Be content with some wasted space; if it's unavoidable, putting a
> lot of effort into trying to avoid it some of the time isn't worth it.
>
> 3) Normally, getting an instruction that can be replaced with one of the
> shorter instructions that leaves room for the decode field... is not too
> difficult if the code is written with several threads interlaced, using
> different subsets of the 32 available registers.

Sounds very hairy, and will need a very special register allocator.
Have you looked into the algorithms needed for that?

On Sunday, March 12, 2023 at 4:35:48 AM UTC-6, Thomas Koenig wrote:

> Sounds very hairy, and will need a very special register allocator.
> Have you looked into the algorithms needed for that?

I would envision that the machine would be used with seven base
registers, all belonging to one segment size, normally. Whatever
size that might be. The only exception is where the one 32K segment
is used for the main segment of the routine, and 4K segments are
used for everything else.

In order to make my architecture complete, and not culturally
biased, after considering adding a complete set of packed
duodecimal instructions, I realized that it ought to have packed
sexagesimal instructions as well. Which would work if it had a
48 bit word, but otherwise not so much.

And then I realized that one other numeration system was used
historically! What about packed vigesimal? But that requires a
word length that is a multiple of five bits!

Fortunately, my encyclopedic knowledge of the history of
computing comes to the rescue.

Obviously, my CPU needs a pin dedicated to informing it that
its RAM is only 60 bits wide instead of 64 bits wide!

In that case, binary data will use the least significant 64 bits of
a 120-bit doubleword, while sexagesimal and vigesimal data
are stored efficiently.

Otherwise, binary data will be stored efficiently, while sexagesimal
and vigesimal data are stored in the least significant 60 bits of a
64 bit word.

This is like the Varian DATA/620 and the Varian 620/i computer,
which could use memory that was either 18 bits wide or 16 bits
wide, or the General Instrument CP1600 microprocessor, which
could use memory that was either 10 bits wide or 8 bits wide.

Then there's currency arithmetic and calendar arithmetic.

Currency arithmetic is where a packed decimal number is
followed by one vigesimal digit and then one duodecimal digit.

Calendar arithmetic is where the second-from-last digit of
a packed vigesimal number is instead octadecimal.

In both of these mixed-radix cases, the numbers would be
treated as adjuncts to another number system, not as a
full fledged system in their own right.

Thus, the add and subtract instructions would be normal;
add and subtract two currency numbers to yield a currency
number.

Multiplication would be currency * packed decimal = currency,
and division would be currency / currench = packed decimal.

The same for calendar, except this time vigesimal would be
the parent system.

John Savard

On Sunday, March 12, 2023 at 10:32:19 AM UTC-6, Quadibloc wrote:

> Obviously, my CPU needs a pin dedicated to informing it that
> its RAM is only 60 bits wide instead of 64 bits wide!
>
> In that case, binary data will use the least significant 64 bits of
> a 120-bit doubleword, while sexagesimal and vigesimal data
> are stored efficiently.
>
> Otherwise, binary data will be stored efficiently, while sexagesimal
> and vigesimal data are stored in the least significant 60 bits of a
> 64 bit word.
>
> This is like the Varian DATA/620 and the Varian 620/i computer,
> which could use memory that was either 18 bits wide or 16 bits
> wide, or the General Instrument CP1600 microprocessor, which
> could use memory that was either 10 bits wide or 8 bits wide.

Now, this would make integer and floating-point arithmetic ludicrously
wasteful of memory in the 60-bit mode. If one changed the lengths
of those datatypes in that mode, though, a decision about addressing
would have to be made.

Well, one would have to be made anyways, because 7 1/2 bit bytes
would be difficult to deal with (although I suppose one could simply
disallow dealing with units smaller than a halfword, except as digits
within a packed type).

If the fundamental unit of addressing were made the 12-bit slab of the
NCR 315, five of them would fit in a 60-bit word.

This allows double precision to become 60 bits, intermediate precision
would remain 48 bits, and single precision would become 36 bits, so the
floating point types would improve.

36-bit integers with 24-bit halfwords?

That would mean adding a *third* mixed-radix type to the architecture;
the address type, wherein the last three bits of an otherwise binary number
would be base-5.

Since there's already a complete instruction set that leaves out three or six
bits per 32-bit word, it wouldn't be necessary to go 64 out of 120 for programs
either. The 30-bit instructions could have extra bits to pick which base they're
operating on... of course, though, since all the packed decimal instructions,
to be extended to include packed duodecimal, packed sexagesimal, and packed
vigesimal are 48 bits or longer, *they would still not fit*.

Although I'm confident I can come up with _some_ contrivance to manage...

John Savard

John Savard

On Sunday, March 12, 2023 at 3:54:16 AM UTC-5, Quadibloc wrote:
> 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.
> On the one hand, I've just discovered that my normal 32-bit instructions,
> since they don't use the ones starting with 1110 and 1111, and they also
> use only half of the instructions of the form 0...1... would actually fit together
> in 31 bits - so a CISC version of the same instruction set, where the 16-bit
> instructions start with 0, and the 32-bit instructions start with 1, is possible.
>
> On the other hand, trying to squeeze more into a given space than is reasonable
> is... not a bug, but an intended feature, if I can succeed in doing so.
>
> But there _is_ one price I am paying for doing so that I don't find acceptable,
> and in my opinion is the worst flaw of the Concertina II architecture.
>
> I'm using multiple options for indicating the number of instruction slots not
> to decode in a block.
>
> The intent is to, by offering these options, reduce to an absolute minimum the
> amount of overhead this imposes for code th at needs unused instruction slots -
> because some instructions have pseudo-immediate values.
>
> But it appears to make it extremely complicated for a compiler to generate
> code that would use those options well.
>
> I think there are three ways to approach code generation for the system that
> would be manageable:
>
> 1) Don't use the base registers that are for 64K segments. Use the one base
> register that supports a 32K segment as the main one, and the ones for 4K
> segments for everything else.
>
> That way, the special instructions that leave room for a 3-bit offset field
> are nearly always usable, and so the compiler succeeds in efficiently
> lowering overhead to an absolute minimum.
>
> 2) Be content with some wasted space; if it's unavoidable, putting a
> lot of effort into trying to avoid it some of the time isn't worth it.
<
Each of my major and minor instruction groups has at least ½ of its
group unencoded. This is a benefit in that it enable seamless growth
into the future.
>
> 3) Normally, getting an instruction that can be replaced with one of the
> shorter instructions that leaves room for the decode field... is not too
> difficult if the code is written with several threads interlaced, using
> different subsets of the 32 available registers.
>
> It's intended for code to be written like that, and usually the register-to-register
> instructions can be shrunk this way without problems, and they should outnumber
> the memory-reference instructions by far.
>
> These three... workarounds... or points... suggest I may be worrying about
> a non-problem. But certainly the complexity of the suite of offerings provided
> for block header types could be off-putting to some taking a look at the ISA.
>
> Of course, the header scheme is much more simple than it *had* been in
> previous iterations of Concertina II.
>
> Now, all there is - is this:
>
> 1) A 32-bit header, which offers the various special functions that need a
> header;
>
> 2) A 16-bit header - 32 bits, with the header plus a 16-bit instruction - if
> all you need is one of the fancy features, not two of them;
>
> 3) A shrunken version of the 32-bit instruction set, if all you need is the
> 3-bit "decode" field which allows pseudo-immediates, and want to minimize
> the overhead price paid for that;
>
> 4) One of the fancy options if header styles (1) or (2) are chosen put
> some information formerly put in the header - and making the list of
> possible header formats long and complicated - in the instructions
> instead. Since I have created a shortened form of the instructions,
> I use it to solve the problem of putting either five bits of predication information
> or three bits of dependency information with every instruction.
>
> How do I do that with a shortened form of the instruction that gives extra space
> only for a three-bit decode field?
<
Get the compiler running and read 100,000 lines of ASM from the compiler
and make adjustments to make the compiled code better.
>
> Well, those shortened instructions only got to take up 1/8 of the total opcode
> space of the regular instruction set. So if I mark instruction slots that instead
> must have one of those instructions with the special meaning for that field,
> that's three extra bits, making six bits, which is just what I need.
>
> It's vastly simpler than what went before.
>
> But it's still clearly not simple _enough_. Or at least I have the nagging
> feeling that it's not simple enough.
>
> Explaining that certain features are for optimized VLIW-style code, and
> are not useful otherwise would... help. A little.
>
> Perhaps I just have to reconcile myself to the fact that if I'm trying
> to do more than should be (or is) possible, I'm not going to be able to do it *well*.
<
I got to this point with your stuff 3 years ago.
>
> But I keep hoping there is some solution I'm overlooking that will
> make it all make sense.
>
> John Savard

On Sunday, March 12, 2023 at 5:35:48 AM UTC-5, Thomas Koenig wrote:
> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > 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.
> >
> > On the one hand, I've just discovered that my normal 32-bit instructions,
> > since they don't use the ones starting with 1110 and 1111, and they also
> > use only half of the instructions of the form 0...1... would actually fit together
> > in 31 bits - so a CISC version of the same instruction set, where the 16-bit
> > instructions start with 0, and the 32-bit instructions start with 1, is possible.
> >
> > On the other hand, trying to squeeze more into a given space than is reasonable
> > is... not a bug, but an intended feature, if I can succeed in doing so.
> That would be a problem if anybody decided to extend your ISA at a later
> date.
>
> Look at POWER, where they ran out of encoding space and had to
> restrict load and stores to their vector registers to indexed loads,
> so they have to waste^H^H^H^H^Huse a register for loading a constant,
> then do the indexed load.
> > But there _is_ one price I am paying for doing so that I don't find acceptable,
> > and in my opinion is the worst flaw of the Concertina II architecture.
> >
> > I'm using multiple options for indicating the number of instruction slots not
> > to decode in a block.
> >
> > The intent is to, by offering these options, reduce to an absolute minimum the
> > amount of overhead this imposes for code th at needs unused instruction slots -
> > because some instructions have pseudo-immediate values.
> >
> > But it appears to make it extremely complicated for a compiler to generate
> > code that would use those options well.
> I don't suppose you have ever tried writing a compiler for your
> architecture.
>
> Maybe you should try writing an assembler first - that also lets you
> know a lot about the quirks of your architecture.
> > I think there are three ways to approach code generation for the system that
> > would be manageable:
> >
> > 1) Don't use the base registers that are for 64K segments. Use the one base
> > register that supports a 32K segment as the main one, and the ones for 4K
> > segments for everything else.
> Hm. You may want large offsets for
<
Offsets of 32-bits and 64-bits solves all of this problem space.
>
> - the stack pointer
> - the frame pointer
> - the PC, for PC-relative stuff
> - The Global Offset Table (GOT)
> - The Procedure Linkage Table (PLT)
>
> One register does not sound like enough.
<
Zero registers is perfect !!
<
> > That way, the special instructions that leave room for a 3-bit offset field
> > are nearly always usable, and so the compiler succeeds in efficiently
> > lowering overhead to an absolute minimum.
> >
> > 2) Be content with some wasted space; if it's unavoidable, putting a
> > lot of effort into trying to avoid it some of the time isn't worth it.
> >
> > 3) Normally, getting an instruction that can be replaced with one of the
> > shorter instructions that leaves room for the decode field... is not too
> > difficult if the code is written with several threads interlaced, using
> > different subsets of the 32 available registers.
> Sounds very hairy, and will need a very special register allocator.
> Have you looked into the algorithms needed for that?
<
Recently, I ran into 5 numerical subroutines where My 66000 with a single
unified set of 32-registers does not need spill/fill code whereas RISC-V
with 32-registers for ints and pointers and another 32-registers for FP
does end up spilling and filling !! In this case it was all down to universal
constants--in the form of FP constants. This saved 9 registers not being
used to hold constants or addresses to constant arrays, leaving plenty
of registers to perform the calculations.

On 3/12/2023 5:35 AM, Thomas Koenig wrote:
> Quadibloc <jsavard@ecn.ab.ca> schrieb:
>> 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.
>>
>> On the one hand, I've just discovered that my normal 32-bit instructions,
>> since they don't use the ones starting with 1110 and 1111, and they also
>> use only half of the instructions of the form 0...1... would actually fit together
>> in 31 bits - so a CISC version of the same instruction set, where the 16-bit
>> instructions start with 0, and the 32-bit instructions start with 1, is possible.
>>
>> On the other hand, trying to squeeze more into a given space than is reasonable
>> is... not a bug, but an intended feature, if I can succeed in doing so.
>
> That would be a problem if anybody decided to extend your ISA at a later
> date.
>
> Look at POWER, where they ran out of encoding space and had to
> restrict load and stores to their vector registers to indexed loads,
> so they have to waste^H^H^H^H^Huse a register for loading a constant,
> then do the indexed load.
>

I suspect POWER was still not quite as bad as SuperH in these areas.
Nearly every (non 32-bit) load/store needs an indexed form (for 32-bit,
a displacement form exists for 0..15).

Though, one could argue, since the index was not scaled and hard-wired
to R0, array indexing wasn't ideal either.
short *arr;
...
j=arr[i];
Being, say:
MOV R9, R0
ADD R0, R0 //shift R0 left by 1 bit
MOV.W @(R0, R8), R10

Whereas, say:
j=arr[11];
Would be:
MOV 22, R0
MOV.W @(R0, R8), R10

>
>> But there _is_ one price I am paying for doing so that I don't find acceptable,
>> and in my opinion is the worst flaw of the Concertina II architecture.
>>
>> I'm using multiple options for indicating the number of instruction slots not
>> to decode in a block.
>>
>> The intent is to, by offering these options, reduce to an absolute minimum the
>> amount of overhead this imposes for code th at needs unused instruction slots -
>> because some instructions have pseudo-immediate values.
>>
>> But it appears to make it extremely complicated for a compiler to generate
>> code that would use those options well.
>
> I don't suppose you have ever tried writing a compiler for your
> architecture.
>
> Maybe you should try writing an assembler first - that also lets you
> know a lot about the quirks of your architecture.
>

In my case, I considered some alternate encodings, wanting to try to fit
everything I wanted into a 32 bit encoding.

Say, what I might have wanted:
64 GPRs;
3 predicate bits;
Bundling;
Ability to use the above in any combination;
Ability to still have 16-bit ops.

Eventually, I failed, so took a more conservative option:
Take my existing encoding, but have an alternate mode which drops 16-bit
encodings but allows all 64 GPRs to be orthogonal.

Does add a limitation:
Still only 1 predicate bit (SR.T);
The PrWEX cases "OP?T | OP2" still only cover a subset of the ISA;
...

So, for example:
ADD?T 0x1234, R4 | ADD 0x5678, R5
Can't be encoded.

But, with XG2, one can encode, say:
ADD?T R36, 0x123, R44 | ADD 0x5678, R45
Which is N/E in the baseline encoding.

But, with code density that is a little worse due to the loss of 16-bit
ops. Still debatable if this a good tradeoff in the general case.

It would make more sense for a GPU-like core.

As-is, my considered encodings for things like:
PMUL.H Rm, Imm56vfp, Rn

Were just sorta using jumbo prefixes on the SHxD.x instructions, noting
that since a jumbo-encoded shift constant does not make sense, a few
FP-Imm and Vector-imm instructions could be shoved in there.

For many other ops, the Jumbo prefixes merely make the immediate bigger,
rather than change type of instruction. However, shift instructions are
special in that a larger immediate simply does not make sense, so this
encoding space is available (though, does also imply necessarily
allowing the use of the "3RI Imm57" jumbo-encodings; which had thus far
been in a gray area).

Say, JumboImm+Op:
FADD Rm, Imm32fp, Rn //Imm32fp converted to Binary64 on encode
FMUL Rm, Imm32fp, Rn //Imm32fp converted to Binary64 on encode
PADD.F Rm, Imm32fv, Rn //Imm 2x Fp16->2x Fp32, SIMD 2x Binary32
PMUL.F Rm, Imm32fv, Rn //Imm 2x Fp16->2x Fp32, SIMD 2x Binary32
And, JumboImm+JumboImm+Op:
PADD.H Rm, Imm56fv, Rn //4x Binary16 (Imm S.E5.F8)
PMUL.H Rm, Imm56fv, Rn //
PADDSH.H Rm, Imm48fv8sh, Rn //Shuffle (Imm S.E5.F6.I2)
PMULSH.H Rm, Imm48fv8sh, Rn //Shuffle
PMACSH.H Rm, Imm48fv8sh, Rn //? Shuffle (Imm S.E5.F6.I2)

Where, it is "tempting" to consider the possibility of merging shuffles
into the FP-SIMD ops to avoid needing separate shuffle ops. Still on the
fence about this.

This might also apply to 3R SIMD ops, which could possibly also gain a
shuffle mask via a 64-bit encoding:
PADD.H Rm, Ro, Imm8, Rn //4x Binary16
PADDX.F Xm, Xo, Imm8, Xn //4x Binary32
...
Would use a similar encoding to that used for the rounding-mode forms,
but likely with the 'V.w' bit indicating that the Imm8 field is
interpreted as a shuffle rather than a rounding mode.

So, 'V' field (wssi):
000z: Rounding Mode
0zzz: Reserved (when 'ss' is not 00)
100z: Shuffle, Reserved
101z: Shuffle, Apply to Rm field
110z: Shuffle, Apply to Ro field
111z: Shuffle, Apply to both Rm and Ro fields

Well, and/or:
000z: Rounding Mode
001z: Shuffle, Apply to Rm/Rs field
010z: Shuffle, Apply to Ro/Rt field
011z: Shuffle, Apply to both Rm and Ro fields
1zzz: Reserved

PMAC is also possible, but would require adding MAC support to the
low-precision FPU. I have come up with a possible way to approach doing
it in a 3-cycle latency, but whether it would be viable for full
Binary32 precision is debatable.

Ideally, would want a single unit that can do:
FADD + FMUL + FMAC
Still has a 3-cycle latency (and can pass timing);
Can do full Binary32;
Not overly expensive.
But, not entirely sure all this is achievable.

Likely process would look like:
Cycle 1:
Shuffle and convert values as needed;
Unpack Rn, Rs, and Rt elements;
Find ExpMul, as ((ExpRs+ExpRt)-127);
Find ShrRn as clamp(ExpMul-ExpRn, 0, 63);
Find ShrMul as clamp(ExpRn-ExpMul, 0, 63);
Calculate FraRs*FraRt -> FraMul
Cycle 2:
Shift FraRn right by ShrRn into FraRnA;
Shift FraMul right by ShrMul into FraMulA;
Add/Subtract FraRnA and FraMulA into FraRes.
Cycle 3:
Invert FraRes if needed;
Adder renormalization step;
Feed through another converter stage (Binar32 to Binary16);
Result goes (directly) to the output.

If the current low-precision FADD unit, the renormalization begins
directly after the values are added. This leaves cycle 3 mostly to work
with the output value (which goes fairly directly into the register
forwarding logic, which is a much tighter pathway).

Though, another option would be to keep the renormalization still in
stage 2 (since it sharing a cycle with the the adder is likely "less
bad" than it sharing the a cycle with the register forwarding).

Further increasing pipeline length isn't really all that viable at the
moment (and adding stall cycles for SIMD FMAC would also kinda defeat
the point of adding it).

Likely drawback is that these instructions would be likely having a
fairly limited set of use-cases (where they would make much difference).

Things these could effect:
Neural nets;
Code making heavy use of quaternion operations or vector cross product
(mostly in relation to the 3R shuffle ops);
....

>> I think there are three ways to approach code generation for the system that
>> would be manageable:
>>
>> 1) Don't use the base registers that are for 64K segments. Use the one base
>> register that supports a 32K segment as the main one, and the ones for 4K
>> segments for everything else.
>
> Hm. You may want large offsets for
>
> - the stack pointer
> - the frame pointer
> - the PC, for PC-relative stuff
> - The Global Offset Table (GOT)
> - The Procedure Linkage Table (PLT)
>
> One register does not sound like enough.
>

Wait, was he proposing going away from a flat address space?...

Granted, I have a "not quite flat" address space, but given this only
effects address spaces larger than 256TB (which I suspect is sufficient
for probably 99.9999% of programs that are likely to exist in the
foreseeable future), I think it is OK.

It seems likely that memory outside the low 48 bits is mostly (if
anything) likely to be an OS scale feature (say, mapping processes into
a large contiguous virtual address space, so that the kernel can more
directly access memory within each program).

On Sunday, March 12, 2023 at 10:32:19 AM UTC-6, Quadibloc wrote:

> Calendar arithmetic is where the second-from-last digit of
> a packed vigesimal number is instead octadecimal.

Some sundials bear the cheerful motto, "I only count the
sunny hours". In this case, my architecture could say "I
only count the non-epagomenal days" - Uayeb would be
right out.

At least there *are* indigenous people in Mexico and Central
America who count themselves as descendants of the Maya.

In the case of the market for packed sexagesimal arithmetic,
while there are both the Assyrian Christians and the Yezidi out
there, I would probably have to admit that's a lost cause.

John Savard

On Sunday, March 12, 2023 at 12:35:59 PM UTC-6, MitchAlsup wrote:
> On Sunday, March 12, 2023 at 3:54:16 AM UTC-5, Quadibloc wrote:

> > Perhaps I just have to reconcile myself to the fact that if I'm trying
> > to do more than should be (or is) possible, I'm not going to be able to do it *well*.

> I got to this point with your stuff 3 years ago.

I don't think I've been unconscious of the issue for the last three years.

I do think I've gotten tantalizingly close to achieving the kind of improvement that
would make _me_ feel more satisfied, though. Not that _you_ would necessarily
notice any difference in what would no doubt remain quite inelegant.

John Savard

On Sunday, March 12, 2023 at 4:20:19 PM UTC-5, Quadibloc wrote:
> On Sunday, March 12, 2023 at 12:35:59 PM UTC-6, MitchAlsup wrote:
> > On Sunday, March 12, 2023 at 3:54:16 AM UTC-5, Quadibloc wrote:
>
> > > Perhaps I just have to reconcile myself to the fact that if I'm trying
> > > to do more than should be (or is) possible, I'm not going to be able to do it *well*.
>
> > I got to this point with your stuff 3 years ago.
> I don't think I've been unconscious of the issue for the last three years..
>
> I do think I've gotten tantalizingly close to achieving the kind of improvement that
> would make _me_ feel more satisfied, though. Not that _you_ would necessarily
> notice any difference in what would no doubt remain quite inelegant.
<
I can tell you that My 66000 is 10%-15% better AFTER Brian got his compiler up
and running and we played both ends towards the middle; while gaining elegance
and loosing almost nothing. That is 10%-15% fewer instructions are needed to
embody the semantic content of compiled subroutines, and the data associated
with those subroutines.
<
I can suggest you you too will fail to achieve this kind of gain if you don't get a
compiler up and running and see what the compiler uses from your ISA, and
then optimize the ISA for what the compiler is using.
>
> John Savard