🚀 go-pugleaf

In article <dak.721621337@messua> dak@messua.informatik.rwth-aachen.de
(David Kastrup) writes:

>See the MIPS processors (micro without interlocking pipeline stages) for
>a clever design idea: they have simply left out all instruction scheduling.
>If you start a command using a register which a previous command still has
>to fill up, there is no delay, but the OLD value is used.
>So the compiler/assembler will have to include nops by hand in order to
>prevent register clashes. On the other hand, command interlocking can be
>done by compilers. And you can use the die space thus gained for other
>purposes (bigger cashes, etc.). And because of the Harvard bus architecture,
>there is no difference between waiting for interlock or fetching a nop.
>Only problem: code tends to get longer.

Second problem: if a second implementation has different "natural" delays
for instructions to produce their results, then something is going to break.
Within limits, you can choose what it is - e.g. any of the following will
do:

  * The second implementation has to reintroduce the instruction scheduling
    hardware. It probably doesn't have to reintroduce *all* of it - e.g. if
    your original implementation had one load delay slot and your new one
    has two, you only have to protect one of them. But simply having
    instruction scheduling hardware at all is a large fraction of the
    complexity involved, so this may not save as much as you might have
    thought.

  * All code has to be recompiled for the new hardware. Unfortunately, not
    all vendors give you the sources...

  * You impose a rule on yourself that you simply won't use implementations
    that change the natural delays. Of course, this may well give
    less-than-optimal results in a few years' time.

Personally, I see this technique and others that expose implementation
details to the programmer as being rather short-sighted. They buy you a nice
short-term gain, at the cost of long-term problems. (Of course, if you're a
small company trying to get your architecture off the ground, you may *need*
the short term gains: if you don't get them, there won't *be* any long term
to worry about...)

David Seal
dseal@armltd.co.uk

All opinions are mine only...