Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!vax5.cit.cornell.edu!tcd
From: tcd@vax5.cit.cornell.edu
Newsgroups: comp.sys.mac.programmer
Subject: m68k timing tables & Mac
Message-ID: <1991Apr29.123112.4331@vax5.cit.cornell.edu>
Date: 29 Apr 91 12:31:12 EDT
Distribution: comp
Organization: CIT, Cornell University
Lines: 28

I'm trying to do some assembly language programming on a Mac and was 
wondering how to interpret the timing tables in e.g., the MC68020 User's
Guide relative to a Mac.  I'm not trying to get real precise, but just 
to develope some general guidelines, for a Mac II, IIcx, IIci in particular.
For example, which is likely to be faster?
     MULS.W  D1,D0          or       MOVE.L   (A0,D1.W),D0
Under the "No wait state memory (3 cycle read/write)" assumption for the
MC68020 timing tables, the MOVE.L would clearly be faster.  But, what are
the correct memory access assumptions for the Mac II family, and how do
these effect the timing tables?  From the Motorola manual, it looks like
I could take the total clocks for an instruction and subtract 3 times the
number of bus cycles given to get the number of internal clocks.  Then, if
I knew the number of clocks per read/write on the Mac, I could multiply
that by the number of bus cycles and add it back to the internal clocks to
get the total clocks for the Mac.  Somehow, I know it can't be that simple.
(if it is that simple, what are the appropriate clocks per read/write for
the various member of the Mac II family?).
     At the moment, I'm trying to figure out whether it makes sense to 
compute certain numbers on the fly, based on values already in registers,
or whether I should compute the set of numbers ahead of time and read them
from memory as I need them.  My current guess is that if it takes a 
multiply to get the number, then I'm better off putting it in a table; if
it takes a couple (register) moves and a shift or add then I should compute
it on the fly.  Anybody have any advice or recommendations on these matters?
Clearly, I'm a novice so please don't be too technical.
Thanks,
Tim Dorcey
tcd@cornella.cit.cornell.edu