Seni (seniike.delete@this.hotmail.com) on April 12, 2017 12:47 pm wrote:
> RichardC (tich.delete@this.pobox.com) on April 12, 2017 11:06 am wrote:
> > Seni (seniike.delete@this.hotmail.com) on April 11, 2017 10:27 pm wrote:
> >
> > > Single-cycle instructions do not need this sequencer at all. It's a huge distinction.
> > >
> > > When anon asks "Is there a hard line between microcode and non-microcode?" The answer is yes.
> > > This right here is the line. Single-cycle instructions with no sequencer are absolutely not microcode.
> >
> > A mathematician would say it's the trivial case of microcode :-)
>
> I don't know if you realize how frustrating this. I'm trying to make this as clear and obvious as possible,
> and yet several of you are completely missing the point, and can't see the forest for the trees when I am
> pointing at it and repeating "This is a forest. These trees are a forest." Maybe it can't be taught?
>
> Single cycle is not just a minimal version of multi-cycle. It is qualitatively different. Not only
> do you not need the ROM/PLA. You don't need the cycle counter, or even the instruction register.
>
> I repeat, with emphasis:
>
> Single-cycle instructions WITH NO SEQUENCER are absolutely not microcode.
>
> NO SEQUENCER.
> Single cycle means it's possible to have NO SEQUENCER.
>
> Have I repeated it enough yet? Do you get it now?


I'll not repeat some of the other comments, but yes, a scalar implementation with only single cycle instructions will likely place very low demands on the functionality of the sequencer.

I'll also point out that the term microcode often gets used rather sloppily. IBM used to be a prime offender here, often called any coded internal to a system "microcode" (until they started calling it "licensed internal code", so they could license it separately from the hardware). And then you had the interminable arguments by people wanting to call Alpha PALcode microcode.

But I do want to point out that having only single cycle instructions does not require the absence of a sequencer, as many things still need to happen in sequence to do things like fetch the next instruction word. It might be a very simple sequencer, but it's very often still there. IOW, you'll have some sort of state machine to wiggle the pins in the right order so that you can fetch the next instruction. OTOH, multi-cycle instructions don't require the presence of a traditional sequencer (in whatever form) either. Consider a data-flow-like internal architecture that can forward a partially completed load-op instruction from the LSU to the ALU via the forwarding network. They way asynchronous processors work is similar as well.

But, I suspect I've lost some context in this thread: why is the presence/absence of a traditional style sequencer, however implemented, interesting?