hawk@pnet01.cts.com (John Anderson) (03/09/90)
Thank you to all those that responded to my inquiries and questions about 32 bit RAM and 16 bit etc. So basically what I understand to be true is that 32 bit is 4 bytes wide (which I already knew) so it can hold *4* instructions instead of just *2* like 16 bit RAM? (that is the part I didn't know about). 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? Also, I got that each instruction is one byte not 4 bytes long but since the data length is a maximum of 32 bits then this leaves and option to have a number stored in 32 bits (taking up 4 bytes) if it is needed to be that big(or that accurate). Is this also true? If this is also true then I appreciate all the help I got from those that replied and helped me. If only some is tru then I still thank you and could you shed some light on me on the stuff I still dont understand? Even if I'm right could someone in the know let me know that I got it? Thanks again...
hue@netcom.UUCP (Jonathan Hue) (03/09/90)
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. -Jonathan
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (03/09/90)
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). Hmm I think this is not quite correct. The instruction word is always one 16-bit word. If necessary there are extra extension words, e.g. to hold some immediate data or address etc. For example: JSR (a0) will translate to: 4E90 JSR 0x12345678 will translate to: 4EB9 1234 5678 The longest possible instruction on a MC68000/MC68008/MC68010/MC68070 is: MOVE.L #0x12345678,0x9ABCDEF0 which translates to: 23FC 1234 5678 9ABC DEF0 The longest possible instruction on a MC68020/MC68030/MC68040 is: MOVE.L ([0x11111111,A0,D0.L*8],0x22222222), ([0x33333333,A1,D1.L*8],0x44444444) which translates to: 21B1 0F23 1111 1111 2222 2222 1F23 3333 3333 4444 4444 Note that the very short: MOVE.L A0,D0 just translates to: 2010 When a co-processor is involved (e.g. MC68881/MC68882), the actual instruction length depends on the co-processor, but is limited to 256 (extionsion) bytes, giving a total of 129 words. The instruction word indicates that the instruction is actually for the co-processor, the next word is the co-processor instruction and then there may be at most 254 extension bytes for the co-pro. The actual limit for a MC68881 is I think 8 words: FMOVE.X #0x123456789ABCDEF012345678,FP0 which translates to: F23E 4800 1234 5678 9ABC DEF0 1234 5678 Disclaimer: I hope the hexnumbers of the assembler translations are correct, I did not do a compiler check, but tried to reproduce the MC68030 and MC68881 User's Manual. -- Dolf Grunbauer Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl Philips Telecommunication and Data Systems UUCP ....!mcvax!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
coburn@clo.enet.dec.com (John T. Coburn) (03/09/90)
In article <1778@crash.cts.com>, hawk@pnet01.cts.com (John Anderson) writes...
:
: Thank you to all those that responded to my inquiries and questions about
:32 bit RAM and 16 bit etc. So basically what I understand to be true is that
:32 bit is 4 bytes wide (which I already knew) so it can hold *4* instructions
:instead of just *2* like 16 bit RAM? (that is the part I didn't know about).
: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?
:
Not exactly (although we may just have semantics problems here). The difference
between 32 bit RAM and 16 bit RAM is that the bus used to access the memory is
twice as wide (32 vs 16 bits). This allows twice as much data to be moved from
memory to processor in the same amount of time (ie. memory access).
This has no effect on the 680x0 instruction size or how much memory (number of
bits) is used for a particular program.
The reason that 32bit RAM isn't used on the 68000 is that it only supports the
16 bit databus and the 68030 supports the 32bit databus (ie. has more pins to
access more databits in one access).
Hope this helps a little bit.
:
: Also, I got that each instruction is one byte not 4 bytes long but since
:the data length is a maximum of 32 bits then this leaves and option to have a
:number stored in 32 bits (taking up 4 bytes) if it is needed to be that big(or
:that accurate). Is this also true? If this is also true then I appreciate
Even with 16bit RAM you could have 32 bit numbers stored and used by the
processor - it would take 2 memory accesses to retrieve the entire number to
the processor.
:all the help I got from those that replied and helped me. If only some is tru
:then I still thank you and could you shed some light on me on the stuff I
:still dont understand? Even if I'm right could someone in the know let me
:know that I got it? Thanks again...
--------------------------------------------------------------------------------
John Coburn !Email:
Digital Equipment Corporation ! coburn%clovax.enet.dec@decwrl.dec.com
Enterprise Integration Services !
Cleveland, Ohio ! ...!decwrl!clovax.enet.dec.com!coburn
================================================================================
swarren@convex.com (Steve Warren) (03/13/90)
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
news@chaph.usc.edu (USENET News) (03/24/90)
From: phlin@phakt.usc.edu ( - TOP SECRET -) Path: phakt.usc.edu!phlin Replies: phlin@aludra.usc.edu :-) :-( :-O :-| 8^) 8^D 8^P *8^O *B^D