Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!daver!dlb!netcom!mcmahan
From: mcmahan@netcom.UUCP (Dave Mc Mahan)
Newsgroups: comp.sys.m68k
Subject: Re: cast (char *) to (int *) ?
Keywords: 68000 C
Message-ID: <11624@netcom.UUCP>
Date: 8 Aug 90 07:33:35 GMT
References: <1990Aug7.183302.26585@cbnewsl.att.com>
Organization: Dave McMahan @ NetCom Services
Lines: 80


 In a previous article, rl@cbnewsl.att.com (roger.h.levy) writes:
>We have a substantial amount of C code originally targeted to a 68008
>system and now being ported to a 68000 system.  In the past, we have
>casted character pointers to integer pointers in some situations and
>then dereferenced the pointer.  Although this works OK with a 68008,
>it will result in a bus error on our 68000 target if the address of
>the data is odd.  Since we need to correct our code, I was wondering
>whether a tool exists that can identify instances of such statements.
>BTW, I checked my K&R and noted the warning about possible addressing
>errors as a result of this practice.  We realize the error of our
>ways so no further scolding is necessary.

There are a couple of ways to get around this.  The first is tedious and
consumes lots of memory (2 bytes for every character declared) but is good
to do in the long run to solve portability problems.

Go through each function and change all the explicit declarations to
typedef's.  Thus, you would do something like:

typedef		char	CHAR;
typedef		int	INT;
typedef		unsigned int	UINT;
typedef		unsigned long	ULONG;

Make sure you also do this in the casts.  This allows you to set the size
of each variable type on your machine.  For your case, you would compile the
whole mess with the stuff above to make sure it still provides the same type
of output, and then go in and change all the CHAR typedefs to:

typedef		int	CHAR;

This will make all your character arrays at least 16 bits wide and force them
all to even boundaries.  Note that this may get a little hairy when you try
to access hardware explicitly.

The other way to get rid of this problem is to check out your compiler to see
if it has a way to force all your odd addressed variables to even addresses.
This might be as a switch to go from the 68008 to the 68000 or a -EVEN switch
that causes all variable bases to begin on even addresses.  I don't know what
compiler you have, so I guess you are on your own.

I think the second method probably won't work too well in your case.  It
appears that you have been doing nasty-NoNo things like setting integer
pointers into the middle of character strings (like trying to parse stuff
as it comes in a comm port and bytes 3 and 4 contain an integer value).  The
compiler likes this stuff as much as any other and it is not technically a
syntax error, so I doubt you will find a tool (like lint) that would catch
such a thing.  It would be very difficult and a smart tool indeed, since you
could concievably set a byte pointer to an even address (which is ok),
increment it twice and use it as an int pointer (which is ok), then increment
it 5 times and use it as an int pointer (which is not ok).  How can a tool
figure out such a mess?  It would have to go through all permutations to
find what you mean.

Another alternative comes to mind.  You can trap the exception vector that
occurs from this type of addressing, decode the instruction via a software
exception handler, and do 'the right thing'.  This might work theoretically,
but good luck making it go in the real world!  I assume you are getting an
address error exception.  That would be the place to install such a handler,
but you would have to write an instruction decoder that would look at the
stack, figure out where the bad instruction was, decode that instruction to
figure out if it was the first operand, the second operand, or both that
caused the problem, fix it, do the instruction, change the stack a bit to
return to the instruction after the one that caused the problem, and then
do an RTE (return from exception) instruction.  Pretty nasty.  I think your
problems might be solved if you went to the 68020 processor that detects this
mis-alignment in the chip and does the right thing, but that to has obvious
problems and costs.

The first brute-force method of typedef'ing everything might work, but then
you might have to tweak all the code so that it still runs properly.  The
best thing to do is the most tedious.  Go through each exception by hand,
figure out what line of source caused the problem, and then change it.  No
fun, but I think you are kind of on your own for this one.  Good luck.

>Roger Levy
>...!rl@groucho.ATT.COM

   -dave