Conference hydra::amiga_v1

    I don't have my 4.0 manual handy, but this looks like BLINK is trying
    to use the "shorter" mode of displacement by default.  Look at your
    Lattice manual and read about the different kinds of relocatable
    address modes...switching to another mode may help (but will give
    you larger executable code size).

    The error could well be legitimate, and if it is, ALINK won't help
    you.  When generating PC or base register relative code, compilers
    and assemblers can generate 16 bit external references to other
    entry points or data.  It isn't until link time that any check can
    be made to see if the item in question is close enough to the source
    instruction to resolve the request.
    
    If you're dealing with a large program, or if the request is to
    an object in a different section than the fixup location, you're
    going to get that error.  What it's trying to tell you is that the
    distance between the symbol's value and whatever base you're using
    (probably the PC of the fixup) is too big to fit in a signed 16
    bit value.
    
    If you're trying to make an external reference to something in another
    code section than where you're making the reference from, give BLINK
    whatever magic option it wants to force all sections to be in the
    same load hunk.
    
    Otherwise, if the program's just big, either rearrange the load
    order so that the reference is closer to the target, or use a different
    compiler option that will use whatever they like to call the large
    code model.
    
    Third option:  (this one's the tough one)  Get a 68020 that can
    do 32 bit PC relative addressing, then hack or get a compiler that
    knows how to use it.

    
    
    	Does your program have a large routine ?  It is documented
    that routines in lattice must fit in 64KB of space. If this is the
    case you have to break it up. 
    
    		Steve Peters
    

Re: .0

Lattice V4.0, unlike earlier versions, defaults to generating code
for the small code/small data model.  As the earlier replies have
pointed out, it seems like your code or data is too large to allow
this.

Try recompiling your program using the following switches to LC:

	-b0	Don't use base relative addressing for data
	-r0	Don't use PC relative addressing for function calls

Depending on which part of your program is "big," you may only need
one of the switches.

Unfortunately, Lattice doesn't describe these switches under the LC
command (instead they are described under LC1 and LC2).  This bit me
when I upgraded to V4.0 from V3.4.  I have an application that can not
use small code and data, and Lattice's changing of the default of
the switches caused me to spend about four hours debugging!

Thanks all for the replies. Randy, what you said is probably what is happening
to me. I just looked in the manual at the -b LC option and -b LC1 option
which do not agree. -b under the LC command (which I saw, but from the doc
didn't seem to want) says that it will cause the compiler to use base-relative
addressing, but that the default is 32-bit absolute addressing. But, under LC1
they state that the default is now base-relative, and to use -b0 for absolute!
Arrrggghhh! Anyway, I'll give this a try tonight and let all know if it worked.
However, since this particular module is not that large, I still don't know
why I would have gotten this error using base-relative addressing.

Randy, do you also have the Lattice V4.0 utilities, like LSE and diff? Both
of these do not work (for me anyway, gee, maybe I'm jixed). LSE echos an
inverse video capital A for every character I type! If I type hello, LSE
ehoes HAEALALAOA where all the A's are in inverse video. Not terribly
useful. Also, no matter what files I try to diff, even files I know are
the same, diff displays a "Line Table Overflow" error. Gesh, for all the
bucks I chucked out for this stuff, I shure expected alot more. Maybe I
should have got Manx instead :-).

Frank

Re: .5

I got the Lattice text management utilities when I bought V3.10 of Lattice
C.  I didn't get any update to them when I got V4.0, but I seem to remember
that the Lattice newsletter indicates that the text utilities haven't been
updated in awhile.  Thus, I assume that you and I have the same version.

Anyway, the Lattice Diff command uses an algorithm that uses a table that
has an entry for each line in the files being compared.  The diff program
doesn't support dynamically growing the table if it overflows, so instead
there is a command line switch to set the table size.  If you use the
-lnnnn qualifier when nnnn represents a decimal number of lines, you
can compare files of any number of lines.  By default, diff only has a
table that allows it to handle files of 1000 lines each.  The text
utilities manual describes the switches for diff.

By the way, if you don't know the number of lines in the file, the Lattice
wc utility will count them for you.

I don't know anything about LSE; I've never used it.

I have found two bugs in the text utilities.  First, grep sends its output
to standard error, not standard output.  Thus you can not redirect its
output.  Second, if you use diff with the -w switch (ignore differences
between tabs an spaces and ignore trailing spaces on a line), diff
will complain that a line of all blanks is different from a line
that contains no text.  However, it does do the right thing if there is
at least one one non-space character on either line.

Randy, thanks for the info. I was finally able to get my module to
build/link last night using the -b0 and -r0 options. I did have
one final error and that is that I was defining IntuitionBase in
the module, and further on in the differences between LC4.0 and previous
versions sections of the doc, it states that the library base vectors
are now defined in the library so you should extern them in your program.

Well, my first experience with C development on the Amiga was a snap :-).

Frank