🚀 go-pugleaf

In article <8804100045.AA12398@jade.berkeley.edu> SLMYQ@USU.BITNET writes:
>I see.  However, what I *really* want is just to have all data of the same type
>put into big data hunks - that will make the object size smaller, won't it?

OK, POOF, you've got it.  BLINK already does that.  BLINK merges all hunks
that have the same type and the same name.  If you don't go to extra effort,
Lattice always names the hunks it produces __MERGED, meaning they will always
be merged.

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.
However, I don't think this is really a problem - why do you care if BLINK
merges your data hunks?

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.