Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!whuts!mtune!rutgers!rochester!ritcv!cci632!ccicpg!nick
From: nick@ccicpg.UUCP (Nick Crossley)
Newsgroups: comp.sys.mac
Subject: Re: Code Optimization
Summary: 68000 vs 68020
Keywords: mac,68000,68020
Message-ID: <10000@ccicpg.UUCP>
Date: 26 Jan 88 20:47:59 GMT
References: <6252@cc5.bbn.COM>
Reply-To: nick@ccicpg.UUCP (Nick Crossley)
Organization: CCI CPG, Irvine CA
Lines: 26

In article <6252@cc5.bbn.COM> denbeste@bbn.COM (Steven Den Beste) writes:
>Johan Larson writes:
...
>> The Mac and Amiga worlds are currently in the process of changing from the
>> 68000 processor to the similar, but more powerful 68020.
...
>Now, I may be wrong about this, but the big advantage of the 68020 isn't so
>much new instructions (there are a few, but they aren't commonly used) but the
>fact that it executes the old instructions much faster - because it uses a
>32-bit internal data path and the 68000 uses a 16-bit path, so it takes twice
>as many internal cycles on the 68000 for a given amount of wide data.
>
...
>denbeste@bbn.com(ARPA/CSNET/UUCP)    harvard!bbn.com!denbeste(UUCP)

Another significant difference is that the 68020 has several additional
addressing modes, so that double indirection (ie for handles) and scaled
indexing for arrays, amongst other things, can be done in one instruction.
It also has 32-bit multiply and divide instructions, which the 68000 does
not.  This is significant if your integer size is 32 bits (as in MPW C).
A peephole optimiser could conceivably improve things here, but as Steven
Den Beste says, you would really need assembler input for this, not the
finished linked binary program.

Nick Crossley, CCI CPG.
...!uunet!ccicpg!nick