🚀 go-pugleaf

In article <8720@netcom.UUCP> hue@netcom.UUCP (Jonathan Hue) writes:
>In article <1778@crash.cts.com> hawk@pnet01.cts.com (John Anderson) writes:
>>I thought each instruction was 32 bits in length and needed to be stored at
>>two 16 bit addresses so when it was used in 32 bit RAM it took up 32 bits for
>>that same one instruction. Am I right so far in saying the first is right and
>>the second (what I used to think) is wrong?  

>They're both wrong.  68k instructions can be 1, 2, or 3 16-bit words long,
>although I'm pretty sure that only the 68020 and 68030 support the 3
>word long ones (CAS2 and LINK (long) come to mind).

>Some 68k instructions (mostly integer arithmetic) can use byte, word,
>and long word operands.

Exactly, and probably the most important concept for Mr. Anderson at this
point is the fact that all instructions and data will be stored at
#exactly#the#same#address# no matter what size the data bus is.

The instruction/data can be arranged "linearly" as a sequence of bytes
(the instructions would have to be cut in half or even more pieces to
get them into individual byte-size pieces).  Each byte has its own
address in the 68000 family, so an address corresponds to each byte
in this ordered stream of bytes.  If you take out of this stream
16-bits at a time you effectively have a 16-bit system.  If you
take out of this stream 32-bits at a time then you have a 32-bit system.

But the relative positions of the data has not changed, and no "empty"
bytes are introduced.  All the byte addresses are unchanged.

I think you were essentially right in saying that the instructions didn't
need to get "longer" to fill out the 32-bit space, like you used to think.
However, it is more complicated than just having them be one byte long.
There are various sizes of instructions and data, and the architecture
is designed to differentiate between them all automatically.  These
sizes are constant across the various incarnations from 32-bit '040,'030,
& '020s, to the 16-bit 010 & 000s, and the 8-bit 008.

--
--Steve
-------------------------------------------------------------------------
	  {uunet,sun}!convex!swarren; swarren@convex.COM