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:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --------------------------------------------------------------------------- _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
