Path: utzoo!attcan!uunet!mcsun!hp4nl!philapd!ssp11!dolf
From: dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer)
Newsgroups: comp.sys.m68k
Subject: Re: 68000 and 68010 questions
Message-ID: <703@ssp11.idca.tds.philips.nl>
Date: 26 Mar 90 22:18:07 GMT
References: <8215@cs.utexas.edu>
Organization: Philips Information Systems, Apeldoorn, The Netherlands
Lines: 38

In article <8215@cs.utexas.edu> rhwang@cs.utexas.edu (Rwo-Hsi Wang) writes:
> Hope someone can give me the answers.
I will try. I am not so sure of my answer on the first question.
> 
>    1.  In appendix D of M68000 Programmer's Reference Manual (4th edition),
>	there are some descriptions about the basic operations included in
>	the number of clock periods given in the tables.  In section D.3,
> [ stuff deleted ]
Good question, although I do not think you should take care of the different
defintions, as there is an instruction to be fetched, processed, operands
to be fetched, and write back. Whether the fetch time of the next instruction
or the current instruction is given is not important I guess as the
MC68000/MC68010 do not have a pipe-line.

>    2.  (Question about 68010)  According to the (same) manual, it states
>	(in appendix F.2, Operand effective address calculation times) that 
>
>		Several instructions do not need the operand at an effective
>	    address to be fetched and thus require fewer clock periods to
>	    calculate a given effective address than the instructions that
>	    do fetch the effective address operand.

An effective address to be fetched is when it is used as source.
An effective address not to be fetched is an address which is used as
destination. Note that in this table there are no 'no fetch' entries
for PC-relartive and immediate data entries, as these addressing modes
can never be the destination.
Source addressing is always slower as apart from the address calculation
the operand has still to be fetched, requiring extra read cycles.
Destination addressing only requires the address calculation.

>Thanks for your help.
I hope it did ;-)
-- 
Dolf Grunbauer          Tel: +31 55 433233  Internet dolf@idca.tds.philips.nl
Philips Telecommunication and Data Systems  UUCP ....!mcsun!philapd!dolf
Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands         n   n   n
It's a pity my .signature is too small to show you my solution of  a + b = c