SLMYQ@USU.BITNET (04/06/88)
Here's another one. I'm not really sure if this is a bug, but it sure is
annoying.
When you use SMALLDATA and have a few data chunks that are supposed to go into
chip memory and a few that don't need to, it just sticks them both together
into one big chunk that must go into chip memory. I really don't want to
have 50K of stuff in chip memory which really doesn't need to be there. And
I really want to use SMALLDATA. The same thing goes with code hunks. Also,
although there is no SMALLBSS switch, Blink always coagulates all of the BSS
hunks into one, with the problems I noted above.
Great!
I'd call up the Distilleries and tell 'em about it, but I can't get through!
Too bad. Maybe next version...
Bryan Ford (SLMYQ@USU.BITNET)walker@sas.UUCP (Doug Walker) (04/08/88)
In article <8804060603.AA13042@jade.berkeley.edu> SLMYQ@USU.BITNET writes: >When you use SMALLDATA and have a few data chunks that are supposed to go into >chip memory and a few that don't need to, it just sticks them both together >into one big chunk that must go into chip memory. I really don't want to >have 50K of stuff in chip memory which really doesn't need to be there. And This is not a bug. It's a byproduct of SMALLDATA itself. When you use the SMALLDATA option, you are telling BLINK to make sure all your data is within 64k of a base pointer. You can't keep the data within the limit if you split it up between CHIP and FAST ram. Sorry, that's just the way it is. (And you did get through to me anyway - I'm a Distiller.)
SLMYQ@USU.BITNET (04/10/88)
>>When you use SMALLDATA and have a few data chunks that are supposed to go into >>chip memory and a few that don't need to, it just sticks them both together >>into one big chunk that must go into chip memory. I really don't want to >>have 50K of stuff in chip memory which really doesn't need to be there. And > >This is not a bug. It's a byproduct of SMALLDATA itself. When you use the >SMALLDATA option, you are telling BLINK to make sure all your data is within >64k of a base pointer. You can't keep the data within the limit if you split >it up between CHIP and FAST ram. Sorry, that's just the way it is. 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? I don't need everything to be next to each other. Maybe you could stick in another switch which would be somewhere between SMALLDATA and "BIGDATA". It would coagulate all data hunks OF THE SAME TYPE, and I think that's what most programmers like me need. Glad to hear it's not a bug. :) Bryan Ford (SLMYQ@USU.BITNET)
walker@sas.UUCP (Doug Walker) (04/12/88)
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.
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (04/14/88)
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