MitchAlsup wrote:
> <
> 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.}

And, IIRC, a walk to the pub.

MitchAlsup wrote:
> On Thursday, June 10, 2021 at 7:21:39 PM UTC-5, EricP wrote:
>> // pdp-11 asm has dest reg on the right
>> DIV r3,r7
>> AND #123,r7
> <
> Its my architecture, I can position the fields and write the ASM in the
> direction I am accustomed. You may do the same with yours.

I was warning other casual readers that, as per your prior statement
to use PDP-11 assembler writing style, the dest operand is on the right.

>> Only branch, bsr, jmp, jsr, instructions should be allowed to modify R7.
>> If you really, really want to do a DIV into R7 then do
>>
>> BAL #0,r2 // copy r7 -> r2
>> DIV r3,r2
>> JMP r2
> <
> This is an argument that IP should not be part of the GPRs, not that
> existing instructions should not be used.

The conclusion I came to is that IP is special because the PC-relative
address mode implies the register and needs no register field,
but does require an offset (2, 4 or 8 bytes, sign extended)
and IP-base-indexed has optional immediate offsets.

Other modes that require no register field are
- immediate data (2, 4, 8 bytes with data type given by the opcode)
- immediate absolute address, Abs32 sign extended to 64, and Abs64

That removes the IP from the register set and moves all the above mode
specifier bits into the opcode, where they can be optimally assigned.

So either an instruction set is orthogonal and contains redundant or
erroneous combinations (e.g. immediate data cannot be a destination),
or one deals with it in the opcode bits, e.g. ADD and ADDI Add Immediate.
I prefer to deal with it in the opcodes.

>> Or special case R7 similar to how My 66000 handles R0.
> <
> I have been thinking about this, back on this topic a bit later.

Having IP in the register set does make IP-relative and IP-base-indexed
fit in with other registers

> <
> My current train of thought is that when one used AM=11x (6 or 7) and R0
> then the 16-bit immediate is used too access 1K-8K of registers, the lower
> order 3-bits is used to denote size and signedness, and depending on a lot
> of things, the upper order bits could be used for other purposes {saturation
> SIMD,Decimal,...}

This reminds me of the TMS 9900 with its Workspace Pointer register.

> <
> I am trying for something different, having 8 registers that control stuff,
> and having a big register file (1K-8K 64-bit entries) that can be accessed
> in one cycle (sort of like a smaller register file), but:: The GPR file only
> accesses 64-bit things, the large file can access things based on a size.
> So::
> disp(r0):SB
> says that the data in R[disp>>3] contains a signed byte
> @disp(R0):UH
> says the 64-bit data in R[disp>>3] points at an unsigned Halfword anywhere in
> memory.
> I will have to figure out some better ASM mnemonics.
> <
> But this is not some kind of RISC machine with a small and large pair of
> register files, it is an address mode machine; and accessing the large
> file eats instruction stream area.

Yes, I was thinking about that overnight, whether operand size is
operand specific or applies to all operands in the instruction.

The problem is in real code, for integers at least, variables often are
different sizes and depend on the promote/demote conversion rules,
and that requires a register to temporarily hold converted values.
Load with optional convert, operate, store with optional convert.

So [mem]-[mem] looks like each operand has to have its own size and type.

Then it needs rule on how things convert when the operand sizes mismatch,
promote on load (integer sign/zero extend),
demote on store (integer wrap/trap/sat).
And floats fp8, fp16, fp32, fp64.

This starts to look less likely to fit into a 16-bit instruction word.

On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
> 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?
<
Yes, it is sad that SW people see AND and ADD as the same latency.
<
> Terje
>
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Saturday, June 12, 2021 at 1:25:02 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > <
> > 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.}
<
> And, IIRC, a walk to the pub.
<
Your mind is as sharp as ever,
And thanks for reminding me of that!

On Saturday, June 12, 2021 at 2:23:09 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Thursday, June 10, 2021 at 7:21:39 PM UTC-5, EricP wrote:
> >> // pdp-11 asm has dest reg on the right
> >> DIV r3,r7
> >> AND #123,r7
> > <
> > Its my architecture, I can position the fields and write the ASM in the
> > direction I am accustomed. You may do the same with yours.
>
> I was warning other casual readers that, as per your prior statement
> to use PDP-11 assembler writing style, the dest operand is on the right.
<
Fair enough.
>
> >> Only branch, bsr, jmp, jsr, instructions should be allowed to modify R7.
> >> If you really, really want to do a DIV into R7 then do
> >>
> >> BAL #0,r2 // copy r7 -> r2
> >> DIV r3,r2
> >> JMP r2
> > <
> > This is an argument that IP should not be part of the GPRs, not that
> > existing instructions should not be used.
>
> The conclusion I came to is that IP is special because the PC-relative
> address mode implies the register and needs no register field,
> but does require an offset (2, 4 or 8 bytes, sign extended)
> and IP-base-indexed has optional immediate offsets.
<
I agree that IP as part of the register file seems to have died off, for
all sorts of reasons. But I am exploring the utility space of address
modes for the first time in 35 years, bear with my meanderings. This
whole thing may come to nothing.
>
> Other modes that require no register field are
> - immediate data (2, 4, 8 bytes with data type given by the opcode)
> - immediate absolute address, Abs32 sign extended to 64, and Abs64
<
On the other hand, having IP as part of the register file, means things like
<
d = 37<<j;
*p = 19;
<
are straightforward.
>
> That removes the IP from the register set and moves all the above mode
> specifier bits into the opcode, where they can be optimally assigned.
<
I am currently playing with the notion where there is a small register file
(8 entries) which is really fast, and a larger register file (64-256 entries)
which is 1 cycle access, and then memory which is 3-4 cycles of access
and supports sizes other than 64-bits. {The first 8 entries of the large
file is the small 8 register file.}
>
> So either an instruction set is orthogonal and contains redundant or
> erroneous combinations (e.g. immediate data cannot be a destination),
> or one deals with it in the opcode bits, e.g. ADD and ADDI Add Immediate.
> I prefer to deal with it in the opcodes.
<
Your architecture, your choice.
>
> >> Or special case R7 similar to how My 66000 handles R0.
> > <
> > I have been thinking about this, back on this topic a bit later.
>
> Having IP in the register set does make IP-relative and IP-base-indexed
> fit in with other registers
>
> > <
> > My current train of thought is that when one used AM=11x (6 or 7) and R0
> > then the 16-bit immediate is used too access 1K-8K of registers, the lower
> > order 3-bits is used to denote size and signedness, and depending on a lot
> > of things, the upper order bits could be used for other purposes {saturation
> > SIMD,Decimal,...}
>
> This reminds me of the TMS 9900 with its Workspace Pointer register.
<
It is along those lines.
>
> > <
> > I am trying for something different, having 8 registers that control stuff,
> > and having a big register file (1K-8K 64-bit entries) that can be accessed
> > in one cycle (sort of like a smaller register file), but:: The GPR file only
> > accesses 64-bit things, the large file can access things based on a size.
> > So::
> > disp(r0):SB
> > says that the data in R[disp>>3] contains a signed byte
> > @disp(R0):UH
> > says the 64-bit data in R[disp>>3] points at an unsigned Halfword anywhere in
> > memory.
> > I will have to figure out some better ASM mnemonics.
> > <
> > But this is not some kind of RISC machine with a small and large pair of
> > register files, it is an address mode machine; and accessing the large
> > file eats instruction stream area.
>
> Yes, I was thinking about that overnight, whether operand size is
> operand specific or applies to all operands in the instruction.
<
Current thought train is that size (and signedness) applies to operands
and that after a calculation should the result not fit in the destination
size, OVERFLOW is raised.
<
I have worked out an encoding extension when I can fit 3 address modes
into a 32-bit instruction and have 128 instructions of this flavor; this also
allows for 16 instructions with 3 address mode operands and 1 address
mode result.
<
Upon EricP's suggestion, I have dropped the deferred address modes
in favor of {reg, [reg],[reg++],[--reg],[rp->0[ri]],[rp->disp16[ri]],[rp->disp32[ri]],
and [rp->disp48[ri]]}. Along with the large register file (64-256 entries)
we should not need an excessive amount of memory traffic.
>
> The problem is in real code, for integers at least, variables often are
> different sizes and depend on the promote/demote conversion rules,
> and that requires a register to temporarily hold converted values.
> Load with optional convert, operate, store with optional convert.
>
> So [mem]-[mem] looks like each operand has to have its own size and type.
<
Size and some other indicator.
For Integers, the indicator is signedness
For Float it has not been worked out, yet.
>
> Then it needs rule on how things convert when the operand sizes mismatch,
> promote on load (integer sign/zero extend),
> demote on store (integer wrap/trap/sat).
> And floats fp8, fp16, fp32, fp64.
<
Current thought train for integers:: we have 8 flavors {Signed, Unsigned}×
{byte, half, word, double}. Operands are accessed and converted to 64-bits.
The calculation is performed (to extra precision if required). Then the result
is fitted to the destination size and if significance is lost->OVERFLOW is raised.
>
> This starts to look less likely to fit into a 16-bit instruction word.
<
It starts looking less and less like a DPD-11, that is for sure.

On Saturday, June 12, 2021 at 4:14:07 PM UTC-5, MitchAlsup wrote:
> On Saturday, June 12, 2021 at 2:23:09 PM UTC-5, EricP wrote:
> > MitchAlsup wrote:
> > > On Thursday, June 10, 2021 at 7:21:39 PM UTC-5, EricP wrote:
> > >> // pdp-11 asm has dest reg on the right
> > >> DIV r3,r7
> > >> AND #123,r7
> > > <
> > > Its my architecture, I can position the fields and write the ASM in the
> > > direction I am accustomed. You may do the same with yours.
> >
> > I was warning other casual readers that, as per your prior statement
> > to use PDP-11 assembler writing style, the dest operand is on the right..
> <
> Fair enough.
> >
> > >> Only branch, bsr, jmp, jsr, instructions should be allowed to modify R7.
> > >> If you really, really want to do a DIV into R7 then do
> > >>
> > >> BAL #0,r2 // copy r7 -> r2
> > >> DIV r3,r2
> > >> JMP r2
> > > <
> > > This is an argument that IP should not be part of the GPRs, not that
> > > existing instructions should not be used.
> >
> > The conclusion I came to is that IP is special because the PC-relative
> > address mode implies the register and needs no register field,
> > but does require an offset (2, 4 or 8 bytes, sign extended)
> > and IP-base-indexed has optional immediate offsets.
> <
> I agree that IP as part of the register file seems to have died off, for
> all sorts of reasons. But I am exploring the utility space of address
> modes for the first time in 35 years, bear with my meanderings. This
> whole thing may come to nothing.
> >
> > Other modes that require no register field are
> > - immediate data (2, 4, 8 bytes with data type given by the opcode)
> > - immediate absolute address, Abs32 sign extended to 64, and Abs64
> <
> On the other hand, having IP as part of the register file, means things like
> <
> d = 37<<j;
> *p = 19;
> <
> are straightforward.
> >
> > That removes the IP from the register set and moves all the above mode
> > specifier bits into the opcode, where they can be optimally assigned.
> <
> I am currently playing with the notion where there is a small register file
> (8 entries) which is really fast, and a larger register file (64-256 entries)
> which is 1 cycle access, and then memory which is 3-4 cycles of access
> and supports sizes other than 64-bits. {The first 8 entries of the large
> file is the small 8 register file.}
> >
> > So either an instruction set is orthogonal and contains redundant or
> > erroneous combinations (e.g. immediate data cannot be a destination),
> > or one deals with it in the opcode bits, e.g. ADD and ADDI Add Immediate.
> > I prefer to deal with it in the opcodes.
> <
> Your architecture, your choice.
> >
> > >> Or special case R7 similar to how My 66000 handles R0.
> > > <
> > > I have been thinking about this, back on this topic a bit later.
> >
> > Having IP in the register set does make IP-relative and IP-base-indexed
> > fit in with other registers
> >
> > > <
> > > My current train of thought is that when one used AM=11x (6 or 7) and R0
> > > then the 16-bit immediate is used too access 1K-8K of registers, the lower
> > > order 3-bits is used to denote size and signedness, and depending on a lot
> > > of things, the upper order bits could be used for other purposes {saturation
> > > SIMD,Decimal,...}
> >
> > This reminds me of the TMS 9900 with its Workspace Pointer register.
> <
> It is along those lines.
> >
> > > <
> > > I am trying for something different, having 8 registers that control stuff,
> > > and having a big register file (1K-8K 64-bit entries) that can be accessed
> > > in one cycle (sort of like a smaller register file), but:: The GPR file only
> > > accesses 64-bit things, the large file can access things based on a size.
> > > So::
> > > disp(r0):SB
> > > says that the data in R[disp>>3] contains a signed byte
> > > @disp(R0):UH
> > > says the 64-bit data in R[disp>>3] points at an unsigned Halfword anywhere in
> > > memory.
> > > I will have to figure out some better ASM mnemonics.
> > > <
> > > But this is not some kind of RISC machine with a small and large pair of
> > > register files, it is an address mode machine; and accessing the large
> > > file eats instruction stream area.
> >
> > Yes, I was thinking about that overnight, whether operand size is
> > operand specific or applies to all operands in the instruction.
> <
> Current thought train is that size (and signedness) applies to operands
> and that after a calculation should the result not fit in the destination
> size, OVERFLOW is raised.
> <
> I have worked out an encoding extension when I can fit 3 address modes
> into a 32-bit instruction and have 128 instructions of this flavor; this also
> allows for 16 instructions with 3 address mode operands and 1 address
> mode result.
> <
> Upon EricP's suggestion, I have dropped the deferred address modes
> in favor of {reg, [reg],[reg++],[--reg],[rp->0[ri]],[rp->disp16[ri]],[rp->disp32[ri]],
> and [rp->disp48[ri]]}. Along with the large register file (64-256 entries)
> we should not need an excessive amount of memory traffic.
> >
> > The problem is in real code, for integers at least, variables often are
> > different sizes and depend on the promote/demote conversion rules,
> > and that requires a register to temporarily hold converted values.
> > Load with optional convert, operate, store with optional convert.
> >
> > So [mem]-[mem] looks like each operand has to have its own size and type.
> <
> Size and some other indicator.
> For Integers, the indicator is signedness
> For Float it has not been worked out, yet.
> >
> > Then it needs rule on how things convert when the operand sizes mismatch,
> > promote on load (integer sign/zero extend),
> > demote on store (integer wrap/trap/sat).
> > And floats fp8, fp16, fp32, fp64.
> <
> Current thought train for integers:: we have 8 flavors {Signed, Unsigned}×
> {byte, half, word, double}. Operands are accessed and converted to 64-bits.
> The calculation is performed (to extra precision if required). Then the result
> is fitted to the destination size and if significance is lost->OVERFLOW is raised.
> >
> > This starts to look less likely to fit into a 16-bit instruction word.
> <
> It starts looking less and less like a DPD-11, that is for sure.
| |> It starts looking less and less like a DPD-11, that is for sure.

"Legacy upgrades" are common in military avionics.
Original functionality maintained. As many new useful features
as the customer will pay for and contractor can efficiently provide.

Repeating myself, one last time:
For legacy ISAs, I think it is proper or advantageous to retain as
much of the original ISA as possible. Here and for Alt-430, most of the ISA
can remain intact except for an escape mechanism to a larger instruction format.
For Alt-11, use the floating-point op-code range for the escape code.
For Alt-430, use the Decimal Add op-code range for the escape code.

As have said before, on DPD11 support 8 and 64 bit data sizes on
most of the original ISA. 8, 16, 32 and 64 data on the escape ISA.
On the Alt-430 the new feature is an additional addressing mode [--Rn].

What's new, for me, for both ISAs, is redirecting the two unused address
modes to specifying the offset size (16, 32 or 64 bits). Easily done with
a three bit mode field.

Now the issue of performance, and that's not my field. Still for the sake
of salesmanship, it is best to provide an upwards compatibility process,
which may require re-assembly or re-compilation?

On Saturday, June 12, 2021 at 11:21:29 AM UTC-6, Ivan Godard wrote:
> On 6/12/2021 8:25 AM, Quadibloc wrote:

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

> Or just set the flags directly - why have CCs?

I can tell you why that idea never even occurred to me.

If I add two numbers, then 'negative', 'zero', 'carry', and 'overflow' naturally describe
things that happened during that addition. I don't have to specify anything in the add
instruction.

If I set the flags, I have to specify... which flag I am going to change... and for what
reason. Set it if the result is negarive, or if there's a carry?

So I have operate instructions with one bit to permit the condition codes to be
set, and conditional branch instructions, following the normal pattern.

Predication, on the other hand, uses flags - so that several flags can be
set up ahead of time, and then referred to by the most economical and direct
manner. This is the traditional convention - and I saw no reason to quarrel with
it.

John Savard

On Saturday, June 12, 2021 at 11:36:20 AM UTC-6, MitchAlsup wrote:

> Quadibloc's though train is stuck in the late 1980s.

Or even the early 1960s, although indeed some things from later,
like the Cray I, did also influence me.

> This is an important point Quadibloc, the CMP and branch get fused
> and performed as if one, then there is no intermediate state required.

Just as the load instruction and the operate instruction can be fused
and performed as one.

Or rather, they get fused and *written* as one, so that the code is more
compact. But then they get turned into micro-ops.

And the compare gets done, and only when the result is ready is the
branch performed... or the load gets done, and only when the data
is fetched is the operate performed.

So instructions like that are just fine... if your implementation is out of order,
and maybe with speculative execution thrown in.

> Once you give up on code scheduling, optionally setting CCs become
> irrelvant.

And because I'm trying to design an inherently efficient ISA, instead of a legacy
one that needs OoO to endow it with efficiency, giving up on code scheduling is
not something I'm planning to do in Concertina II. The original Concertina
architecture is a pure CISC architecture of that kind.

John Savard

On Saturday, June 12, 2021 at 2:50:38 PM UTC-6, MitchAlsup wrote:
> On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
> > MitchAlsup wrote:

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

> Yes, it is sad that SW people see AND and ADD as the same latency.

Just in case there's a misunderstanding here:

Setting the "carry-in" signal line to HIGH does not take more than one
gate delay.

However, since it _is_ a carry-in line, presumably it's a carry in to
some accumulator. With the intent that the number in it will be
incremented by one. If that's a 64-bit accumulator, the number of gate
delays will be... large. At least for some values of its contents, those
ending in a long string of ones.

Mitch Alsup's figure is for the case where a carry-in signal arrives at
a full adder, and propagates to its result outputs.

John Savard

On Saturday, June 12, 2021 at 7:38:05 PM UTC-5, Quadibloc wrote:
> On Saturday, June 12, 2021 at 2:50:38 PM UTC-6, MitchAlsup wrote:
> > On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
> > > MitchAlsup wrote:
>
> > > > 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?
>
> > Yes, it is sad that SW people see AND and ADD as the same latency.
> Just in case there's a misunderstanding here:
>
> Setting the "carry-in" signal line to HIGH does not take more than one
> gate delay.
<
With a 3 (or 4)-bit adder the carry in does not change the 4-gates of delay.
<
>
> However, since it _is_ a carry-in line, presumably it's a carry in to
> some accumulator. With the intent that the number in it will be
> incremented by one. If that's a 64-bit accumulator, the number of gate
> delays will be... large. At least for some values of its contents, those
> ending in a long string of ones.
>
> Mitch Alsup's figure is for the case where a carry-in signal arrives at
> a full adder, and propagates to its result outputs.
<
An incrementer for 3 (or 4)-bits would still cost that 4 gates of delay.
>
> John Savard

On Saturday, June 12, 2021 at 8:01:50 PM UTC-5, MitchAlsup wrote:
> On Saturday, June 12, 2021 at 7:38:05 PM UTC-5, Quadibloc wrote:
> > On Saturday, June 12, 2021 at 2:50:38 PM UTC-6, MitchAlsup wrote:
> > > On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
> > > > MitchAlsup wrote:
> >
> > > > > 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?
> >
> > > Yes, it is sad that SW people see AND and ADD as the same latency.
> > Just in case there's a misunderstanding here:
> >
> > Setting the "carry-in" signal line to HIGH does not take more than one
> > gate delay.
> <
> With a 3 (or 4)-bit adder the carry in does not change the 4-gates of delay.
> <

Don't understand?
A carry lookahead adder of the TTL era has a carry input to the LSB.
No need for an increment circuit..
Other adders: conditional sum or carry select (chapter 3 Hwang, chapter 5 Koren,
chapter 5 & 6 Flores, chapter 6 & 7 Parhami) are similar WRT LSB carry input.

> >
> > However, since it _is_ a carry-in line, presumably it's a carry in to
> > some accumulator. With the intent that the number in it will be
> > incremented by one. If that's a 64-bit accumulator, the number of gate
> > delays will be... large. At least for some values of its contents, those
> > ending in a long string of ones.
> >
> > Mitch Alsup's figure is for the case where a carry-in signal arrives at
> > a full adder, and propagates to its result outputs.
> <
> An incrementer for 3 (or 4)-bits would still cost that 4 gates of delay.
> >
> > John Savard

On Saturday, June 12, 2021 at 8:56:21 PM UTC-5, JimBrakefield wrote:
> On Saturday, June 12, 2021 at 8:01:50 PM UTC-5, MitchAlsup wrote:
> > On Saturday, June 12, 2021 at 7:38:05 PM UTC-5, Quadibloc wrote:
> > > On Saturday, June 12, 2021 at 2:50:38 PM UTC-6, MitchAlsup wrote:
> > > > On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
> > > > > MitchAlsup wrote:
> > >
> > > > > > 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?
> > >
> > > > Yes, it is sad that SW people see AND and ADD as the same latency.
> > > Just in case there's a misunderstanding here:
> > >
> > > Setting the "carry-in" signal line to HIGH does not take more than one
> > > gate delay.
> > <
> > With a 3 (or 4)-bit adder the carry in does not change the 4-gates of delay.
> > <
> Don't understand?
> A carry lookahead adder of the TTL era has a carry input to the LSB.
<
It can
<
> No need for an increment circuit..
<
An incrementer is a degenerate adder with carry in hardwired to 1 and one operand wired to 000.
<
> Other adders: conditional sum or carry select (chapter 3 Hwang, chapter 5 Koren,
> chapter 5 & 6 Flores, chapter 6 & 7 Parhami) are similar WRT LSB carry input.
<
Adders shorter than about 16 bits have no particular need of Carry Select or other
exotic adding technologies.
<
Basically the adder sets up the p (propogate) and g (generate) terms. These terms
drive the local Manchester carry. The output of the Manchester carry selects the
output with an XOR gate. This is the 4 gates I was speaking.
<
This is one of the missing parts of this NG structure--the inability to post figures.
> > >
> > > However, since it _is_ a carry-in line, presumably it's a carry in to
> > > some accumulator. With the intent that the number in it will be
> > > incremented by one. If that's a 64-bit accumulator, the number of gate
> > > delays will be... large. At least for some values of its contents, those
> > > ending in a long string of ones.
> > >
> > > Mitch Alsup's figure is for the case where a carry-in signal arrives at
> > > a full adder, and propagates to its result outputs.
<
I have built adders where the carry_in signal can be as much as 3 gates behind
the operands without slowing the adder down. I have also built adders where
the carry_in needs to arrive before the operands. It all depends on what the logic
situation is presented.
<
> > <
> > An incrementer for 3 (or 4)-bits would still cost that 4 gates of delay.
> > >
> > > John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:
>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.

Another alternative (in addition to Mitch Alsup's CARRY instruction)
is to have the carry in the 65th bit of the GPR, which we discussed
recently (<2021Mar10.110220@mips.complang.tuwien.ac.at> ff.)

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

Condition codes, like all single-instance special-purpose registers,
go against the grain for any kind of compiler. Intermediate
representations have nothing to do with it; condition codes are used
widely enough (and in architectures that are mainstream enough) that
they would be well-represented in intermediate representations if the
back end could then do something with them. As it is, the back ends
cannot do much with them, so they are only represented half-heartedly
in the intermediate representation.

- 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 9:25:56 AM UTC-6, Quadibloc wrote:

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

These instructions have now been added to the Concertina II architecture. While
the notion may horrify some, I do think that this is, indeed, a solution to the
compiler-related objection to condition codes. By having the ability, if necessary,
to take condition code information, and put it into flags, operate instructions that
generate condition codes for future branches can now be drastically re-ordered
by optimization if necessary; if an issue arises, a set flag instruction can be inserted,
and one of the branches changed to a branch on flag.

John Savard

MitchAlsup <MitchAlsup@aol.com> schrieb:
>> This starts to look less likely to fit into a 16-bit instruction word.
><
> It starts looking less and less like a DPD-11, that is for sure.

I assume this is a typo, but it would be a good name for the
architecture :-)

On 13/06/2021 01:26, Quadibloc wrote:
> On Saturday, June 12, 2021 at 11:21:29 AM UTC-6, Ivan Godard wrote:
>> On 6/12/2021 8:25 AM, Quadibloc wrote:
>
>>> 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...)
>
>> Or just set the flags directly - why have CCs?
>
> I can tell you why that idea never even occurred to me.
>
> If I add two numbers, then 'negative', 'zero', 'carry', and 'overflow' naturally describe
> things that happened during that addition. I don't have to specify anything in the add
> instruction.
>
> If I set the flags, I have to specify... which flag I am going to change... and for what
> reason. Set it if the result is negarive, or if there's a carry?

Worth noting, perhaps, that of the four classic flags that you mention,
N and Z are not strictly necessary as they can be determined from a result.

By contrast, the other two are needed in that they reveal information
about what happened /during/ an operation that would otherwise be lost
(or expensive to recreate).

So in a sense, no more than two flags are required. (It may be possible
to reduce it further but that's a separate topic.) If there were only
two then that would lead, interestingly, to three potential categories
of branch instructions:

1. Branches relying only on flags C & V (e.g. branch below).
2. Branches relying on values (e.g. branch zero).
3. Branches combining flags with values (e.g. branch less).

There's a handy table of what flags are traditionally tested for which
branch conditions at

http://www.scs.stanford.edu/05au-cs240c/lab/i386/appd.htm

Caveat: in programs, some instructions which are traditionally executed
only to set flags (like test and compare) would have to be replaced by
ones which generate a result, consuming a register in order to do so.

--
James Harris

On 12/06/2021 21:50, MitchAlsup wrote:
> On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:

....

>> 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?
> <
> Yes, it is sad that SW people see AND and ADD as the same latency.

As what you might call a software person I don't see AND and ADD as
needing the same latency and I find it a bit irksome when CPUs require
the same time (1 cycle) for each - although I guess that with
transistors aplenty (as there are today) there are probably ways to
predict carry propagation.

--
James Harris

James Harris <james.harris.1@gmail.com> writes:
>Worth noting, perhaps, that of the four classic flags that you mention,
>N and Z are not strictly necessary as they can be determined from a result.
>
>By contrast, the other two are needed in that they reveal information
>about what happened /during/ an operation that would otherwise be lost
>(or expensive to recreate).
>
>So in a sense, no more than two flags are required. (It may be possible
>to reduce it further but that's a separate topic.)

Add another bit to the result register, and C and V are also
represented in the result: C is the extra bit, and V=C^N. That's one
way to do it, and you have ripple effects on instruction-set design:
You need to differentiate between signed and unsigned addition with
this approach (or already have the inputs sign- or zero-extended into
the C bit). An alternative (and probably better) way is to have two
extra bits (C and V), but a common add instruction that sets them
both, C as the overflow of unsigned addition and V as the overflow
indicator of signed addition (In this case, V=C^N does not always
hold). See <2021Mar10.110220@mips.complang.tuwien.ac.at> ff.

>If there were only
>two then that would lead, interestingly, to three potential categories
>of branch instructions:
>
>1. Branches relying only on flags C & V (e.g. branch below).
>2. Branches relying on values (e.g. branch zero).

Aarch64 has branches on cc's (but not just C & V, as well as a branch
on a register being zero (or non-zero), and you can test the sign bit
with TBZ/TBNZ (if I understand this instruction correctly).

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

James Harris <james.harris.1@gmail.com> schrieb:
> On 12/06/2021 21:50, MitchAlsup wrote:
>> On Saturday, June 12, 2021 at 12:47:46 PM UTC-5, Terje Mathisen wrote:
>
> ...
>
>>> 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?
>> <
>> Yes, it is sad that SW people see AND and ADD as the same latency.
>
> As what you might call a software person I don't see AND and ADD as
> needing the same latency and I find it a bit irksome when CPUs require
> the same time (1 cycle) for each -

You would need an elastic pipeline for this; in this case, you could
also make your additions somewhat faster in the case where you
do not need to propagate carries very far (or your multipliers if
you are, for example, multiplying two 8-bit numbers with a 64-bit
multiplier).

There are papers on this, but no major architecture has done this to
date (unless I have missed something, which may well be the case).

Thomas Koenig <tkoenig@netcologne.de> writes:
>James Harris <james.harris.1@gmail.com> schrieb:
>> As what you might call a software person I don't see AND and ADD as
>> needing the same latency and I find it a bit irksome when CPUs require
>> the same time (1 cycle) for each -
>
>You would need an elastic pipeline for this; in this case, you could
>also make your additions somewhat faster in the case where you
>do not need to propagate carries very far (or your multipliers if
>you are, for example, multiplying two 8-bit numbers with a 64-bit
>multiplier).
>
>There are papers on this, but no major architecture has done this to
>date (unless I have missed something, which may well be the case).

Chuck Moore's uP20 and maybe some or all his later CPUs (most recently
the c18 in the Greenarrays CPUs) had this characteristic: He uses a
ripple-carry adder, which may take 4 cycles to produce a valid result
in the uP20, so in the general case you need to preceed an addition
with three nops (Why preceed? Because the adder always computes the
sum, and the addition instruction just selects the result of the
adder; the operands are always in the same registers, and there is no
subtract instruction). If you know that the result is available
earlier (i.e., that the carry chains are shorter), you can use fewer
NOPs.

By contrast, the result of AND is available in the next cycle, so no
need to have NOPs in front of AND.

Unfortunately, Chuck Moore is not much into writing, so we only get
second-hand reports of all this stuff, some which go into such details
and others which don't.

As for more mainstream CPUs, I doubt that you would get much benefit
from being able to process some ALU operations faster. You still have
to control and feed the ALUs, and that may be the bottleneck. But
assuming that that's taken care of, and we can run each ALU
instruction in the minimal number of gate delays, and then feed the
result to the next ALU instruction (or load or whatever) in the
critical dependency chain, would we really see a significant speedup?
This might make an interesting limits paper.

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

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>James Harris <james.harris.1@gmail.com> schrieb:
>>> As what you might call a software person I don't see AND and ADD as
>>> needing the same latency and I find it a bit irksome when CPUs require
>>> the same time (1 cycle) for each -
>>
>>You would need an elastic pipeline for this; in this case, you could
>>also make your additions somewhat faster in the case where you
>>do not need to propagate carries very far (or your multipliers if
>>you are, for example, multiplying two 8-bit numbers with a 64-bit
>>multiplier).
>>
>>There are papers on this, but no major architecture has done this to
>>date (unless I have missed something, which may well be the case).

[Chuck Moore references snipped - I will try to find some info on that]

> As for more mainstream CPUs, I doubt that you would get much benefit
> from being able to process some ALU operations faster. You still have
> to control and feed the ALUs, and that may be the bottleneck.

It probably makes more sense to make everything asynchronous - why
not an asynchronous decoder and asynchronous retirement?

Koopmans and Patel have proposed such an architecture in "Decoupled
Pipelines: Rationale, Analysis, and Evaluation", and there seems
to be some more work, but not a lot, and it all appears to be
rather dated.

It would be interesting to, for example, see a multiplier design
which is capable of generating its result earlier if the result
is shorter than its maximum length. Maybe switching to a partial
implementation on the input size is something that could be done.

On Sunday, June 13, 2021 at 6:02:00 AM UTC-5, James Harris wrote:
> On 13/06/2021 01:26, Quadibloc wrote:
> > On Saturday, June 12, 2021 at 11:21:29 AM UTC-6, Ivan Godard wrote:
> >> On 6/12/2021 8:25 AM, Quadibloc wrote:
> >
> >>> 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...)
> >
> >> Or just set the flags directly - why have CCs?
> >
> > I can tell you why that idea never even occurred to me.
> >
> > If I add two numbers, then 'negative', 'zero', 'carry', and 'overflow' naturally describe
> > things that happened during that addition. I don't have to specify anything in the add
> > instruction.
> >
> > If I set the flags, I have to specify... which flag I am going to change... and for what
> > reason. Set it if the result is negarive, or if there's a carry?
<
> Worth noting, perhaps, that of the four classic flags that you mention,
> N and Z are not strictly necessary as they can be determined from a result.
>
> By contrast, the other two are needed in that they reveal information
> about what happened /during/ an operation that would otherwise be lost
> (or expensive to recreate).
>
> So in a sense, no more than two flags are required.
<
There are 10 ways to interpret an integer-integer compare--even if you
cast out ½ of them you can't encode 5-states in 2-bits--so you have to
have signed and unsigned compare instructions.
<
There are 10 ways to classify a floating point number, and this is a bit
hard to compress into a 2-bit code.
<
> (It may be possible
> to reduce it further but that's a separate topic.) If there were only
> two then that would lead, interestingly, to three potential categories
> of branch instructions:
>
> 1. Branches relying only on flags C & V (e.g. branch below).
> 2. Branches relying on values (e.g. branch zero).
> 3. Branches combining flags with values (e.g. branch less).
>
> There's a handy table of what flags are traditionally tested for which
> branch conditions at
>
> http://www.scs.stanford.edu/05au-cs240c/lab/i386/appd.htm
>
>
>
>
> Caveat: in programs, some instructions which are traditionally executed
> only to set flags (like test and compare) would have to be replaced by
> ones which generate a result, consuming a register in order to do so.
>
>
> --
> James Harris

On Sunday, June 13, 2021 at 7:55:08 AM UTC-6, Anton Ertl wrote:

> Add another bit to the result register, and C and V are also
> represented in the result: C is the extra bit, and V=C^N.

That's easily enough done on the IBM 7090. On the PDP-8,
the carry bit, called the Link bit, can be thought of as an extra
bit in the accumulator.

In a general register architecture, though, if you lengthen
all the general registers by one bit, now they're not conformant
with memory. So load and store multiple don't work well for
saving state unless they're made wasteful of memory, and
quite a bit else gets made... inaesthetic at least.

The carry bit in the status word can indeed be thought of as
what it really is... an extension to the output buffer of the ALU.
So I guess you could call that the "result register". But that's
no change to the status quo.

There seems no harm in precomputing the other condition code
bits, and there is the additional benefit of not having to explain
the concept of the carry out of a floating-point number.

If "carry" means that the exponent was decreased by one, overflow
doesn't fall out... or I suppose the carry could be out of the exponent,
but it's in excess-n form, not two's complement form, although that
of course can be faked...

John Savard

MitchAlsup wrote:
> On Friday, June 11, 2021 at 10:08:38 AM UTC-5, EricP wrote:
>> 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'}

I'm pretty sure you were thinking of the "Wrath of Kahn", but I'm sure
Kahan could also be quite cross if you mess up your FP unit badly?
:-)

Terje

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

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

Enough?

I.e. branch if a >= b, but only if neither is a nan?

I.e. any kind of compound check.

Terje

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