Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!purdue!gatech!uflorida!codas!usfvax2!jc3b21!fgd3
From: fgd3@jc3b21.UUCP (Fabbian G. Dufoe)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Possible BLINK bug????
Message-ID: <366@jc3b21.UUCP>
Date: 14 Apr 88 05:53:06 GMT
References: <8804060603.AA13042@jade.berkeley.edu> <364@jc3b21.UUCP> <452@sas.UUCP>
Organization: St. Petersburg Jr. College, FL
Lines: 62
Summary: Command line option solves the problem

In article <452@sas.UUCP>, walker@sas.UUCP (Doug Walker) writes:
> In article <364@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes:
> >In article <8804060603.AA13042@jade.berkeley.edu>, SLMYQ@USU.BITNET writes:
> >     I've had a problem with Lattice 4.0 that might be related to this.
> >Nothing I do will prevent the compiler from naming data sections "_MERGED".
> >That's a special name that causes Blink to merge all data hunks with that
> >name.  It doesn't even matter if you are using SMALLDATA with Blink.  
> 
> You can use the -s option in Lattice 4.0 to choose your own name for each
> data hunk.  BLINK merges all like-named hunks, not just __MERGED hunks.

     I contacted Lattice about the problem.  The answer is that the -b
option is now the default.  To switch off the -b option you use -b0.  The
manual describes the -b0 option for lc1 but not for lc.  However, the
option works with lc as well as lc1.  Hence the problem turned out to be
one with documentation rather than the compiler.

     Note that the -s option will not work unless you also specify -b0.
Apparently the -b default overrides the -s option.  (I haven't checked, but
I assume the -s option still works for code segments.  I only tried it for
data and bss segments.)

> However, I don't think this is really a problem - why do you care if BLINK
> merges your data hunks?

     If BLINK merges your data hunks your program may not load into badly
fragmented memory.  You might want to be sure AmigaDOS can scatter-load
your program into the smallest possible contiguous memory spaces.  In that
case you don't want data hunks merged.  Basically, you want control over
what the compiler and linker do for you.

> Note that if you use the -b option to get 16-bit data addressing,
> your data hunks MUST be merged for the reasons I listed before - the data
> must be in the same 64K chunk of memory.  This means that if you use -b and
> have any data compiled to CHIP memory, ALL your data must go to CHIP memory.

     This isn't exactly right.  Let me quote from the Lattice 4.0 manual,
page 5-11:

     It is possible to mix modules compiled with and without the -b flag.
     As long as modules compiled with the -b flag do not reference any data
     in modules compiled without the -b flag, no special linking procedures
     are necessary.  Otherwise, it is necessary to use the smalldata option
     of the linker to cause all data to be combined.

You can use the -b option for all data except that which goes to chip
memory.  Then use the -a option (for lc--equivalent to the -c option for
lc2) for data that must go to chip memory.  The linker will merge the hunks
compiled with the -b option but not those compiled with the -a option.
Assuming you didn't reference data in the -a option modules from the -b
option modules the program will work.

     I was very pleased with the promptness with which the people at
Lattice solved my problem.  I've had occasion to contact them several times
and have been very satisfied with the quality of their support and their
products.  

--Fabbian Dufoe
  350 Ling-A-Mor Terrace South
  St. Petersburg, Florida  33705
  813-823-2350

UUCP: ...gatech!codas!usfvax2!jc3b21!fgd3