I guess this is mostly a question for Mitch...

I have seen the terms "sequencer" and "microcode" being used, and while
I think that I know what microcode is, I'm not sure what the definition
of a sequencer is.

AFAIK microcode (at least in the context of a traditional multi-CPI
machine) sits in the decoder and pumps out "micro instructions" from
a microcode ROM - often more than one micro instruction per instruction.
I guess that in modern CISC implementations (e.g. x86) the microcode is
part of the translation front end, and probably only as an optional part
to cover for the cases that the fast-path translators can not deal with.

Anyway... How about a sequencer? My understanding is that it is a
simpler variant that does not need a microcode ROM - e.g. it could be an
FSM or just a counter, right?

For instance could the vector control unit in my scalar MRISC32-A1
implementation, which is basically a counter that stalls the front end
while iterating over vector register elements, be considered to be a
sequencer? How about the control unit for an iterative divider?

When talking about using a sequencer to implement My 66000 instructions
such as ENTER, EXIT and MM - where would those sequencers typically be
located? E.g. in decode or execute?

Would they output a sequence of (internal) instructions (which I assume
would be the case if they sit in the decoder), or would they act more
like controllers (which I assume would be the case if they sit in the
EU:s)?

/Marcus

On Thursday, June 24, 2021 at 8:56:56 AM UTC+2, Marcus wrote:
> I guess this is mostly a question for Mitch...
>
> I have seen the terms "sequencer" and "microcode" being used, and while
> I think that I know what microcode is, I'm not sure what the definition
> of a sequencer is.
>
> AFAIK microcode (at least in the context of a traditional multi-CPI
> machine) sits in the decoder and pumps out "micro instructions" from
> a microcode ROM - often more than one micro instruction per instruction.
> I guess that in modern CISC implementations (e.g. x86) the microcode is
> part of the translation front end, and probably only as an optional part
> to cover for the cases that the fast-path translators can not deal with.
>
> Anyway... How about a sequencer? My understanding is that it is a
> simpler variant that does not need a microcode ROM - e.g. it could be an
> FSM or just a counter, right?
>
> For instance could the vector control unit in my scalar MRISC32-A1
> implementation, which is basically a counter that stalls the front end
> while iterating over vector register elements, be considered to be a
> sequencer? How about the control unit for an iterative divider?

I'd could all these as sequencer-driven, because the circuit can be done with
just <100 gates configured for the exact formulas you need.

> When talking about using a sequencer to implement My 66000 instructions
> such as ENTER, EXIT and MM - where would those sequencers typically be
> located? E.g. in decode or execute?
>
> Would they output a sequence of (internal) instructions (which I assume
> would be the case if they sit in the decoder), or would they act more
> like controllers (which I assume would be the case if they sit in the
> EU:s)?

I guess I've got a similar question:
when a "most simple op" is translated from one ISA-op to one micro-op,
or "almost simple op" goes one ISA-op to two micro-op....
are these micro-op templates stitched using logic,
or is there some template in a small ROM so that you can lookup + fill the blanks
(eg: copy the register number as-is in bits 20..25) ?

> /Marcus

On Thursday, June 24, 2021 at 1:56:56 AM UTC-5, Marcus wrote:
> I guess this is mostly a question for Mitch...
>
> I have seen the terms "sequencer" and "microcode" being used, and while
> I think that I know what microcode is, I'm not sure what the definition
> of a sequencer is.
>
> AFAIK microcode (at least in the context of a traditional multi-CPI
> machine) sits in the decoder and pumps out "micro instructions" from
> a microcode ROM - often more than one micro instruction per instruction.
<
There are function units which have a myriad of sequences to run and they
might be implemented with microcode, too. You are restricting microcode
to the "pipeline control" (Decoder through Writeback).
<
But microcode requires a ROM that is programmable after it is designed
and laid out. Often with a few additional words that are programmable
even so far as after power on.
<
> I guess that in modern CISC implementations (e.g. x86) the microcode is
> part of the translation front end, and probably only as an optional part
> to cover for the cases that the fast-path translators can not deal with.
>
> Anyway... How about a sequencer? My understanding is that it is a
> simpler variant that does not need a microcode ROM - e.g. it could be an
> FSM or just a counter, right?
<
A sequencer is a machine that receives various inputs and asserts a sequence
of control lines that cause the HW to perform "stuff" in certain sequences.
Early IRCS machiens would have a single sequencer "run" the pipeline.
Some RISC machines had a sequencer that "ran" the FP ADD unit (FADD, FCMP,
FDIV,...) or "ran" the FP MUL unit (FMUL, IMUL, UMUL)
<
Many people have a mistaken belief that a sequencer necessarily has a single
point of control, this is not correct, a sequencer for PDP-11 will have at least
4 sequencer within the "sequencer" (en-the-large) 1 of these sequence out
Fetch requests, 2 of these sequence out address modes, and one sequences
out the data path. {This is why HW is not SW and never can be}
>
> For instance could the vector control unit in my scalar MRISC32-A1
> implementation, which is basically a counter that stalls the front end
> while iterating over vector register elements, be considered to be a
> sequencer? How about the control unit for an iterative divider?
<
Both of these are sequencers, and a "sequencer" can be implemented in
several ways, gates and flip-flops at one end of the spectrum, microcode
at the other end.
>
> When talking about using a sequencer to implement My 66000 instructions
> such as ENTER, EXIT and MM - where would those sequencers typically be
> located? E.g. in decode or execute?
<
AGEN would have these sequencers, after all, most of what they do is to
spew addresses at the cache. The "math" the ENTER and EXIT perform
is easily a subset of AGEN arithmetic.
>
> Would they output a sequence of (internal) instructions (which I assume
> would be the case if they sit in the decoder), or would they act more
> like controllers (which I assume would be the case if they sit in the
> EU:s)?
<
Its more like the instruction shows up (ENTER) and AGEN spews out cache
addresses and register read requests to stream registers onto the stack
and finishes with stores to SP and optionally to FP.
<
The front end sees 1 instruction and then the AGEN unit is busy until it
is no longer busy. The front end is allowed to start executing instructions
that are not dependent on the register to stack movement and not needing
the AGEN unit.
>
> /Marcus

On Thursday, June 24, 2021 at 3:45:45 AM UTC-5, winden wrote:
> On Thursday, June 24, 2021 at 8:56:56 AM UTC+2, Marcus wrote:
> > I guess this is mostly a question for Mitch...
> >
> > I have seen the terms "sequencer" and "microcode" being used, and while
> > I think that I know what microcode is, I'm not sure what the definition
> > of a sequencer is.
> >
> > AFAIK microcode (at least in the context of a traditional multi-CPI
> > machine) sits in the decoder and pumps out "micro instructions" from
> > a microcode ROM - often more than one micro instruction per instruction.
> > I guess that in modern CISC implementations (e.g. x86) the microcode is
> > part of the translation front end, and probably only as an optional part
> > to cover for the cases that the fast-path translators can not deal with.
> >
> > Anyway... How about a sequencer? My understanding is that it is a
> > simpler variant that does not need a microcode ROM - e.g. it could be an
> > FSM or just a counter, right?
> >
> > For instance could the vector control unit in my scalar MRISC32-A1
> > implementation, which is basically a counter that stalls the front end
> > while iterating over vector register elements, be considered to be a
> > sequencer? How about the control unit for an iterative divider?
<
> I'd could all these as sequencer-driven, because the circuit can be done with
> just <100 gates configured for the exact formulas you need.
<
The CRAY machines used a shift register sequencer. The decoder saw a
vector instruction and then searched for a place to set 64 active bits in
a function unit sequencer. Then, once issued, the sequencer is simply
"advance the shift register" until it is empty.
<
> > When talking about using a sequencer to implement My 66000 instructions
> > such as ENTER, EXIT and MM - where would those sequencers typically be
> > located? E.g. in decode or execute?
> >
> > Would they output a sequence of (internal) instructions (which I assume
> > would be the case if they sit in the decoder), or would they act more
> > like controllers (which I assume would be the case if they sit in the
> > EU:s)?
<
> I guess I've got a similar question:
> when a "most simple op" is translated from one ISA-op to one micro-op,
> or "almost simple op" goes one ISA-op to two micro-op....
> are these micro-op templates stitched using logic,
> or is there some template in a small ROM so that you can lookup + fill the blanks
> (eg: copy the register number as-is in bits 20..25) ?
<
I would no longer do it this way--I would keep the ops=instruction relationship
and build reservation stations that fire more than once and fire at the FU that
can provide the required service. So a LD-OP-ST would fire 3 times, once to
LD, once to calculate, and once to store (with already known address).
>
>
> > /Marcus

On Thursday, June 24, 2021 at 11:45:49 AM UTC-5, MitchAlsup wrote:
> On Thursday, June 24, 2021 at 3:45:45 AM UTC-5, winden wrote:
> > On Thursday, June 24, 2021 at 8:56:56 AM UTC+2, Marcus wrote:
> > > I guess this is mostly a question for Mitch...
> > >
> > > I have seen the terms "sequencer" and "microcode" being used, and while
> > > I think that I know what microcode is, I'm not sure what the definition
> > > of a sequencer is.
> > >
> > > AFAIK microcode (at least in the context of a traditional multi-CPI
> > > machine) sits in the decoder and pumps out "micro instructions" from
> > > a microcode ROM - often more than one micro instruction per instruction.
> > > I guess that in modern CISC implementations (e.g. x86) the microcode is
> > > part of the translation front end, and probably only as an optional part
> > > to cover for the cases that the fast-path translators can not deal with.
> > >
> > > Anyway... How about a sequencer? My understanding is that it is a
> > > simpler variant that does not need a microcode ROM - e.g. it could be an
> > > FSM or just a counter, right?
> > >
> > > For instance could the vector control unit in my scalar MRISC32-A1
> > > implementation, which is basically a counter that stalls the front end
> > > while iterating over vector register elements, be considered to be a
> > > sequencer? How about the control unit for an iterative divider?
> <
> > I'd could all these as sequencer-driven, because the circuit can be done with
> > just <100 gates configured for the exact formulas you need.
> <
> The CRAY machines used a shift register sequencer. The decoder saw a
> vector instruction and then searched for a place to set 64 active bits in
> a function unit sequencer. Then, once issued, the sequencer is simply
> "advance the shift register" until it is empty.
> <
> > > When talking about using a sequencer to implement My 66000 instructions
> > > such as ENTER, EXIT and MM - where would those sequencers typically be
> > > located? E.g. in decode or execute?
> > >
> > > Would they output a sequence of (internal) instructions (which I assume
> > > would be the case if they sit in the decoder), or would they act more
> > > like controllers (which I assume would be the case if they sit in the
> > > EU:s)?
> <
> > I guess I've got a similar question:
> > when a "most simple op" is translated from one ISA-op to one micro-op,
> > or "almost simple op" goes one ISA-op to two micro-op....
> > are these micro-op templates stitched using logic,
> > or is there some template in a small ROM so that you can lookup + fill the blanks
> > (eg: copy the register number as-is in bits 20..25) ?
> <
> I would no longer do it this way--I would keep the ops=instruction relationship
> and build reservation stations that fire more than once and fire at the FU that
> can provide the required service. So a LD-OP-ST would fire 3 times, once to
> LD, once to calculate, and once to store (with already known address).
<
Of course, doing it with multi-fire reservation stations almost requires one to
have the FP registers and the non-FP registers topologically adjacent to each
other so one can LD-OP-ST floating point arithmetic as well as integer.
<
> >
> >
> > > /Marcus

On 2021-06-24, MitchAlsup wrote:
> On Thursday, June 24, 2021 at 1:56:56 AM UTC-5, Marcus wrote:
>> I guess this is mostly a question for Mitch...
>>
>> I have seen the terms "sequencer" and "microcode" being used, and while
>> I think that I know what microcode is, I'm not sure what the definition
>> of a sequencer is.
>>
>> AFAIK microcode (at least in the context of a traditional multi-CPI
>> machine) sits in the decoder and pumps out "micro instructions" from
>> a microcode ROM - often more than one micro instruction per instruction.
> <
> There are function units which have a myriad of sequences to run and they
> might be implemented with microcode, too. You are restricting microcode
> to the "pipeline control" (Decoder through Writeback).
> <
> But microcode requires a ROM that is programmable after it is designed
> and laid out. Often with a few additional words that are programmable
> even so far as after power on.
> <
>> I guess that in modern CISC implementations (e.g. x86) the microcode is
>> part of the translation front end, and probably only as an optional part
>> to cover for the cases that the fast-path translators can not deal with.
>>
>> Anyway... How about a sequencer? My understanding is that it is a
>> simpler variant that does not need a microcode ROM - e.g. it could be an
>> FSM or just a counter, right?
> <
> A sequencer is a machine that receives various inputs and asserts a sequence
> of control lines that cause the HW to perform "stuff" in certain sequences.
> Early IRCS machiens would have a single sequencer "run" the pipeline.
> Some RISC machines had a sequencer that "ran" the FP ADD unit (FADD, FCMP,
> FDIV,...) or "ran" the FP MUL unit (FMUL, IMUL, UMUL)
> <
> Many people have a mistaken belief that a sequencer necessarily has a single
> point of control, this is not correct, a sequencer for PDP-11 will have at least
> 4 sequencer within the "sequencer" (en-the-large) 1 of these sequence out
> Fetch requests, 2 of these sequence out address modes, and one sequences
> out the data path. {This is why HW is not SW and never can be}
>>
>> For instance could the vector control unit in my scalar MRISC32-A1
>> implementation, which is basically a counter that stalls the front end
>> while iterating over vector register elements, be considered to be a
>> sequencer? How about the control unit for an iterative divider?
> <
> Both of these are sequencers, and a "sequencer" can be implemented in
> several ways, gates and flip-flops at one end of the spectrum, microcode
> at the other end.
>>
>> When talking about using a sequencer to implement My 66000 instructions
>> such as ENTER, EXIT and MM - where would those sequencers typically be
>> located? E.g. in decode or execute?
> <
> AGEN would have these sequencers, after all, most of what they do is to
> spew addresses at the cache. The "math" the ENTER and EXIT perform
> is easily a subset of AGEN arithmetic.
>>
>> Would they output a sequence of (internal) instructions (which I assume
>> would be the case if they sit in the decoder), or would they act more
>> like controllers (which I assume would be the case if they sit in the
>> EU:s)?
> <
> Its more like the instruction shows up (ENTER) and AGEN spews out cache
> addresses and register read requests to stream registers onto the stack
> and finishes with stores to SP and optionally to FP.
> <
> The front end sees 1 instruction and then the AGEN unit is busy until it
> is no longer busy. The front end is allowed to start executing instructions
> that are not dependent on the register to stack movement and not needing
> the AGEN unit.

Thanks for taking the time to explain! That cleared things up a great
deal for me.

/Marcus

On 6/25/2021 12:51 PM, Marcus wrote:
> On 2021-06-24, MitchAlsup wrote:
>> On Thursday, June 24, 2021 at 1:56:56 AM UTC-5, Marcus wrote:
>>> I guess this is mostly a question for Mitch...
>>>
>>> I have seen the terms "sequencer" and "microcode" being used, and while
>>> I think that I know what microcode is, I'm not sure what the definition
>>> of a sequencer is.
>>>
>>> AFAIK microcode (at least in the context of a traditional multi-CPI
>>> machine) sits in the decoder and pumps out "micro instructions" from
>>> a microcode ROM - often more than one micro instruction per instruction.
>> <
>> There are function units which have a myriad of sequences to run and they
>> might be implemented with microcode, too. You are restricting microcode
>> to the "pipeline control" (Decoder through Writeback).
>> <
>> But microcode requires a ROM that is programmable after it is designed
>> and laid out. Often with a few additional words that are programmable
>> even so far as after power on.
>> <
>>> I guess that in modern CISC implementations (e.g. x86) the microcode is
>>> part of the translation front end, and probably only as an optional part
>>> to cover for the cases that the fast-path translators can not deal with.
>>>
>>> Anyway... How about a sequencer? My understanding is that it is a
>>> simpler variant that does not need a microcode ROM - e.g. it could be an
>>> FSM or just a counter, right?
>> <
>> A sequencer is a machine that receives various inputs and asserts a
>> sequence
>> of control lines that cause the HW to perform "stuff" in certain
>> sequences.
>> Early IRCS machiens would have a single sequencer "run" the pipeline.
>> Some RISC machines had a sequencer that "ran" the FP ADD unit (FADD,
>> FCMP,
>> FDIV,...) or "ran" the FP MUL unit (FMUL, IMUL, UMUL)
>> <
>> Many people have a mistaken belief that a sequencer necessarily has a
>> single
>> point of control, this is not correct, a sequencer for PDP-11 will
>> have at least
>> 4 sequencer within the "sequencer" (en-the-large) 1 of these sequence out
>> Fetch requests, 2 of these sequence out address modes, and one sequences
>> out the data path. {This is why HW is not SW and never can be}
>>>
>>> For instance could the vector control unit in my scalar MRISC32-A1
>>> implementation, which is basically a counter that stalls the front end
>>> while iterating over vector register elements, be considered to be a
>>> sequencer? How about the control unit for an iterative divider?
>> <
>> Both of these are sequencers, and a "sequencer" can be implemented in
>> several ways, gates and flip-flops at one end of the spectrum, microcode
>> at the other end.
>>>
>>> When talking about using a sequencer to implement My 66000 instructions
>>> such as ENTER, EXIT and MM - where would those sequencers typically be
>>> located? E.g. in decode or execute?
>> <
>> AGEN would have these sequencers, after all, most of what they do is to
>> spew addresses at the cache. The "math" the ENTER and EXIT perform
>> is easily a subset of AGEN arithmetic.
>>>
>>> Would they output a sequence of (internal) instructions (which I assume
>>> would be the case if they sit in the decoder), or would they act more
>>> like controllers (which I assume would be the case if they sit in the
>>> EU:s)?
>> <
>> Its more like the instruction shows up (ENTER) and AGEN spews out cache
>> addresses and register read requests to stream registers onto the stack
>> and finishes with stores to SP and optionally to FP.
>> <
>> The front end sees 1 instruction and then the AGEN unit is busy until it
>> is no longer busy. The front end is allowed to start executing
>> instructions
>> that are not dependent on the register to stack movement and not needing
>> the AGEN unit.
>
> Thanks for taking the time to explain! That cleared things up a great
> deal for me.
>

I had previously considered possibly adding such a "sequencer" to BJX2,
which could have allowed a few operations which can't currently be done
via a single operation; or possibly allow "MOV.X" operations on a 1-wide
core, ...

This would likely involve adding another split and stall signal to the
pipeline, which can stall IF and ID1 (Input Side), but allow ID1 to emit
new ops, and ID2 and the EX stages to continue on as normal.

Hadn't done so yet, as it seems like a bit of added cost and complexity.

Or maybe even a microcode ROM, but this seems like a lot of extra
complexity. Could also need banked registers, or reserving that certain
registers may be stomped during the operation (eg: "This instruction may
leave R0/R1 and R32..R35 in an undefined state" or similar).

So, say, there is an internal pipeline register 'UXPC' where:
UXPC = 0, Instructions come from I$
UXPC != 0, Instructions come from UXROM, IF is stalled.

Where, say, triggering a microcode op:
Copies Rm and Ro to R0 and R1 or similar;
Sets UXPC to a non-zero address.

Possibly, the UXROM is 108 bits wide:
96 bits: VLIW bundle;
12 bits: Next UXPC + Control Tag (0 for End).

As soon as the Next UXPC is 0, whatever is in R0 is redirected to the
original Rn. The UXROM code could resemble normal BJX2 code, just
hard-wired into 3-wide WEX mode (with Lanes 2/3 padded with NOPs when
unused).

The 12-bit code would encode control-flow within the UXROM as a sort of
special mini-instruction (Branch-Continue, Terminate, Branch-True,
Branch-False, Branch-True-Or-Terminate, Branch-False-Or-Terminate). Note
that the ROM would likely be fairly small.

The banked case would be similar, except that and maybe R16..R23 or
similar, would be remapped to special internal registers and not effect
externally visible state (possibly Rs/Rt/Ru/Rv/Rx/Ry =>
R4/R6/R5/R7/R2/R3, with termination mapping R2/R3 to Rn or Xn).

This approach could have a lot less performance overhead than using an
interrupt or similar though (it is typically a lot faster/cheaper to use
function calls for these sorts of cases than to use an interrupt handler).

Cost could be a concern though...

> /Marcus

On Friday, June 25, 2021 at 2:17:23 PM UTC-5, BGB wrote:
> On 6/25/2021 12:51 PM, Marcus wrote:
> > On 2021-06-24, MitchAlsup wrote:
> >> On Thursday, June 24, 2021 at 1:56:56 AM UTC-5, Marcus wrote:
> >>> I guess this is mostly a question for Mitch...
> >>>
> >>> I have seen the terms "sequencer" and "microcode" being used, and while
> >>> I think that I know what microcode is, I'm not sure what the definition
> >>> of a sequencer is.
> >>>
> >>> AFAIK microcode (at least in the context of a traditional multi-CPI
> >>> machine) sits in the decoder and pumps out "micro instructions" from
> >>> a microcode ROM - often more than one micro instruction per instruction.
> >> <
> >> There are function units which have a myriad of sequences to run and they
> >> might be implemented with microcode, too. You are restricting microcode
> >> to the "pipeline control" (Decoder through Writeback).
> >> <
> >> But microcode requires a ROM that is programmable after it is designed
> >> and laid out. Often with a few additional words that are programmable
> >> even so far as after power on.
> >> <
> >>> I guess that in modern CISC implementations (e.g. x86) the microcode is
> >>> part of the translation front end, and probably only as an optional part
> >>> to cover for the cases that the fast-path translators can not deal with.
> >>>
> >>> Anyway... How about a sequencer? My understanding is that it is a
> >>> simpler variant that does not need a microcode ROM - e.g. it could be an
> >>> FSM or just a counter, right?
> >> <
> >> A sequencer is a machine that receives various inputs and asserts a
> >> sequence
> >> of control lines that cause the HW to perform "stuff" in certain
> >> sequences.
> >> Early IRCS machiens would have a single sequencer "run" the pipeline.
> >> Some RISC machines had a sequencer that "ran" the FP ADD unit (FADD,
> >> FCMP,
> >> FDIV,...) or "ran" the FP MUL unit (FMUL, IMUL, UMUL)
> >> <
> >> Many people have a mistaken belief that a sequencer necessarily has a
> >> single
> >> point of control, this is not correct, a sequencer for PDP-11 will
> >> have at least
> >> 4 sequencer within the "sequencer" (en-the-large) 1 of these sequence out
> >> Fetch requests, 2 of these sequence out address modes, and one sequences
> >> out the data path. {This is why HW is not SW and never can be}
> >>>
> >>> For instance could the vector control unit in my scalar MRISC32-A1
> >>> implementation, which is basically a counter that stalls the front end
> >>> while iterating over vector register elements, be considered to be a
> >>> sequencer? How about the control unit for an iterative divider?
> >> <
> >> Both of these are sequencers, and a "sequencer" can be implemented in
> >> several ways, gates and flip-flops at one end of the spectrum, microcode
> >> at the other end.
> >>>
> >>> When talking about using a sequencer to implement My 66000 instructions
> >>> such as ENTER, EXIT and MM - where would those sequencers typically be
> >>> located? E.g. in decode or execute?
> >> <
> >> AGEN would have these sequencers, after all, most of what they do is to
> >> spew addresses at the cache. The "math" the ENTER and EXIT perform
> >> is easily a subset of AGEN arithmetic.
> >>>
> >>> Would they output a sequence of (internal) instructions (which I assume
> >>> would be the case if they sit in the decoder), or would they act more
> >>> like controllers (which I assume would be the case if they sit in the
> >>> EU:s)?
> >> <
> >> Its more like the instruction shows up (ENTER) and AGEN spews out cache
> >> addresses and register read requests to stream registers onto the stack
> >> and finishes with stores to SP and optionally to FP.
> >> <
> >> The front end sees 1 instruction and then the AGEN unit is busy until it
> >> is no longer busy. The front end is allowed to start executing
> >> instructions
> >> that are not dependent on the register to stack movement and not needing
> >> the AGEN unit.
> >
> > Thanks for taking the time to explain! That cleared things up a great
> > deal for me.
> >
> I had previously considered possibly adding such a "sequencer" to BJX2,
> which could have allowed a few operations which can't currently be done
> via a single operation; or possibly allow "MOV.X" operations on a 1-wide
> core, ...
<
When I did this in Mc 88100, we simply made the AGEN unit go busy if it were
processing a DoubleWord LD or ST. This was the same Busy the main pipeline
would get if the Cache took a miss or a snoop prevented a LD or ST from
accessing the cache.
>
> This would likely involve adding another split and stall signal to the
> pipeline, which can stall IF and ID1 (Input Side), but allow ID1 to emit
> new ops, and ID2 and the EX stages to continue on as normal.
>
> Hadn't done so yet, as it seems like a bit of added cost and complexity.
>
>
>
> Or maybe even a microcode ROM, but this seems like a lot of extra
> complexity. Could also need banked registers, or reserving that certain
> registers may be stomped during the operation (eg: "This instruction may
> leave R0/R1 and R32..R35 in an undefined state" or similar).
<
In Mc 88100 we simply used a state machine to cycle off the long FDIV
sequences--it was a counting problem not a hairy sequencing problem.
>
> So, say, there is an internal pipeline register 'UXPC' where:
> UXPC = 0, Instructions come from I$
> UXPC != 0, Instructions come from UXROM, IF is stalled.
>
> Where, say, triggering a microcode op:
> Copies Rm and Ro to R0 and R1 or similar;
> Sets UXPC to a non-zero address.
>
> Possibly, the UXROM is 108 bits wide:
> 96 bits: VLIW bundle;
> 12 bits: Next UXPC + Control Tag (0 for End).
>
> As soon as the Next UXPC is 0, whatever is in R0 is redirected to the
> original Rn. The UXROM code could resemble normal BJX2 code, just
> hard-wired into 3-wide WEX mode (with Lanes 2/3 padded with NOPs when
> unused).
>
> The 12-bit code would encode control-flow within the UXROM as a sort of
> special mini-instruction (Branch-Continue, Terminate, Branch-True,
> Branch-False, Branch-True-Or-Terminate, Branch-False-Or-Terminate). Note
> that the ROM would likely be fairly small.
>
>
> The banked case would be similar, except that and maybe R16..R23 or
> similar, would be remapped to special internal registers and not effect
> externally visible state (possibly Rs/Rt/Ru/Rv/Rx/Ry =>
> R4/R6/R5/R7/R2/R3, with termination mapping R2/R3 to Rn or Xn).
>
> This approach could have a lot less performance overhead than using an
> interrupt or similar though (it is typically a lot faster/cheaper to use
> function calls for these sorts of cases than to use an interrupt handler).
>
> Cost could be a concern though...
>
>
> > /Marcus

What about the exec instruction? I had the thought that with vector registers maybe a vector exec instruction could be implemented. A snippet of program code could be stored in a vector register then executed with a vector exec instruction. This is a little bit like having micro-code executed.
Using a vector register it would be possible to pass program code to routines. I think the Clipper database language had the ability to pass code to routines.

On 6/25/2021 2:52 PM, MitchAlsup wrote:
> On Friday, June 25, 2021 at 2:17:23 PM UTC-5, BGB wrote:
>> On 6/25/2021 12:51 PM, Marcus wrote:
>>> On 2021-06-24, MitchAlsup wrote:
>>>> On Thursday, June 24, 2021 at 1:56:56 AM UTC-5, Marcus wrote:
>>>>> I guess this is mostly a question for Mitch...
>>>>>
>>>>> I have seen the terms "sequencer" and "microcode" being used, and while
>>>>> I think that I know what microcode is, I'm not sure what the definition
>>>>> of a sequencer is.
>>>>>
>>>>> AFAIK microcode (at least in the context of a traditional multi-CPI
>>>>> machine) sits in the decoder and pumps out "micro instructions" from
>>>>> a microcode ROM - often more than one micro instruction per instruction.
>>>> <
>>>> There are function units which have a myriad of sequences to run and they
>>>> might be implemented with microcode, too. You are restricting microcode
>>>> to the "pipeline control" (Decoder through Writeback).
>>>> <
>>>> But microcode requires a ROM that is programmable after it is designed
>>>> and laid out. Often with a few additional words that are programmable
>>>> even so far as after power on.
>>>> <
>>>>> I guess that in modern CISC implementations (e.g. x86) the microcode is
>>>>> part of the translation front end, and probably only as an optional part
>>>>> to cover for the cases that the fast-path translators can not deal with.
>>>>>
>>>>> Anyway... How about a sequencer? My understanding is that it is a
>>>>> simpler variant that does not need a microcode ROM - e.g. it could be an
>>>>> FSM or just a counter, right?
>>>> <
>>>> A sequencer is a machine that receives various inputs and asserts a
>>>> sequence
>>>> of control lines that cause the HW to perform "stuff" in certain
>>>> sequences.
>>>> Early IRCS machiens would have a single sequencer "run" the pipeline.
>>>> Some RISC machines had a sequencer that "ran" the FP ADD unit (FADD,
>>>> FCMP,
>>>> FDIV,...) or "ran" the FP MUL unit (FMUL, IMUL, UMUL)
>>>> <
>>>> Many people have a mistaken belief that a sequencer necessarily has a
>>>> single
>>>> point of control, this is not correct, a sequencer for PDP-11 will
>>>> have at least
>>>> 4 sequencer within the "sequencer" (en-the-large) 1 of these sequence out
>>>> Fetch requests, 2 of these sequence out address modes, and one sequences
>>>> out the data path. {This is why HW is not SW and never can be}
>>>>>
>>>>> For instance could the vector control unit in my scalar MRISC32-A1
>>>>> implementation, which is basically a counter that stalls the front end
>>>>> while iterating over vector register elements, be considered to be a
>>>>> sequencer? How about the control unit for an iterative divider?
>>>> <
>>>> Both of these are sequencers, and a "sequencer" can be implemented in
>>>> several ways, gates and flip-flops at one end of the spectrum, microcode
>>>> at the other end.
>>>>>
>>>>> When talking about using a sequencer to implement My 66000 instructions
>>>>> such as ENTER, EXIT and MM - where would those sequencers typically be
>>>>> located? E.g. in decode or execute?
>>>> <
>>>> AGEN would have these sequencers, after all, most of what they do is to
>>>> spew addresses at the cache. The "math" the ENTER and EXIT perform
>>>> is easily a subset of AGEN arithmetic.
>>>>>
>>>>> Would they output a sequence of (internal) instructions (which I assume
>>>>> would be the case if they sit in the decoder), or would they act more
>>>>> like controllers (which I assume would be the case if they sit in the
>>>>> EU:s)?
>>>> <
>>>> Its more like the instruction shows up (ENTER) and AGEN spews out cache
>>>> addresses and register read requests to stream registers onto the stack
>>>> and finishes with stores to SP and optionally to FP.
>>>> <
>>>> The front end sees 1 instruction and then the AGEN unit is busy until it
>>>> is no longer busy. The front end is allowed to start executing
>>>> instructions
>>>> that are not dependent on the register to stack movement and not needing
>>>> the AGEN unit.
>>>
>>> Thanks for taking the time to explain! That cleared things up a great
>>> deal for me.
>>>
>> I had previously considered possibly adding such a "sequencer" to BJX2,
>> which could have allowed a few operations which can't currently be done
>> via a single operation; or possibly allow "MOV.X" operations on a 1-wide
>> core, ...
> <
> When I did this in Mc 88100, we simply made the AGEN unit go busy if it were
> processing a DoubleWord LD or ST. This was the same Busy the main pipeline
> would get if the Cache took a miss or a snoop prevented a LD or ST from
> accessing the cache.

OK. I had considered that ID1 would do something funky and turn it into
a pair of MOV.Q ops ...

But, then it is unclear how much sense it makes in this case, vs just
having the compiler emit a pair of MOV.Q ops if targeting a core which
doesn't have MOV.X ...

Granted, it does mean that compiler options have to be set to match the
CPU feature set, otherwise, code is either sub-optimal (doesn't use a
feature which exists; or can only use it indirectly via function calls,
....), or doesn't work at all if it tries to use a feature which doesn't
exist.

This is "probably not ideal" for something meant as a general purpose
ISA, but is pretty standard in embedded (where one frequently needs to
tell the compiler the specific model of the specific processor to
generate code for).

But, the other extreme is something like x86, where they try to keep
hardware support for every feature of every previous x86 chip which
every existed (whether or not the features still make sense).

I suspect, at some point, emulation may make more sense than trying to
keep the same hardware ISA. Though, there is the issue that this puts
this under the control of the OS, and even some OS's which were known
for this (eg, Windows) kinda drag their feet (meaning that one needs to
use 3rd party emulators to run 30 year old binaries).

Granted, I have yet to decide what the eventual "redistributable binary
format" will be, or even if such a thing makes sense for my project.

Would almost assume trying to use something "off the shelf", except that
the existing mainstream options (JVM, .NET, Dalvik, ...), "kinda suck".
Also not really a fan of "just use repurposed LLVM IR".

One of the front-runner options is "Use WAD files holding RIL3 Bytecode
blobs" (doesn't really require much in terms of "new technology" on my
part), but this option "still kinda sucks". However, RIL3 is high-level
enough to at least mostly gloss-over machine-specific issues (it is a
stack machine along vaguely similar lines to .NET bytecode hybridized
with parts of PostScript; and the wackiness that rather than metadata
being structure-based or similar, the entire bytecode image is basically
a single massive blob of bytecode which is linearly interpreted to
rebuild all the various compiler structures and metadata... Or,
basically, "it seemed like a good idea at the time"...).

Also, unlike some of the other options, it is reasonably well adapted to
C and C++ and similar, and also supports inline ASM and a few other
useful features, ...

Taken slightly further, it is possible that the ".ifarch" feature could
be extended to allow inline ASM blobs with multiple instruction sets, or
maybe be extended to functions:
__declspec(ifnarch(BJX2)) void Foo() { ... }
So the function will only generate machine-code for machine if not
running on BJX2 (could be further wrapped in preprocessor macros to
retain compatibility with other compilers).

Likewise:
__declspec(ifarch(BJX2)) __asm {
Foo:
...
};

Would only emit the inline ASM blob if generating code for BJX2, but
allow falling back to a C version otherwise (and ".ifarch" can be used
within the ASM code to generate different code based on ISA feature flags).

Possibly:
__declspec(ifarch(BJX2,A32,A64)) ...
Is true if any of these is present.
__declspec(ifnarch(BJX2,A32,A64)) ...
Is true if none of these is present.

On 2021-06-26, robf...@gmail.com wrote:
> What about the exec instruction? I had the thought that with vector registers maybe a vector exec instruction could be implemented. A snippet of program code could be stored in a vector register then executed with a vector exec instruction. This is a little bit like having micro-code executed.
> Using a vector register it would be possible to pass program code to routines. I think the Clipper database language had the ability to pass code to routines.
>

My initial feeling is that it's not a good idea. First off vector
register content (i.e. register file read or operand forwarding) is
usually not available at the "right" pipeline stage for executing
code (i.e. decode), and some instructions (branches) would be
difficult / infeasible (so it wouldn't be easy to do loops or
if:s in the code snippet, for instance).

Second it feels like a security issue, with similar problems as
"eval"-style commands in some programming languages.

That does not mean that it's not possible to execute code from a
vector register - but it's one of those things that could prove
problematic in many ways, and could place undesirable restrictions
on the implementation.

/Marcus

On Saturday, June 26, 2021 at 8:11:42 AM UTC-4, Marcus wrote:
> On 2021-06-26, robf...@gmail.com wrote:
> > What about the exec instruction? I had the thought that with vector registers maybe a vector exec instruction could be implemented. A snippet of program code could be stored in a vector register then executed with a vector exec instruction. This is a little bit like having micro-code executed.
> > Using a vector register it would be possible to pass program code to routines. I think the Clipper database language had the ability to pass code to routines.
> >
> My initial feeling is that it's not a good idea. First off vector
> register content (i.e. register file read or operand forwarding) is
> usually not available at the "right" pipeline stage for executing
> code (i.e. decode), and some instructions (branches) would be
> difficult / infeasible (so it wouldn't be easy to do loops or
> if:s in the code snippet, for instance).
>
> Second it feels like a security issue, with similar problems as
> "eval"-style commands in some programming languages.
>
> That does not mean that it's not possible to execute code from a
> vector register - but it's one of those things that could prove
> problematic in many ways, and could place undesirable restrictions
> on the implementation.
>
> /Marcus

Implementing a vector exec may be a little easier in my case. Vector instructions already get repeatedly dumped to the re-order queue after decode. It would not take much to set the IR field in the queue to the value of a register, then flag the register values as invalid. There is already a ‘dec’ flag indicating that the instruction has been properly decoded. That could be set to false at queue time. It might take a second decoder though dedicated to decoding un-decoded instructions in the queue. The trick would be to get some form of branching working, as you say. I am thinking that maybe branching to a particular vector element might be possible if it is in the queue. It would take searching the queue for the right element. Some portion of a branch instruction address range could be used to indicate branching to elements, but the range allowed would be very small, ±8. It does get tricky to do. Probably not worthwhile to implement, but it would be a “cool” feature. OTOH I am kinda bored, I suppose I could wrap the implementation up in #if directives to make it optional..

On Friday, June 25, 2021 at 10:10:59 PM UTC-5, robf...@gmail.com wrote:
> What about the exec instruction? I had the thought that with vector registers maybe a vector exec instruction could be implemented. A snippet of program code could be stored in a vector register then executed with a vector exec instruction. This is a little bit like having micro-code executed.
<
On the EXC instruction, due to a host of reasons, these have passed out of favor.
<
As to Vector, When I looked into this, it ended up to be much more performant and less costly
to vectorize loops rather than vectorizing instructions. And this is where VEC an LOOP instructions
come from in My 66000 as the bookends of the Virtual Vector Method.
<
> Using a vector register it would be possible to pass program code to routines. I think the Clipper database language had the ability to pass code to routines.
<
What is wrong with passing a pointer to a subroutine and calling the code.

On Saturday, June 26, 2021 at 8:35:21 AM UTC-5, robf...@gmail.com wrote:
> On Saturday, June 26, 2021 at 8:11:42 AM UTC-4, Marcus wrote:
> > On 2021-06-26, robf...@gmail.com wrote:
> > > What about the exec instruction? I had the thought that with vector registers maybe a vector exec instruction could be implemented. A snippet of program code could be stored in a vector register then executed with a vector exec instruction. This is a little bit like having micro-code executed.
> > > Using a vector register it would be possible to pass program code to routines. I think the Clipper database language had the ability to pass code to routines.
> > >
> > My initial feeling is that it's not a good idea. First off vector
> > register content (i.e. register file read or operand forwarding) is
> > usually not available at the "right" pipeline stage for executing
> > code (i.e. decode), and some instructions (branches) would be
> > difficult / infeasible (so it wouldn't be easy to do loops or
> > if:s in the code snippet, for instance).
> >
> > Second it feels like a security issue, with similar problems as
> > "eval"-style commands in some programming languages.
> >
> > That does not mean that it's not possible to execute code from a
> > vector register - but it's one of those things that could prove
> > problematic in many ways, and could place undesirable restrictions
> > on the implementation.
> >
> > /Marcus
> Implementing a vector exec may be a little easier in my case. Vector instructions already get repeatedly dumped to the re-order queue after decode. It would not take much to set the IR field in the queue to the value of a register, then flag the register values as invalid. There is already a ‘dec’ flag indicating that the instruction has been properly decoded. That could be set to false at queue time. It might take a second decoder though dedicated to decoding un-decoded instructions in the queue. The trick would be to get some form of branching working, as you say. I am thinking that maybe branching to a particular vector element might be possible if it is in the queue. It would take searching the queue for the right element. Some portion of a branch instruction address range could be used to indicate branching to elements, but the range allowed would be very small, ±8. It does get tricky to do. Probably not worthwhile to implement, but it would be a “cool” feature. OTOH I am kinda bored, I suppose I could wrap the implementation up in #if directives to make it optional.
<
To show the extent of my disfavor for EXC, in My 66000 one cannot execute code in a page
that is writable !

MitchAlsup wrote:
> <
> To show the extent of my disfavor for EXC, in My 66000 one cannot execute code in a page
> that is writable !

That forces JIT'ers and self modifiers to make a trip through
the OS to change the page protection from RW to RE.
Not that it is a bad thing as it does allow the OS to clean up model
specfic things like caches and prefetch buffers across multiple SMP cores.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>That forces JIT'ers and self modifiers to make a trip through
>the OS to change the page protection from RW to RE.

We won't be going there for the 66000. We will just disable JITting
for the 66000, like we do for every instruction set that requires
undue complications.

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

On Saturday, June 26, 2021 at 10:54:53 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > <
> > To show the extent of my disfavor for EXC, in My 66000 one cannot execute code in a page
> > that is writable !
> That forces JIT'ers and self modifiers to make a trip through
> the OS to change the page protection from RW to RE.
<
No, it requires the JIT to run in a different address mapping than the application
using the JITted code. Since this transition only costs 12 cycles plus cache
effects, it is well worth while.
<
> Not that it is a bad thing as it does allow the OS to clean up model
> specfic things like caches and prefetch buffers across multiple SMP cores.

>What is wrong with passing a pointer to a subroutine and calling the code.

Nothing wrong with passing pointers. But being able to pass code eliminates subroutine call and return overhead. I think with the database, one could store field validation code along with the metadata for a field, then load and run it in a generic routine at runtime. IIRC database engines allow constraints to be applied to field data. In this case it could be raw machine code.

The EXC instruction is a little on the slow side as I have it implemented. It decodes twice, after the first decode it clears the ‘dec’ flag in the queue causing it to be decoded a second time. The second time through it has the actual instruction to work with. One issue is EXC an EXC instruction causes an infinite decode loop. Starting to be more hardware than its worth to detect exceptions. Vector EXC is a little more complicated.

I added mystery ops to the ISA. This is a little bit like an EXC except that only the opcode / func is passed in a register. The register fetch fields remain the same as a regular instruction, so this instruction is fast. The execute logic looks at the value in the third register and selects the 2R operation accordingly. This instruction allows things like modifying match conditions in text processing without resorting to switch statements.

On 6/27/2021 3:11 PM, robf...@gmail.com wrote:
>> What is wrong with passing a pointer to a subroutine and calling the code.
>
> Nothing wrong with passing pointers. But being able to pass code eliminates subroutine call and return overhead. I think with the database, one could store field validation code along with the metadata for a field, then load and run it in a generic routine at runtime. IIRC database engines allow constraints to be applied to field data. In this case it could be raw machine code.
>
> The EXC instruction is a little on the slow side as I have it implemented. It decodes twice, after the first decode it clears the ‘dec’ flag in the queue causing it to be decoded a second time. The second time through it has the actual instruction to work with. One issue is EXC an EXC instruction causes an infinite decode loop. Starting to be more hardware than its worth to detect exceptions.

One pretty simple solution to this kind of problem that has been used in
the past is to start a timer/counter each time an instruction starts.
If the count exceeds some large number, generate an exception.

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

On Sunday, June 27, 2021 at 5:11:27 PM UTC-5, robf...@gmail.com wrote:
> >What is wrong with passing a pointer to a subroutine and calling the code.
<
> Nothing wrong with passing pointers. But being able to pass code eliminates subroutine call and return overhead.
<
Once you start having to set timers, or special case certain instructions (EXC) it is easier to not
have and EXC instruction and just bottle up code in a subroutine and simply call it. {Notice you
also have to special case CALL and RET instructions, indirect JMP instructions, SVC,.....}
<
> I think with the database, one could store field validation code along with the metadata for a field, then load and run it in a generic routine at runtime. IIRC database engines allow constraints to be applied to field data.. In this case it could be raw machine code.
>
> The EXC instruction is a little on the slow side as I have it implemented.. It decodes twice, after the first decode it clears the ‘dec’ flag in the queue causing it to be decoded a second time. The second time through it has the actual instruction to work with. One issue is EXC an EXC instruction causes an infinite decode loop. Starting to be more hardware than its worth to detect exceptions. Vector EXC is a little more complicated.
<
More complicated and still insufficient ! What if a code sequence you want to Vector EXC needs
65 instructions ? .....
>
> I added mystery ops to the ISA. This is a little bit like an EXC except that only the opcode / func is passed in a register. The register fetch fields remain the same as a regular instruction, so this instruction is fast. The execute logic looks at the value in the third register and selects the 2R operation accordingly. This instruction allows things like modifying match conditions in text processing without resorting to switch statements.

>One pretty simple solution to this kind of problem that has been used in
>the past is to start a timer/counter each time an instruction starts.
>If the count exceeds some large number, generate an exception.

That is a good idea to include, but I am a little stumped at the moment about implementation. ANY1 current imp. is an out-of-order machine, so multiple instructions may start before any of them finish. I have seen the core fire a string of store operations to the memory controller, then the queue sits idle for hundreds of cycles while the stores complete. It is not inconceivable that the processor could be caught up in an instruction start loop :) During debugging I have seen the core trying to execute the same instruction over and over again. Issue with the scheduler and the ‘out’ flag not being set properly.
It is almost necessary to time how long it has been since the queue last changed. If it’s more than 500 clocks then exception. Seem like monitoring one of the queue pointers might do the trick. The execute pointer and the decode pointer seemingly jump around randomly. Que and deque are supposed to proceed linearly.

>Once you start having to set timers, or special case certain instructions (EXC) it is easier to not
>have and EXC instruction and just bottle up code in a subroutine and simply call it. {Notice you
>also have to special case CALL and RET instructions, indirect JMP instructions, SVC,.....}

I decided to scrap the EXC instruction along with CALL and RET – as you say too much hardware for value added. There was a bug in the call instruction and branch-and-link, jump-and-link works just fine. Cost is a little bit less dense code. Opcodes for CALL and RET may be reserved so they can be emulated by software if desired, they would generate an unimplemented instruction trap. They could also be emulated with subroutines to get back the code density.

>>One pretty simple solution to this kind of problem that has been used in
>>the past is to start a timer/counter each time an instruction starts.
>>If the count exceeds some large number, generate an exception.
> That is a good idea to include, but I am a little stumped at the moment
> about implementation.

As a compiler/proglang guy, the one thing that stumps me instead here is "why?".
Why would you want, or when/where would you need something like an
"exec" opcode? It seems to me like a "solution" in search of a problem.

Stefan

Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>>One pretty simple solution to this kind of problem that has been used in
>>>the past is to start a timer/counter each time an instruction starts.
>>>If the count exceeds some large number, generate an exception.
>> That is a good idea to include, but I am a little stumped at the moment
>> about implementation.
>
> As a compiler/proglang guy, the one thing that stumps me instead here is "why?".
> Why would you want, or when/where would you need something like an
> "exec" opcode? It seems to me like a "solution" in search of a problem.

I have even missed what this exec opcode should do, to be frank.

Would it be like the UNIX exec() system call, or something else?

On Monday, June 28, 2021 at 11:14:07 AM UTC-4, Thomas Koenig wrote:
> Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> >>>One pretty simple solution to this kind of problem that has been used in
> >>>the past is to start a timer/counter each time an instruction starts.
> >>>If the count exceeds some large number, generate an exception.
> >> That is a good idea to include, but I am a little stumped at the moment
> >> about implementation.
> >
> > As a compiler/proglang guy, the one thing that stumps me instead here is "why?".
> > Why would you want, or when/where would you need something like an
> > "exec" opcode? It seems to me like a "solution" in search of a problem.
> I have even missed what this exec opcode should do, to be frank.
>
> Would it be like the UNIX exec() system call, or something else?

EXEC executes an instruction contained in a register. It would allow passing the instruction around in a program. The great benefit of EXEC is that it allows functionality of a routine to be altered without resorting to self-modified code. I missed this kind of thing when programming a graphics library. I ended up using self modifying code for performance reasons. EXEC could have been used to implement the raster-ops for instance. It could also be used in text processing software. It is far faster to use an EXEC instruction than the switch statement it typically replaces. It does have some benefit, but it is also costly to implement.
I have had EXEC like functionality available on one machine in the form of specialized code buffers. Code could be executed out of a buffer in a single clock cycle.

On 6/28/2021 7:21 AM, Stefan Monnier wrote:
>>> One pretty simple solution to this kind of problem that has been used in
>>> the past is to start a timer/counter each time an instruction starts.
>>> If the count exceeds some large number, generate an exception.
>> That is a good idea to include, but I am a little stumped at the moment
>> about implementation.
>
> As a compiler/proglang guy, the one thing that stumps me instead here is "why?".
> Why would you want, or when/where would you need something like an
> "exec" opcode? It seems to me like a "solution" in search of a problem.
>
>
> Stefan
>

An exec is a very cheap special-case function call for very short functions.