[net.micro.68k] bus error, but why?

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