Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!nosc!crash!pnet01!lkoop
From: lkoop@pnet01.cts.com (Lamonte Koop)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: What the #&%@?
Message-ID: <7827@crash.cts.com>
Date: 6 Mar 91 08:36:01 GMT
Sender: root@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 65

lkoop@pnet01.cts.com (Lamonte Koop) writes:
>
>I have come face to face with a rather perplexing problem involving a project
>I am currently working on, to which I cannot find the answer.  I'm hoping


Well, I found it...

>SOMEONE [read: ANYONE! please!] may have an idea as to what is going on. 
>Anyway, the problem goes like this:  The application I have set up uses a
>fairly standard Intuition interface setup...with the appropriate message
>handling loops and such.  The problem arises when the code I compile is
>executed on a stock 68000-based system (I am currently developing on a
>68030-accelerated system).  The event handling loops run perfectly normal when
>run on the 68030 (or a 68020 for that matter)...unfortunately, things begin to
>flake out when the program is run in the machine's 68000 mode...or any
>68000-based system.  The symptoms are thus:  at VERY random times, selecting a
>menu item will result in an Address error guru.  Now, most of the menu
                             ^^^^^^^^^^^^^
          tip off right here-------|

>selections simply result in a function call or so.  The odd part is that there
>is NO way to predict which menu function will guru...or WHEN...It just
>happens.  This does not happen AT ALL when the program is run under an 020 or
>030 system. [No...the compiler is NOT set to compile for 020/030 specific code
>generation].  The layout of the event loop skeleton is somewhat like this:
>
>while(keepgoing) {
>   Wait(1L << BenchWindow->UserPort->mp_SigBit);
>   while((msg = (struct IntuiMessage *)GetMsg(BenchWindow->UserPort))) {
>     code = msg->Code;  class = msg->Class;
>     gad = ((struct Gadget *)msg->IAddress)->GadgetID;

Ok, the above line is the problem.  I thought I would post this just as a
follow-up and warning for anyone who might accidentally do something this
dumb.  Ok, the assignment to the variable 'gad' above is compiled to the
following machine code:

       206B 001C         MOVEA.L   001C(A3),A0
       3B68 0026 FFEA    MOVE.W    0026(A0),FFEA(A5)

Now, the reason this SOMETIMES crashes, and only on a 68000/68010 came to me
after a rather lengthy fit about the whole mess.  The 'gad' assignment is made
regardless of whether or not the IntuiMessage is a 'gadget' type of message.
I just assumed (wrongly) that if it wasn't a gadget message, then it wouldn't
matter what was assigned to gad...but I wasn't thinking of HOW it was
assigned.  Every now and then, it's possible that dereferencing the
msg->IAddress pointer the way I was would result in an ODD address.  Now, the
68020, 030, etc don't require DATA to be word aligned, (they just incur a
performance hit for accessing such misaligned data)...so such references in
the context given above (the disassembled code) had no ill effects on my
system when I was in my normal state (running on the 030).  However, the 68000
DOES require word alignment of such data accesses, and thus on the occasions
when A0 ended up ODD from my bizarre reference to msg->IAddress, an Address
Error guru would occur. (i.e: BOOM).  Note that this condition would only
occur when the message was not a gadget message...and in such cases the
occurance was still fairly "random" in nature (it would'nt ALWAYS end up odd)
 
The moral of the story:  Don't make stupid assumptions :-).


                             LaMonte Koop
 Internet: lkoop@pnet01.cts.com         ARPA: crash!pnet01!lkoop@nosc.mil
           UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop
 "It's a dog-eat-dog world...and I'm wearing Milk Bone underwear"--Norm