Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!unixhub!linac!att!cbnewsh!cbnewse!cbnewsd!knudsen
From: knudsen@cbnewsd.att.com (michael.j.knudsen)
Newsgroups: comp.os.os9
Subject: Re: Diffs between OS-9 2.2 / 2.4 ?
Summary: Hardware problem
Message-ID: <1991Jun28.193845.18635@cbnewsd.att.com>
Date: 28 Jun 91 19:38:45 GMT
References: <1991Jun27.140054.13331@unhd.unh.edu>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 57

In article <1991Jun27.140054.13331@unhd.unh.edu>, pss1@kepler.unh.edu (Paul S Secinaro) writes:

>      Recently, we have been having trouble with a piece of software
> which we are evaluating.  When I run the program on our system, which
> is running OS-9/68020 v2.2, I get an error #000:102, which the manual
> states is a "Bus exception error" or something like that (it does not
> go into any more detail than that).  This same binary is known to run
> properly on a system running OS-9 v2.4 on a 68030 module.

Yes, OSK error messages are not known for detail, tho trivial
errors like #216 "File Not Found" give out tons of canned formal
verbiage :-)

> 1.  What exactly does error #000:102 mean?  I know that UNIX, for
> example, will give a "Bus Error - core dumped" message if you try to
> use an improperly initialized pointer or otherwise bang up against the
> limits imposed by the MMU.  Does it mean the same thing in OS-9?  Or

Yes it's the same idea -- in our case, Odd Address Error.
Having just ported a 6809 program to a 68000 clone, I think I can
answer you correctly.

> 3.  Could this program be trying to execute '030 specific code on the
> '020?  Can the Microware C compilers generate '030 specific code?

Your problem is that the code is trying to access a word (long or
short) on an odd byte address.  Since the 68000 chip is 16-bit
shortword hardware, this is a no-no and causes a hardware bus
interrupt and the error you got.

The 68030 (and 020) threw in extra silicon to shift data up or down
a byte as needed, so odd-byte accesses are now legal on those
advanced chips.  They are slower, tho, requiring an extra bus cycle.

So code that runs on an 020 or 030 may break on the 000 thru 012.
Note that the OSK version is not the problem.

I got into trouble by casting char pointers into short or int
pointers.  Since the char pointers can be odd addresses, half the
time that will get you killed!
So check the source for (int *) and (short *) and (long *) applied
to char pointers.  Then rewrite the code (a shame, it may be
inelegant when you get finished).

If you *don't* find the above in the source, then maybe it's a
genuine buggy pointer that only the old 68000 can catch.
Hope you find it...

In my own case, I was casting a char field inside a structure that way.
I re-ordered the fields within the structure to make the byte in
question land on an even boundary.  Fixed the problem.

But the moral is that some forms of pointer type-casting are NOT
portable, even within the Moto family.
-- 
"What America needs is A Thousand Points When Lit..."
	knudsen@ihlpl.att.com