Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!lll-lcc!ames!ucbcad!ucbvax!decvax!decwrl!labrea!rocky!rokicki
From: rokicki@rocky.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: 64k tables & Manx? (Summary)
Message-ID: <288@rocky.STANFORD.EDU>
Date: Tue, 5-May-87 10:07:41 EDT
Article-I.D.: rocky.288
Posted: Tue May  5 10:07:41 1987
Date-Received: Thu, 7-May-87 03:16:10 EDT
References: <18567@ucbvax.BERKELEY.EDU> <1799@cbmvax.cbmvax.cbm.UUCP> <18703@ucbvax.BERKELEY.EDU>
Distribution: na
Organization: Stanford University Computer Science Department
Lines: 37
Summary: More Manx bugs

robinson@renoir.Berkeley.EDU (Michael Robinson) writes:
> Note below:  The Manx assembler limits the size of a dcb (Define constant
> block) to 256 bytes, but does not check that the value you specified is 
> equal or less than that.  Consequently, you can specify a block 257 bytes
> long, and the assembler will merrily produce a 256 byte block without 
> informing you that you are not getting what you asked for.  If you specify a
> number large enough, the assembler will crash (guru).  I would guess that 
> this constitutes a bug.

Yep, 3.40a is shore a nice package, but it does have a few minor flaws.

First, the linker does not complain if you get more than 64K of data, it
just wraps it around, if you use the +Q option with the small memory
model.  (+Q puts constant strings in the data segment.)  This one took
me a while to hunt down.  If your program is exhibiting strange behavior,
like some variables apparently not initialized to 0, you might generate
a symbol table dump and check the size of your data segment.

Secondly, addressing a byte array with an unsigned int still does not
work.  For instance, the code:

getme(a,i)
char *a ;
unsigned i ;
{
   return(a[i]) ;
}

Generates:

. . .

move.b	(a0,d1.w),d0

. . .

which interprets i (in d1) as a signed value.