Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga.tech
Subject: Re: lattice/MANX bug when compiling large programs
Message-ID: <6439@batcomputer.tn.cornell.edu>
Date: 2 Oct 88 17:18:34 GMT
References: <12499@oberon.USC.EDU>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 26

In article <12499@oberon.USC.EDU> papa@pollux.usc.edu (Marco Papa) writes:
>Lattice 4.00 compiles the program OK, but then dies right away in Blink.
>Blink returns "error 502: Distance for reloc16 > 32768" with symbol __xcovf or
>something like that.  I am just using the "default" library lc which should
>be able to address the entire memory.

I don't work for Lattice, SAS or the Software Distillery, but I will offer
some advice.

The default for the both the compiler AND THE LIBRARIES is base-relative
addressing.  For a program with a lot of data, you should be compiling 
with the -b0 flag to lc (or lc1) to disable base-relative addressing.  You
probably should not be using the blink "SMALLDATA" option.  If you still
have the problem, you should use the library lcnb in the lib directory on
disk 4, which is compiled without base-relative addressing (this is 
documented in the readme file on disk 1--disk 4 was added after the manual 
was printed).

If you don't expect this program to take up much stack, you could also
'finesse' the problem by using the -v flag to lc (or lc2).  This disables
the stack checking code at each function entry point.   (__xcovf is
defined by the stack overflow handler, so it's referenced by every
module in your program.)  However, this is often not a good idea...

-dan riley (dsr@lns61.tn.cornell.edu, dsr@crnlns.bitnet)
-wilson lab, cornell u.