[comp.arch] Instruction timing

hankd@pur-ee.UUCP (Hank Dietz) (11/07/88)

In article <6326@june.cs.washington.edu>, pardo@june.cs.washington.edu (David Keppel) writes:
> bcase@cup.portal.com (Brian bcase Case) writes:
> >[ Amazing: DEC never gave instruction timings ]
> >[ How are you supposed to write a good compiler? ]
> 
> In both defend DEC and support of RISC designers, most CISCs have
> great variability in timing *for a given instruction*.  Some relevent
...[various reasons why timings can be hard to know]....

I agree that instruction times are very hard to know, but you want to be
able to at least make reasonable guesses.  For that matter, it isn't just
CISC machines which suffer unpredictable instruction timing: RISC
instruction sets also have timing variations due to cache, bus traffic,
register window overflow, etc.

My personal preference would be to see the exact formulas for computing
instruction execution time published, however, I'll settle for min/max
bounds or even just expected values (provided the expected times for all
instructions are given based on roughly the same assumptions and that these
assumptions are not particularly unreasonable).

Why don't manufacturers do this?  Because the timings can and do change
dramatically.  For example, the number of T-states in quite a few z80
instructions depended on which company you bought the chip from -- they were
not identical silicon.  This also seems to be true of 68000s.  Especially
for microcoded machines (typically, CISCs), the number of T-states may
differ from source to source or even from production run to run, because
somebody might fix this or tweak that, hence changing the micro-machine but
not changing the instruction set.  Manufacturers like DEC have yet another
reason:  they manufacture full lines of "compatible" machines, but relative
timing of instructions is quite different in the high-end and low-end
machines.  It would be rather nasty, marketing-wise, for them to admit that
you really shouldn't be running the same compiled code on different machines
which they claim are compatible....  It would be nice if they'd take the
more mature view and tell people they can run their object code on all the
compatibles, but supply a document/file with the actual timing formulas
which each machine they ship so that compilers can tailor code to exactly
what you've actually got.

     __         /|
  _ |  |  __   / |  Compiler-oriented
 /  |--| |  | |  |  Architecture
/   |  | |__| |_/   Researcher from
\__ |  | | \  |     Purdue
    \    |  \  \
         \      \   hankd@ee.ecn.purdue.edu