Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!WATDCS.BITNET!DMIHOCKA
From: DMIHOCKA@WATDCS.BITNET (D Mihocka)
Newsgroups: comp.sys.atari.st
Subject: (none)
Message-ID: <8803290445.AA17142@ucbvax.berkeley.edu>
Date: 29 Mar 88 04:39:27 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 33

Laser C users beware: I've come across a code-generation bug in the inline
assembler. If you have code similar to this:

foo:
    dc.b    0x00, 0x01, 0x00, 0x80, 0x00, 0xFF

it actually generates the following 6 bytes:

    0x00, 0x01, 0xFF, 0x80, 0xFF, 0xFF

i.e. value in the range $80 - $FF get sign extened into the previous
byte. This will totally screw up any lookup table you may have. I've
notified Megamax of the problem, and they say it's too late to fix it for
the next update, but they'll investigate the problem.

In a similar situation, if you have this code:

label1:
    dc.b    0
label2:
    dc.b    0
label3:
    dc.w    0

it will actually generate 6 bytes, not 4, and PC relative references to
the labels will generate an address that is off by 2 from the address
generated using long addressing. i.e. don't mix PC relative and absolute
addressing when accessing dc.b constants.

Megamax suggests that to word around the problem, use dc.w and combine the
bytes. For now, that's about all we can do until they fix the bug.

- Darek