[vox-tech] what is a bus error

Jeff Newmiller vox-tech@lists.lugod.org
Mon, 7 Jan 2002 21:15:41 -0800 (PST)


On Mon, 7 Jan 2002, Rod Roark wrote:

> Drivers don't access buses directly, but rather by reading from 
> and writing to I/O or memory addresses, or by fielding interrupts.

This is not entirely helpful.  It's like saying you don't access a bus
directly when you commute to campus because you only pay attention to
which stops you are interested in.  True, you don't ordinarily care
whether the bus is a Gillig or a London double-decker, but if the
double-decker requires a special approach to the door then you might want
to pay attention in case you ever have to ride the double-decker.

> So I think any "bus error" message is going to be hardware-specific.

Yes.  The classic "bus error" derives from attempts to access multiple
addresses across the bus width boundary.

Computer Engineering 101:

Memory (and I/O space) is addressable in some minimum units (typically
bytes for modern architectures... I will assume bytes below).  However, to
speed things up, the actual data path is often several units wide... a
32-bit bus is four bytes wide.  A memory location must thus be addressed
by groups of addressable units, as well as by which of the paralleled
units is of interest. Attempt to make a parallel access to data that
are not located in parallel is where a bus error would be raised.

For example, in a 32-bit processor with a 32-bit data bus, the high 30
bits of the address define which set of four bytes, and the bottom two
bits define which byte within the bus is of interest. (Actually, these two
bits are represented with four separate hardware lines so that 1, 2, 3 or
all 4 of the bytes can be activated independently).  To access a pair of
bytes beginning with address 00000003 and ending with address 00000004
requires first an access to the group of four bytes beginning at 00000000
and ending at 00000003, discarding the bytes from 0000000 through
00000002, followed by an access to the group of four bytes beginning at
00000004 and ending at 00000007, discarding bytes from 00000005 through
00000007, and munging the two resulting bytes together into a single
two-byte value.

For backward compatibility, the x86 architecture has been designed to
automate this kind of inefficient silliness, but other processor designers
have elected to emphasize to the programmer that this is inefficient and
avoidable (not to mention a pain in the butt to implement in hardware) by
generating a software interrupt, known as a bus error.  It is usually
avoidable by not laying out your software to look for data in such places.  
In the unusual cases where the organization is not avoidable (such as
communications packet structures), the data can be accessed by separate
instructions.

If you have ever wondered why sizeof(struct whatever) is often not equal
to the sum of the sizes of its elements... perhaps you can figure out why,
now.

> However a "buss error" would pertain to "software".  ;-)

That particular interrupt would probably be handled with a "slap"! :)

> 
> -- Rod
>    http://www.sunsetsystems.com/
> 
> On Monday 07 January 2002 16:18, Peter Jay Salzman wrote:
> > i did a google search, and found alot of conflicting answers.  some of
> > them seemed to indicate that the precise definition of bus error is
> > architecture dependent, but i find that hard to believe.

Doubting Peter.  The precise definition _is_ architecture dependent,
though the working definition given above is probably enough to help you
out when you encounter one.

> >
> > i know what a segmentation violation is.
> >
> > but what exactly is a bus error?
> >
> > can anyone write a hello world type program that demonstrates barfing
> > from a bus error?  i found some code that purported to produce a bus
> > error on a sparc, but it didn't barf under linux.

That is, it didn't barf on the x86 architecture.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------