🚀 go-pugleaf

>>I predict that before too long all high performance commodity micros will do
>>scheduling at runtime.

>I don't think the situation is as clear-cut as you describe it.

>There are certain scheduling techniques that tend to work well no
>matter where you use them -- as long as you have enough registers, it
>doesn't hurt to stick a few instructions between a load into a
>register and the subsequent use of that register.  On superscalar
>machines, it is generally a bad idea to do too many of exactly the
>same thing in a big lump (i.e., ld, ld, ld or fadd, fadd, fadd), and
>if you have the option of mixing things up a bit, you should.
>Increasing the size of basic blocks (through code replication,
>typically) is another trick for helping most machines, since branches
>often stall pipelines.

>These are general rules, and they won't yield optimum performance, but
>you must trade them off against the costs of generating
>implementation-specific code.  Those costs include

>  (1) less sharing of text and libraries
>  (2) lots of cache flushing and
>  (3) scheduling and register allocation are not necessarily cheap.

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.