Quadibloc wrote:
> On Thursday, June 10, 2021 at 7:35:07 AM UTC-6, EricP wrote:
>
>> PC should be illegal as a destination,
>> Should use branch instructions.
>
> Why not do it the other way around, and save an opcode?
> The hardware could know that loading the PC _is_ a branch,
> and therefore to take the necessary precautions with the
> pipeline when it happens.
>
> John Savard

As I mentioned in my other reply, my concern is in allowing
any integer or logic OP to write into the PC.

To minimize pipeline bubbles, Decode needs to calculate branch addresses
early and forward changes to Fetch ASAP. If that is restricted to only
doing a 64-bit ADD then that can be done in parallel with the decode.
Then if the instruction is a branch or jump, Decode just sends
a pulse to Fetch to let it know it has a new address.

If however you toss in all sundry operations, you'd need a full
ALU inside decode, the ALU operation code for which comes from
Decode and so is serially dependent on Decode.
More expensive ALU serially dependent on decode means longer Decode stage.
Now since no one would do this to Decode, you wind up doing this
in the real ALU which is at least 2 pipeline stages further on.
And since Decode stalls Fetch and Decode as soon as it sees a write to R7,
it therefore bakes the pipeline bubble into your ISA
for functionality that no one needs or would use.

It violates my "Is it necessary?" smell detector.
When optimizing the design and asked "Is there anything left to remove?"
I reply "Yes, this smelly bit over there."

On 6/11/2021 10:08 AM, EricP wrote:
> Quadibloc wrote:
>> On Thursday, June 10, 2021 at 7:35:07 AM UTC-6, EricP wrote:
>>
>>> PC should be illegal as a destination, Should use branch instructions.
>>
>> Why not do it the other way around, and save an opcode?
>> The hardware could know that loading the PC _is_ a branch,
>> and therefore to take the necessary precautions with the
>> pipeline when it happens.
>>
>> John Savard
>
> As I mentioned in my other reply, my concern is in allowing
> any integer or logic OP to write into the PC.
>

Most likely option is that any op storing to PC is treated like a
branch, rather than PC behaving like a conventional register.

Something like @PC+ addressing would likely need to be handled as a
special case in the instruction fetch/decode logic, effectively treating
it like a longer instruction.

> To minimize pipeline bubbles, Decode needs to calculate branch addresses
> early and forward changes to Fetch ASAP. If that is restricted to only
> doing a 64-bit ADD then that can be done in parallel with the decode.
> Then if the instruction is a branch or jump, Decode just sends
> a pulse to Fetch to let it know it has a new address.
>
> If however you toss in all sundry operations, you'd need a full
> ALU inside decode, the ALU operation code for which comes from
> Decode and so is serially dependent on Decode.
> More expensive ALU serially dependent on decode means longer Decode stage.
> Now since no one would do this to Decode, you wind up doing this
> in the real ALU which is at least 2 pipeline stages further on.
> And since Decode stalls Fetch and Decode as soon as it sees a write to R7,
> it therefore bakes the pipeline bubble into your ISA
> for functionality that no one needs or would use.
>
> It violates my "Is it necessary?" smell detector.
> When optimizing the design and asked "Is there anything left to remove?"
> I reply "Yes, this smelly bit over there."
>

One can capture PC in the pipeline, and so any value seen by the ALU ops
are (potentially) several cycles out of date relative to fetch/decode.

On Friday, June 11, 2021 at 10:08:38 AM UTC-5, EricP wrote:

> As I mentioned in my other reply, my concern is in allowing
> any integer or logic OP to write into the PC.
>
> To minimize pipeline bubbles, Decode needs to calculate branch addresses
> early and forward changes to Fetch ASAP. If that is restricted to only
> doing a 64-bit ADD then that can be done in parallel with the decode.
> Then if the instruction is a branch or jump, Decode just sends
> a pulse to Fetch to let it know it has a new address.
<
At this point, at best, you already have a delay slot (bubble) in the pipeline.
But this is about the best one can do until one starts having wider FETCH
and a means to scan forward for branches and perform the ADD and
fetch the target of the branch before one known whether the branch will
be taken or not.
>
> If however you toss in all sundry operations, you'd need a full
> ALU inside decode, the ALU operation code for which comes from
> Decode and so is serially dependent on Decode.
<
Yes, there is a state in the "front end" (Or in DEC parlance:: the I-Box) known
as "Unknown Fetch Address". You can build predictors for these: Jump
Prediction table, Call return Stack, Method Call Table,... so the front end
does not dry up.
<
Even with JMP instructions you have this state:: consider a LD->JMP
that takes a cache miss--you are not in a position to FETCH anything
until the LDed data arrives (without prediction).
<
In effect the "front end" is a calculation unit and the BR/JMP instructions
are delivering operands to this FETCH calculation unit. That FETCH calcu-
lation unit is delivering its results to the DECODE calculation unit,.....
<
All you have done is to make the "front end" calculatiion units IDENTICAL
to the "back end" calculations units {INT, FADD, FMAC, MEM,...} It actually
simplifies and unifies the micro architecture !! The 2 calculation units in
the front end play the same game with the same reservation stations as
the calculation units in the back end !!
<
> More expensive ALU serially dependent on decode means longer Decode stage.
> Now since no one would do this to Decode, you wind up doing this
> in the real ALU which is at least 2 pipeline stages further on.
<
{Quote :: Spock from "Wrath of Kahan", 'Captain, he is thinking 2-dimensionally'}
<
Yes, in order to meet the timing of feeding a branch adder back as the fetch
address, the input to that adder needs to be found in a constant place in the
instruction. I have seen microarchitectures where if the register for the JMP
instruction is on the forwarding path the pipeline eats a bubble due to this
same kind of pipeline timing.
<
But if you consider the front end as 2 calculation units, Fetch waits for a new
address to show up, and then streams instructions to the decode unit. The
decode unit waits for instructions to arrive. Then the branch unit figures out
which stages of the pipeline need to get wiped clean. And the entire machine
has been unified.
<
> And since Decode stalls Fetch and Decode as soon as it sees a write to R7,
> it therefore bakes the pipeline bubble into your ISA
> for functionality that no one needs or would use.
<
The decoder looks for special cases:: in the PDP-11's case, a MOV PC,#immed
transfers control to anywhere in memory, but at least there is a JMP instruction
that does the same thing.
>
> It violates my "Is it necessary?" smell detector.
<
Its lack violates my "can you get it done without adding an instruction" detector.
That is: RISC machines do not have a NEG instruction because one can always
perform a SUB Rd,R0,Rs and get the same result without adding an instruction!
My 66000 can do this with a 5-bit immediate variant ADD Rd,#0,-Rs since I don't
have a register filled with zeros.
<
> When optimizing the design and asked "Is there anything left to remove?"
> I reply "Yes, this smelly bit over there."
<
But if you have to add something to remove something else--have you actually
made forward progress? You are adding a JMP instruction to get rid of the
IP=value which is already present.

On Friday, June 11, 2021 at 5:59:09 AM UTC-6, chris wrote:

> Opinions may vary, but if you were an assembler programmer back in the
> days when memory was tight and machines were slow, the fact that
> condition codes are set with many instructions, was of great
> benefit.

Oh, I agree that condition codes are a good thing. I'm not too sympathetic
to architectures like the Alpha and RISC-V which completely dispense with
them.

However, if _every_ operate instruction changes the condition codes, you
have to put the conditional branch right after the operate instruction that
affects it. This creates a dependency, and for branches especially that's a
bad thing.

So, the way many RISC instruction sets have done it (the PowerPC taking
it to a more elaborate level) in a high-performance instruction set, I include
a bit to enable or disable setting the condition codes in instructions that can
set them.

That loses a bit of opcode space, but it doesn't lose the advantages you
mention.

John Savard

On Friday, June 11, 2021 at 9:01:05 AM UTC-6, MitchAlsup wrote:

> After studying the situation overnight, I agree with EricP that
> auto-inc/dec deferred is not worthy of inclusion--which leads
> the way to enable base+index addressing.

Getting rid of _one_ addressing mode would presumably only free
up one bit from each mode field; gaining two bits would only let
you have a rather short base register field.

But I'm not surprised your ISA take is much different from mine.

John Savard

On Friday, June 11, 2021 at 1:30:22 PM UTC-5, Quadibloc wrote:
> On Friday, June 11, 2021 at 9:01:05 AM UTC-6, MitchAlsup wrote:
>
> > After studying the situation overnight, I agree with EricP that
> > auto-inc/dec deferred is not worthy of inclusion--which leads
> > the way to enable base+index addressing.
<
> Getting rid of _one_ addressing mode would presumably only free
> up one bit from each mode field; gaining two bits would only let
> you have a rather short base register field.
<
It gets rid of @(R++) and @(--R), I count 2.
This leaves me room for [Rb+Ri+disp] and *[Rb+Ri+disp], but perhaps
the second should not make the cut.
>
> But I'm not surprised your ISA take is much different from mine.
<
You mean aside from hating condition codes ?
<
Spend a year writing a compiler and revisit you like of condition codes.
>
> John Savard

On Friday, June 11, 2021 at 9:08:38 AM UTC-6, EricP wrote:

> As I mentioned in my other reply, my concern is in allowing
> any integer or logic OP to write into the PC.

I certainly agree it's useless for the result of, say, a divide
instruction to be stored in the program counter. But that's
a small price to pay (a waste of opcode space) if the benefits
of making the program counter a register are desired - eliminating
the need for a special instruction to return from a subroutine and
so on.

With base-index addressing, though, just making the displacement
zero lets you return from a subroutine, so I question making the PC
a register because I don't really think there is much in the way of
real benefits - and the price of *losing a register* is a big one,
especially when you only have eight registers.

John Savard

On Friday, June 11, 2021 at 1:28:30 PM UTC-5, Quadibloc wrote:
> On Friday, June 11, 2021 at 5:59:09 AM UTC-6, chris wrote:
>
> > Opinions may vary, but if you were an assembler programmer back in the
> > days when memory was tight and machines were slow, the fact that
> > condition codes are set with many instructions, was of great
> > benefit.
> Oh, I agree that condition codes are a good thing. I'm not too sympathetic
> to architectures like the Alpha and RISC-V which completely dispense with
> them.
>
> However, if _every_ operate instruction changes the condition codes, you
> have to put the conditional branch right after the operate instruction that
> affects it. This creates a dependency, and for branches especially that's a
> bad thing.
<
In the days condition codes made sense, the machines were using 4-10 cycles
per instruction, so putting the BC immediately after the Operate instruction
was dé rigueur.
<
One of the things we learned in the early RISC days was this one either wanted
no condition codes, or to use a bit to say when the condition codes were going
to be used--in effect CC write elision. Using that bit is bad for entropy.
>
> So, the way many RISC instruction sets have done it (the PowerPC taking
> it to a more elaborate level) in a high-performance instruction set, I include
> a bit to enable or disable setting the condition codes in instructions that can
> set them.
>
> That loses a bit of opcode space, but it doesn't lose the advantages you
> mention.
<
I still fail to see where cc gain anything (with proper branch support), plus
I see many places where a vector of comparand bits is better than a CC
from a CMP instruction (especially with the requirements of IEEE 754).
>
> John Savard

On Friday, June 11, 2021 at 1:36:16 PM UTC-5, Quadibloc wrote:
> On Friday, June 11, 2021 at 9:08:38 AM UTC-6, EricP wrote:
>
> > As I mentioned in my other reply, my concern is in allowing
> > any integer or logic OP to write into the PC.
<
> I certainly agree it's useless for the result of, say, a divide
> instruction to be stored in the program counter. But that's
> a small price to pay (a waste of opcode space) if the benefits
> of making the program counter a register are desired - eliminating
> the need for a special instruction to return from a subroutine and
> so on.
<
For example: consider the return address stored on the stack
<
MOV IP,(SP++)
<
And you don't have to waste a register reading RA from the stack before
transferring control. I use this trick in exit EXIT instruction.
>
> With base-index addressing, though, just making the displacement
> zero lets you return from a subroutine, so I question making the PC
> a register because I don't really think there is much in the way of
> real benefits - and the price of *losing a register* is a big one,
> especially when you only have eight registers.
>
> John Savard

On 6/11/2021 11:42 AM, MitchAlsup wrote:
> On Friday, June 11, 2021 at 1:28:30 PM UTC-5, Quadibloc wrote:
>> On Friday, June 11, 2021 at 5:59:09 AM UTC-6, chris wrote:
>>
>>> Opinions may vary, but if you were an assembler programmer back in the
>>> days when memory was tight and machines were slow, the fact that
>>> condition codes are set with many instructions, was of great
>>> benefit.
>> Oh, I agree that condition codes are a good thing. I'm not too sympathetic
>> to architectures like the Alpha and RISC-V which completely dispense with
>> them.
>>
>> However, if _every_ operate instruction changes the condition codes, you
>> have to put the conditional branch right after the operate instruction that
>> affects it. This creates a dependency, and for branches especially that's a
>> bad thing.
> <
> In the days condition codes made sense, the machines were using 4-10 cycles
> per instruction, so putting the BC immediately after the Operate instruction
> was dé rigueur.
> <
> One of the things we learned in the early RISC days was this one either wanted
> no condition codes, or to use a bit to say when the condition codes were going
> to be used--in effect CC write elision. Using that bit is bad for entropy.
>>
>> So, the way many RISC instruction sets have done it (the PowerPC taking
>> it to a more elaborate level) in a high-performance instruction set, I include
>> a bit to enable or disable setting the condition codes in instructions that can
>> set them.
>>
>> That loses a bit of opcode space, but it doesn't lose the advantages you
>> mention.
> <
> I still fail to see where cc gain anything (with proper branch support), plus
> I see many places where a vector of comparand bits is better than a CC
> from a CMP instruction (especially with the requirements of IEEE 754).

How often is more than one bit subsequently selected from that bit vector? -

On Friday, June 11, 2021 at 7:16:42 PM UTC-5, Ivan Godard wrote:
> On 6/11/2021 11:42 AM, MitchAlsup wrote:
> > On Friday, June 11, 2021 at 1:28:30 PM UTC-5, Quadibloc wrote:
> >> On Friday, June 11, 2021 at 5:59:09 AM UTC-6, chris wrote:
> >>
> >>> Opinions may vary, but if you were an assembler programmer back in the
> >>> days when memory was tight and machines were slow, the fact that
> >>> condition codes are set with many instructions, was of great
> >>> benefit.
> >> Oh, I agree that condition codes are a good thing. I'm not too sympathetic
> >> to architectures like the Alpha and RISC-V which completely dispense with
> >> them.
> >>
> >> However, if _every_ operate instruction changes the condition codes, you
> >> have to put the conditional branch right after the operate instruction that
> >> affects it. This creates a dependency, and for branches especially that's a
> >> bad thing.
> > <
> > In the days condition codes made sense, the machines were using 4-10 cycles
> > per instruction, so putting the BC immediately after the Operate instruction
> > was dé rigueur.
> > <
> > One of the things we learned in the early RISC days was this one either wanted
> > no condition codes, or to use a bit to say when the condition codes were going
> > to be used--in effect CC write elision. Using that bit is bad for entropy.
> >>
> >> So, the way many RISC instruction sets have done it (the PowerPC taking
> >> it to a more elaborate level) in a high-performance instruction set, I include
> >> a bit to enable or disable setting the condition codes in instructions that can
> >> set them.
> >>
> >> That loses a bit of opcode space, but it doesn't lose the advantages you
> >> mention.
> > <
> > I still fail to see where cc gain anything (with proper branch support), plus
> > I see many places where a vector of comparand bits is better than a CC
> > from a CMP instruction (especially with the requirements of IEEE 754).
<
> How often is more than one bit subsequently selected from that bit vector? -
<
A few percent--not enough to justify.
<
But along with the 2 equality, 4 signed, 4 unsigned relations, you have many more
things one can detect NEGMAX, SPOSMAX, UPOSMAX, 0<x<y, 0<=x<y,0<x<=y,0<=x<=y;
Any Byte 0, Any half 0, and Word 0,on the integer side along with performing a floating
point classify (SNaN, QNaN, -INFINTY, +INFINITY, -normal,-denormal,zero,+denormal
+normal) to make FP functions easier to write.
<
Now while these are not high ticket items the do reduce the complexity of meeting
IEEE 754 2019 defined semantics.
<
In addition, how, with a condition code, are you going to ask "has any memory interference
occurred" when performing ATOMIC events ?
<
You really want to hook "branches" up to almost anything that can cause a control transfer
in your architecture. 2-bit-to-5-bit condition codes are hopeless here.
<

Quadibloc <jsavard@ecn.ab.ca> writes:
>However, if _every_ operate instruction changes the condition codes, you
>have to put the conditional branch right after the operate instruction that
>affects it. This creates a dependency, and for branches especially that's a
>bad thing.

IMO it's a good thing. Then you know that the cc comes from the
previous non-branch instruction, not from some arbitrary far
instruction. You can fuse the conditional branch(es) with the
condition-generating instructions in all cases, and don't have to
reify the cc in a flags register. It certainly makes emulators easier
to implement, and, I expect, also CPUs.

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

On Friday, June 11, 2021 at 12:42:27 PM UTC-6, MitchAlsup wrote:

> I still fail to see where cc gain anything (with proper branch support), plus
> I see many places where a vector of comparand bits is better than a CC
> from a CMP instruction (especially with the requirements of IEEE 754).

You're the expert, so no doubt you're right.

And for vector instructions, yes, they create a vector of mask bits based on
a selected condition, if requested, and don't touch the condition codes, in the ISAs
I've proposed.

But for scalar instructions, I lack the imagination to see how one can do a multi-word
add with carry propagation without using silly instructions that do the add a second
time, branch at the same time as arithmetic, or do other bad things that are wasteful.
Condition codes are the traditional approach people are familar with.

Condition code elision solves... the _serious_ problems with condition codes, so
after I include that, I stop worrying about them. Maybe that's wrong. You've noted
they're bad for compilers.

I suppose you mean certain kinds of compilers - those that first generate pseudocode
which is later converted to code for the target machine. The pseudocode doesn't deal
in awkward constructs like condition codes, so they're not natural for that kind of
compiler architecture.

John Savard

On Friday, June 11, 2021 at 11:46:01 PM UTC-6, Anton Ertl wrote:

> IMO it's a good thing. Then you know that the cc comes from the
> previous non-branch instruction, not from some arbitrary far
> instruction. You can fuse the conditional branch(es) with the
> condition-generating instructions in all cases, and don't have to
> reify the cc in a flags register. It certainly makes emulators easier
> to implement, and, I expect, also CPUs.

That's a dependency. You want to do other instructions between
the operation and the branch. So it forces you to implement full
OoO for efficiency, which is why RISC architectures didn't do it
that way; they either had a bit to turn off setting the condition
codes, or they dispensed with condition codes entirely.

John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:
>On Friday, June 11, 2021 at 11:46:01 PM UTC-6, Anton Ertl wrote:
>
>> IMO it's a good thing. Then you know that the cc comes from the
>> previous non-branch instruction, not from some arbitrary far
>> instruction. You can fuse the conditional branch(es) with the
>> condition-generating instructions in all cases, and don't have to
>> reify the cc in a flags register. It certainly makes emulators easier
>> to implement, and, I expect, also CPUs.
>
>That's a dependency. You want to do other instructions between
>the operation and the branch.

What makes you think so? The typical code I see has the branch right
after the condition-code-setting instruction. Intel even optimizes
this case by combining e.g., an add and a following conditional branch
into one uop, and I expect that they are not the only ones.

>So it forces you to implement full
>OoO for efficiency, which is why RISC architectures didn't do it
>that way; they either had a bit to turn off setting the condition
>codes, or they dispensed with condition codes entirely.

I don't expect that in-order SPARCs and in-order ARMs run any slower
if you set the condition code in every instruction. Doing in-order
and setting cc on every instruction is easy.

OoO is more interesting: If you manage to treat the
condition-code-generating instruction and the consuming instruction(s)
as a unit, you don't even need to have condition codes in the
microarchitecture. If you don't, you may be able to make do with
fewer physical condition code registers if fewer instructions set
condition codes. Or maybe not: If every instruction overwrites the
previous condition code register, many cc registers need to be
allocated, but they are also released quickly.

My guess is that hardware implementation concerns are not the reason
for making cc-setting optional. Instead, compiler implementation
concerns are: If every instruction is cc-setting, spill-code placement
and placement of move instruction becomes harder; maybe there is also
the hope that the compiler can do better scheduling of code if it can
move non-cc-setting instructions between a cc-setting and a cc-reading
instruction, but I don't think that hope is fulfilled:

Looking for "b." (conditional branches depending on condition codes)
in an Aarch64 file generated from C code and one immediately
preceeding line, I see

189 b.

preceded by

134 cmp
14 cmn (compare negative)
5 tst
1 ccmp
1 subs
1 adds

22 non-cc-setting instructions (ldr, str, mov, add, ror)

If you are as obsessed with code density as our PDP-11 reinventors, do
you really want to waste a bit in many instructions for that?

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

On Saturday, June 12, 2021 at 5:40:10 AM UTC-6, Anton Ertl wrote:

> If you are as obsessed with code density as our PDP-11 reinventors, do
> you really want to waste a bit in many instructions for that?

Code density is very important, or, at least, in my designs I've treated it as
such. But it isn't everything. Speed is the most important thing.

And another goal of my design is to have a design that works in a wide
range of implementations; light-weight ones as well as heavyweight
ones. So while the design can benefit from being implemented with
out-of-order executiion, it has to be also suited to an in-order implementation
as well.

Thus, my PDP-11-like instruction set within the Concertina II ISA can only be
used in conjunction with a 32-bit header in every 256-bit block of code; code
density is reduced by this overhead. Only the primary instruction set, composed
only of 32-bit instructions, can be used without a header. The headers all lie
within unused opcode space in that instruction set.

This avoids having different modes for different instruction sets, so that executing
code in the wrong mode isn't available as a potential security flaw. So security also
takes precedence over code density.

John Savard

On 6/11/2021 6:24 PM, MitchAlsup wrote:
> On Friday, June 11, 2021 at 7:16:42 PM UTC-5, Ivan Godard wrote:
>> On 6/11/2021 11:42 AM, MitchAlsup wrote:
>>> On Friday, June 11, 2021 at 1:28:30 PM UTC-5, Quadibloc wrote:
>>>> On Friday, June 11, 2021 at 5:59:09 AM UTC-6, chris wrote:
>>>>
>>>>> Opinions may vary, but if you were an assembler programmer back in the
>>>>> days when memory was tight and machines were slow, the fact that
>>>>> condition codes are set with many instructions, was of great
>>>>> benefit.
>>>> Oh, I agree that condition codes are a good thing. I'm not too sympathetic
>>>> to architectures like the Alpha and RISC-V which completely dispense with
>>>> them.
>>>>
>>>> However, if _every_ operate instruction changes the condition codes, you
>>>> have to put the conditional branch right after the operate instruction that
>>>> affects it. This creates a dependency, and for branches especially that's a
>>>> bad thing.
>>> <
>>> In the days condition codes made sense, the machines were using 4-10 cycles
>>> per instruction, so putting the BC immediately after the Operate instruction
>>> was dé rigueur.
>>> <
>>> One of the things we learned in the early RISC days was this one either wanted
>>> no condition codes, or to use a bit to say when the condition codes were going
>>> to be used--in effect CC write elision. Using that bit is bad for entropy.
>>>>
>>>> So, the way many RISC instruction sets have done it (the PowerPC taking
>>>> it to a more elaborate level) in a high-performance instruction set, I include
>>>> a bit to enable or disable setting the condition codes in instructions that can
>>>> set them.
>>>>
>>>> That loses a bit of opcode space, but it doesn't lose the advantages you
>>>> mention.
>>> <
>>> I still fail to see where cc gain anything (with proper branch support), plus
>>> I see many places where a vector of comparand bits is better than a CC
>>> from a CMP instruction (especially with the requirements of IEEE 754).
> <
>> How often is more than one bit subsequently selected from that bit vector? -
> <
> A few percent--not enough to justify.
> <
> But along with the 2 equality, 4 signed, 4 unsigned relations, you have many more
> things one can detect NEGMAX, SPOSMAX, UPOSMAX, 0<x<y, 0<=x<y,0<x<=y,0<=x<=y;
> Any Byte 0, Any half 0, and Word 0,on the integer side along with performing a floating
> point classify (SNaN, QNaN, -INFINTY, +INFINITY, -normal,-denormal,zero,+denormal
> +normal) to make FP functions easier to write.
> <
> Now while these are not high ticket items the do reduce the complexity of meeting
> IEEE 754 2019 defined semantics.
> <
> In addition, how, with a condition code, are you going to ask "has any memory interference
> occurred" when performing ATOMIC events ?
> <
> You really want to hook "branches" up to almost anything that can cause a control transfer
> in your architecture. 2-bit-to-5-bit condition codes are hopeless here.
> <
>

Yes, but...

Besides branches, there are predicates, conversion to bool operand, and
SIMD to consider.

If the polycode is only used once, then the entropy cost of <CMP,
select> is the same as that of <select<CMP>> unless, as in traditional
CCs, the CMP is implicit in ordinary ops like MV and ADD. And I think we
agree that implicit CC setting is a bad idea.

So it costs no more to have lots of compare ops than to have one and a
selector. If you can fit them into the encoding, of course; three
quarters of the postings here are about fitting bits into encodings, and
it's such a waste of time because entropy is not the same thing as parse.

I agree that 2-5 bit CCs are hopeless. But why not make that 1-bit? And
if there must be SIMD, one bit per lane, governing only that lane?

On Saturday, June 12, 2021 at 7:48:04 AM UTC-6, Quadibloc wrote:
> On Saturday, June 12, 2021 at 5:40:10 AM UTC-6, Anton Ertl wrote:
>
> > If you are as obsessed with code density as our PDP-11 reinventors, do
> > you really want to waste a bit in many instructions for that?
> Code density is very important, or, at least, in my designs I've treated it as
> such. But it isn't everything. Speed is the most important thing.
>
> And another goal of my design is to have a design that works in a wide
> range of implementations; light-weight ones as well as heavyweight
> ones. So while the design can benefit from being implemented with
> out-of-order executiion, it has to be also suited to an in-order implementation
> as well.
>
> Thus, my PDP-11-like instruction set within the Concertina II ISA can only be
> used in conjunction with a 32-bit header in every 256-bit block of code; code
> density is reduced by this overhead. Only the primary instruction set, composed
> only of 32-bit instructions, can be used without a header. The headers all lie
> within unused opcode space in that instruction set.
>
> This avoids having different modes for different instruction sets, so that executing
> code in the wrong mode isn't available as a potential security flaw. So security also
> takes precedence over code density.

But despite allowing security and speed to take precedence over code density,
my Concertina II design does reflect a fanatical devotion to code density.

At least in one sense. Mitch Alsup would say that real concern over code density
means making the most common instructions the smallest.

While I think I _have_ made the most common instructions small, I've also devoted
attention to making other instructions as small as they could be, even if they are
likely to be rarely used.

The IBM 360 has register-to-register operand instructions that are 16 bits long?
All right, I have those.

The IBM 360 has memory-reference instructions that are 32 bits long, which have
full base-index addressing? All right, I have those.

The IBM 360 has memory to memory string and packed decimal instructions that
are 48 bits long? All right, I have those.

Did I tell you that the IBM 360 has 16 general registers, but I have 32?

Did I tell you that the IBM 360 uses 12-bit displacements for addressing, but I
use 16-bit displacements for addressing?

So essentially my code density goal was to achieve the *impossible*!

I did have to make compromises.

The 16-bit register to register operate instructions... allow one of the registers
to be arbitrarily picked from all 32, and the other is one of the eight in the same
subgroup of eight registers. Also, to make room in opcode space for other
instructions besides 16-bit ones, in most instruction formats, they can't set the
condition codes.

The 32-bit memory-reference instructions are load and store only, and they can
only address aligned operands (the famous SEL 32 trick of using the least significant
bits of the address to indicate the operand type is being used).

The 48-bit string and packed decimal instructions... like those of the 360, aren't
indexed, but in addition use alternate addressing modes with displacements shorter
than 16 bits. (Here, I use the IBM 360 Model 20 as an inspiration, to allow a 15-bit
displacement off of *one* base register, in addition to 12-bit displacements off of
of eight others.)

So while code density is not a goal that overrides everything else, a
lot of attention has been paid to making it possible to use short forms of
many types of instructions. Longer forms are available for the cases
the short forms don't cover, as that's better than using more than one
instruction.

John Savard

On Saturday, June 12, 2021 at 12:50:32 AM UTC-6, Quadibloc wrote:
> On Friday, June 11, 2021 at 12:42:27 PM UTC-6, MitchAlsup wrote:
>
> > I still fail to see where cc gain anything (with proper branch support), plus
> > I see many places where a vector of comparand bits is better than a CC
> > from a CMP instruction (especially with the requirements of IEEE 754).
> You're the expert, so no doubt you're right.
>
> And for vector instructions, yes, they create a vector of mask bits based on
> a selected condition, if requested, and don't touch the condition codes, in the ISAs
> I've proposed.
>
> But for scalar instructions, I lack the imagination to see how one can do a multi-word
> add with carry propagation without using silly instructions that do the add a second
> time, branch at the same time as arithmetic, or do other bad things that are wasteful.
> Condition codes are the traditional approach people are familar with.
>
> Condition code elision solves... the _serious_ problems with condition codes, so
> after I include that, I stop worrying about them. Maybe that's wrong. You've noted
> they're bad for compilers.
>
> I suppose you mean certain kinds of compilers - those that first generate pseudocode
> which is later converted to code for the target machine. The pseudocode doesn't deal
> in awkward constructs like condition codes, so they're not natural for that kind of
> compiler architecture.

On reflection, suppose I have two instructions which must set the condition code
for a future branch.

And some compiler optimization has put them in the... wrong order.

Now, I include in the Concertina II architecture, in *addition* to jump and branch
instructions which test the condition codes... an instruction that tests the condition
codes, and sets one of the flag bits used for *instruction predication*.

It has occured to me that to achieve - without the baggage that the PowerPC took
on - complete immunity to condition codes restricting what the compiler can do,
there is a missing class of instructions that I need to add to my architecture.

In addition to condition-code based conditional jump instructions... I need jump
instructions that use those flag bits originally envisaged as only for instruction
predication. (Of course, I _could_ predicate a jump instruction, but if I can avoid
the cost and awkwardness of choosing a block header just for that...)

John Savard

EricP wrote:
> Terje Mathisen wrote:
>> EricP wrote:
>>>
>>> So toss out auto inc/dec address modes and put in two instructions
>>>
>>>    // pdp-11 asm has dest reg on the right
>>>    ADDTY #tiny,reg   Add Tiny
>>>    SUBTY #tiny,reg   Subtract Tiny
>>>
>>> where tiny is 1..7 and 0 means 8. Much more generally useful.
>>
>> I would rather have 0..7 meaning 1..8, since this is trivially
>> achieved by always enabling an incoming carry to the address adder.
>> Special-casing 0 to mean 8 seems like it would need more gates?
>>
>> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
>>
>> Terje
>
> 1..7, 0 => 8 allows the 3 lower bits to be used directly
> and a 3-input NOR-3 gate to drive the 4th bit.
>
> 0..7 => 1..8 needs an incrementer, in this case a NOT, 2 XOR's,
> an AND-2 and an AND-3 carry lookaheads.
>
> Its in the decoder and there are other more expensive things there,
> so it wouldn't be on the critical path either way.

The logic is simple either way, but since we're already going to use the
(address) adder, just setting carry_in is effectively free.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 6/12/2021 8:25 AM, Quadibloc wrote:
> On Saturday, June 12, 2021 at 12:50:32 AM UTC-6, Quadibloc wrote:
>> On Friday, June 11, 2021 at 12:42:27 PM UTC-6, MitchAlsup wrote:
>>
>>> I still fail to see where cc gain anything (with proper branch support), plus
>>> I see many places where a vector of comparand bits is better than a CC
>>> from a CMP instruction (especially with the requirements of IEEE 754).
>> You're the expert, so no doubt you're right.
>>
>> And for vector instructions, yes, they create a vector of mask bits based on
>> a selected condition, if requested, and don't touch the condition codes, in the ISAs
>> I've proposed.
>>
>> But for scalar instructions, I lack the imagination to see how one can do a multi-word
>> add with carry propagation without using silly instructions that do the add a second
>> time, branch at the same time as arithmetic, or do other bad things that are wasteful.
>> Condition codes are the traditional approach people are familar with.
>>
>> Condition code elision solves... the _serious_ problems with condition codes, so
>> after I include that, I stop worrying about them. Maybe that's wrong. You've noted
>> they're bad for compilers.
>>
>> I suppose you mean certain kinds of compilers - those that first generate pseudocode
>> which is later converted to code for the target machine. The pseudocode doesn't deal
>> in awkward constructs like condition codes, so they're not natural for that kind of
>> compiler architecture.
>
> On reflection, suppose I have two instructions which must set the condition code
> for a future branch.
>
> And some compiler optimization has put them in the... wrong order.
>
> Now, I include in the Concertina II architecture, in *addition* to jump and branch
> instructions which test the condition codes... an instruction that tests the condition
> codes, and sets one of the flag bits used for *instruction predication*.
>
> It has occured to me that to achieve - without the baggage that the PowerPC took
> on - complete immunity to condition codes restricting what the compiler can do,
> there is a missing class of instructions that I need to add to my architecture.
>
> In addition to condition-code based conditional jump instructions... I need jump
> instructions that use those flag bits originally envisaged as only for instruction
> predication. (Of course, I _could_ predicate a jump instruction, but if I can avoid
> the cost and awkwardness of choosing a block header just for that...)
>
> John Savard
>

Or just set the flags directly - why have CCs?

On Saturday, June 12, 2021 at 1:50:32 AM UTC-5, Quadibloc wrote:
> On Friday, June 11, 2021 at 12:42:27 PM UTC-6, MitchAlsup wrote:
>
> > I still fail to see where cc gain anything (with proper branch support), plus
> > I see many places where a vector of comparand bits is better than a CC
> > from a CMP instruction (especially with the requirements of IEEE 754).
> You're the expert, so no doubt you're right.
>
> And for vector instructions, yes, they create a vector of mask bits based on
> a selected condition, if requested, and don't touch the condition codes, in the ISAs
> I've proposed.
>
> But for scalar instructions, I lack the imagination to see how one can do a multi-word
> add with carry propagation without using silly instructions that do the add a second
> time, branch at the same time as arithmetic, or do other bad things that are wasteful.
> Condition codes are the traditional approach people are familar with.
<
I agree with you that your familiarity is blinding your vision.
<
However, I do have to admit it took me 35 years to figure out CARRY as the solution
to multiprecision arithmetic of all kind {ADD, SUB, MUL, DIV, SHIFTs, Floating Point.}
>
> Condition code elision solves... the _serious_ problems with condition codes, so
> after I include that, I stop worrying about them. Maybe that's wrong. You've noted
> they're bad for compilers.
<
They are not "so bad" for compilers, but they do not match the semantics high level
languages had defined for flow control (if-then-else, do-while, and for}
>
> I suppose you mean certain kinds of compilers - those that first generate pseudocode
> which is later converted to code for the target machine. The pseudocode doesn't deal
> in awkward constructs like condition codes, so they're not natural for that kind of
> compiler architecture.
<
YEs.
>
> John Savard

On Saturday, June 12, 2021 at 6:40:10 AM UTC-5, Anton Ertl wrote:
> Quadibloc <jsa...@ecn.ab.ca> writes:
> >On Friday, June 11, 2021 at 11:46:01 PM UTC-6, Anton Ertl wrote:
> >
> >> IMO it's a good thing. Then you know that the cc comes from the
> >> previous non-branch instruction, not from some arbitrary far
> >> instruction. You can fuse the conditional branch(es) with the
> >> condition-generating instructions in all cases, and don't have to
> >> reify the cc in a flags register. It certainly makes emulators easier
> >> to implement, and, I expect, also CPUs.
> >
> >That's a dependency. You want to do other instructions between
> >the operation and the branch.
<
> What makes you think so? The typical code I see has the branch right
> after the condition-code-setting instruction. Intel even optimizes
> this case by combining e.g., an add and a following conditional branch
> into one uop, and I expect that they are not the only ones.
> >So it forces you to implement full
<
Code scheduling is really for narrow in order machines.
<
GBOoO machines are better off with natural scheduling and letting
HW solve the register and memory ordering problems.
<
Quadibloc's though train is stuck in the late 1980s.
<
> >OoO for efficiency, which is why RISC architectures didn't do it
> >that way; they either had a bit to turn off setting the condition
> >codes, or they dispensed with condition codes entirely.
<
> I don't expect that in-order SPARCs and in-order ARMs run any slower
> if you set the condition code in every instruction. Doing in-order
> and setting cc on every instruction is easy.
>
> OoO is more interesting: If you manage to treat the
> condition-code-generating instruction and the consuming instruction(s)
> as a unit, you don't even need to have condition codes in the
> microarchitecture.
<
This is an important point Quadibloc, the CMP and branch get fused
and performed as if one, then there is no intermediate state required.
<
> If you don't, you may be able to make do with
> fewer physical condition code registers if fewer instructions set
> condition codes. Or maybe not: If every instruction overwrites the
> previous condition code register, many cc registers need to be
> allocated, but they are also released quickly.
>
> My guess is that hardware implementation concerns are not the reason
> for making cc-setting optional.
<
Once you give up on code scheduling, optionally setting CCs become
irrelvant.
<
> Instead, compiler implementation
> concerns are: If every instruction is cc-setting, spill-code placement
> and placement of move instruction becomes harder; maybe there is also
> the hope that the compiler can do better scheduling of code if it can
> move non-cc-setting instructions between a cc-setting and a cc-reading
> instruction, but I don't think that hope is fulfilled:
>
> Looking for "b." (conditional branches depending on condition codes)
> in an Aarch64 file generated from C code and one immediately
> preceeding line, I see
>
> 189 b.
>
> preceded by
>
> 134 cmp
> 14 cmn (compare negative)
> 5 tst
> 1 ccmp
> 1 subs
> 1 adds
>
> 22 non-cc-setting instructions (ldr, str, mov, add, ror)
>
> If you are as obsessed with code density as our PDP-11 reinventors, do
> you really want to waste a bit in many instructions for that?
<
Thank you for making my point.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Saturday, June 12, 2021 at 12:12:07 PM UTC-5, Terje Mathisen wrote:
> EricP wrote:
> > Terje Mathisen wrote:
> >> EricP wrote:
> >>>
> >>> So toss out auto inc/dec address modes and put in two instructions
> >>>
> >>> // pdp-11 asm has dest reg on the right
> >>> ADDTY #tiny,reg Add Tiny
> >>> SUBTY #tiny,reg Subtract Tiny
> >>>
> >>> where tiny is 1..7 and 0 means 8. Much more generally useful.
> >>
> >> I would rather have 0..7 meaning 1..8, since this is trivially
> >> achieved by always enabling an incoming carry to the address adder.
> >> Special-casing 0 to mean 8 seems like it would need more gates?
> >>
> >> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
> >>
> >> Terje
> >
> > 1..7, 0 => 8 allows the 3 lower bits to be used directly
> > and a 3-input NOR-3 gate to drive the 4th bit.
> >
> > 0..7 => 1..8 needs an incrementer, in this case a NOT, 2 XOR's,
> > an AND-2 and an AND-3 carry lookaheads.
> >
> > Its in the decoder and there are other more expensive things there,
> > so it wouldn't be on the critical path either way.
<
> The logic is simple either way, but since we're already going to use the
> (address) adder, just setting carry_in is effectively free.
<
What makes you think the AGEN adder has a carry in ??
<
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

MitchAlsup wrote:
> On Friday, June 11, 2021 at 8:28:59 AM UTC-5, Terje Mathisen wrote:
>> EricP wrote:
>>> So toss out auto inc/dec address modes and put in two instructions
>>>
>>> // pdp-11 asm has dest reg on the right
>>> ADDTY #tiny,reg Add Tiny
>>> SUBTY #tiny,reg Subtract Tiny
>>>
>>> where tiny is 1..7 and 0 means 8. Much more generally useful.
>> I would rather have 0..7 meaning 1..8, since this is trivially achieved
>> by always enabling an incoming carry to the address adder.
>> Special-casing 0 to mean 8 seems like it would need more gates?
>>
>> I.e. cnt3 = !(cnt0 & cnt1 & cnt2) vs always setting carry-in?
> <
> cnt3 is 1-gate delay.
> carry-in is 4-gate delays.

Wow!

So you are saying that simply forcing carry-in takes 4 extra gate
delays, on top of routing the three address bits, and also merging them
with the generated cnt3 bit?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"