libes@nbs-amrf.UUCP (Don Libes) (01/14/85)
I've wrote some C code that generates a bus error in the same spot, consistently. I don't think the C code (at least at the location the bus error is reported) is very important, because the location moves when I add or delete enough statements. Also, its executed several times before it faults. I've tried all the "classical" C debugging techniques (adding printfs, deleting code and watching for the error to go away, etc...) but I'm down to looking at the 68010 assembler (on a Sun). Using stepi (in dbx), I can single-step through the instruction. It always a movl. Here's an example: movl a0(18),d0 When I execute this instruction I get a bus error. What's mystifying is that I can look at the memory pointed to by both operands with the debugger. Additionally, the stack and everything else looks just fine. What else might a movl depend on? The 68010 reference manual says a bus error will leave condition codes set indicating the address in question, but how does one look at the condition codes with dbx? If it helps, the pc ends up two bytes into the movl, after the bus error. I can reset it to the movl instruction and get the bus error an arbitrary number of times. I ran the same piece of code on our VAX (running Eunice) just to see what its debugger (sdb) would say, but it doesn't generate a fault at all! Help! Don Libes {seismo,umcp-cs}!nbs-amrf!libes
libes@nbs-amrf.UUCP (Don Libes) (01/18/85)
Many thanks to the people (rlgvax!jds, oakhill!cruess, vu44!jack) who correctly clued me in that longword stores must be done on even byte addresses on the 68010. The reason that the C compiler generated the errant code was my own fault, although understandable. I was stuffing structures into an outgoing message declared as a character buffer. Sure enough, when I stuffed one in that had an odd length, the next one started on an odd address boundary and my program faulted. My mistake was forgetting about alignment. The reason it didn't occur to me to wonder about alignment (besides the fact that I don't read 68000 manuals when writing C code), is that when I asked the debugger (dbx) to see the longword at an odd address it gave me the bytes straddling the odd address without complaint. That was misleading, although I suppose the author figured he was doing the programmer a favor by not generating a bus error but simulating the long word fetch. Don Libes {seismo,umcp-cs}!nbs-amrf!libes
jec@iuvax.UUCP (01/23/85)
The problem probably is that you are using an assembler for the 68000 and not the 68010. Long words need to be long word aligned when using the 68010 whereas they need only be word aligned on the 68000. -- James Conley Indiana University UNIX-68K Education Board Project ...!iuvax!jec
guy@rlgvax.UUCP (Guy Harris) (01/26/85)
> > The problem probably is that you are using an assembler for the 68000 > and not the 68010. Long words need to be long word aligned when using > the 68010 whereas they need only be word aligned on the 68000. Huh? From p. 47 of the M68000 16/32-Bit Microprocessor Programmer's Reference Manual, fourth edition, which describes the MC68000, MC68008, and MC68010: Address error exceptions occur when the processor attempts to access a word or a long word operand or an instruction at an odd address. Nothing about any restriction more stringent than 16-bit word alignment. (The 68010, like the 68000, is a 16/32 bit chip, not a full 32-bit chip. It does 16-bit fetches/stores, and manipulates non-address data 16 bits at a time.) The 68020 is a 32-bit chip but has no special alignment requirements. If the 010 (or 020) required 32-bit alignment of longword quantities, it would not be compatible with the 000, which would probably not help its sales at all. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
davet@oakhill.UUCP (Dave Trissel) (01/27/85)
In article <3500006@iuvax.UUCP> jec@iuvax.UUCP writes: > >The problem probably is that you are using an assembler for the 68000 >and not the 68010. Long words need to be long word aligned when using >the 68010 whereas they need only be word aligned on the 68000. > > Operand alignment is the exact same for the MC68000, the MC68008 (the 8 bit bus version) and the MC68010. Word and longword operands must reside on a word boundary. There never has been a longword boundary restriction. The new 32-bit MC68020 has no data operand boundary restrictions at all. Motorola Semiconductor Inc. Dave Trissel Austin, Texas {gatech,ctvax,seismo,ihnp4}!ut-sally!oakhill!davet
rpw3@redwood.UUCP (Rob Warnock) (01/27/85)
+--------------- | The problem probably is that you are using an assembler for the 68000 | and not the 68010. Long words need to be long word aligned when using | the 68010 whereas they need only be word aligned on the 68000. | James Conley | ...!iuvax!jec +--------------- Gee... somebody better tell this 68010 here... it's been working fine with word-aligned longs! Think you'd better read the Programmer's Reference Manual again (sorry). Try section 2.4, pages 12-13 of the Fourth Edition. Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
terryl@tekcrl.UUCP () (01/29/85)
>The problem probably is that you are using an assembler for the 68000 >and not the 68010. Long words need to be long word aligned when using >the 68010 whereas they need only be word aligned on the 68000. Wrong, assembler-breath. Long words need only be WORD-ALIGNED on the 68010, not long-word aligned. It's still a 16-bit external data bus, not a 32-bit bus. The 68000 is upwards compatible with the 68010, but not the other way around, software-wise, except for one instruction: the move from status register, which is now a priviledged instruction under the 68010. It wasn't under the 68000. Of course this assumes the code is at the user level; interrupts and exceptions push things on/pop things off the system stack in slightly different ways between the two processors. Terry Laskodi of Tektronix
jec@iuvax.UUCP (01/29/85)
[] Yup, I'm wrong. Sorry about that. I do seem to recall learning that there was some problem concerning long vs. word alignment in a class I took, but I could be wrong entirely. Is there a performance different on either the 68010 or 68020 with regards to alignment (long v. word)? -- James E. Conley Phonetics Research Laboritory Indiana University at Bloomington ...iuvax!jec
jbn@wdl1.UUCP (01/30/85)
Users of Omnibyte VMEbus CPU cardss of serial 3090 and down: Check your board for a Motorola 68432 chip at position U35. If one is present, your CPU card will not function properly if there is more than one bus master. The Motorola bus arbiter chip must be replaced with a two-chip set on a daughter board to make the card work in a multiple bus master configuration. Contact Omnibyte and get the Field Change Order 5 kit. (part number OB68KVME1FCO5, parts kit VME1FCO5K.) This fix cured a serious intermittent problem for us encountered with three bus masters in one VME cage. John Nagle Ford Aerospace and Communications Corp.
cruess@oakhill.UUCP (Michael Cruess) (02/01/85)
In article <3500007@iuvax.UUCP> jec@iuvax.UUCP writes: > > Is there a performance different >on either the 68010 or 68020 with regards to alignment (long v. word)? > On the MC68000 and MC68010, there is no penalty for aligning a long word on a word boundary. It always takes 2 bus cycles to access a long. Words and longs may not be aligned on odd byte boundaries. On the MC68020, there are no alignment restrictions on data, but there may be a performance penalty depending on the alignment and data bus width. The MC68020 can handle memory that is 8, 16, and/or 32 bits wide. If an operand spans more than one addressable "unit" of memory the processor will automatically run the minimum number of cycles to complete the transfer. The number can range from 1 (long aligned long in 32 bit memory) to 4 (any long in 8 bit memory). The most interesting is 3 (odd byte aligned long in 16 bit memory). Michael Cruess {ihnp4,seismo,gatech,ctvax}!ut-sally!oakhill!cruess