[comp.sys.amiga] Maximum array size in Lattice 4.0

jonasf@kuling.UUCP (Jonas Flygare) (04/09/88)

Well, maybe I'm just plain stupid, or something, but if any of you people 
"out there" have an intelligent answer to this, I would be very grateful.
I have been cursing over a program for a while now, and the trouble is
the compiler barfs on an array of ints, with a size of almost 70000.
I cannot find anything in the manual mentioning a restriction on the
size of arrays (short of a 32 bit int, of course). Anyone? And if there is
a limit, how can I get around the problem? (easy).
The program in question is the compress program posted a while ago,
I want to recompile it for 16bit mode.
-- 
Jonas Flygare (aka Flax)         +------------------------------------------+
email: jonasf@kuling.UUCP        | "Never try to hack while a playful ferret |
real:  Vaktargatan 32 F:621      |  is watching your toes.                  |
       S-754 22 Uppsala Sweden   +-------- I TRIED....... OUCH! ------------+ 

cmcmanis%pepper@Sun.COM (Chuck McManis) (04/14/88)

In article <692@kuling.UUCP> jonasf@kuling.UUCP (Jonas Flygare) writes:
>
>Well, maybe I'm just plain stupid, or something, but if any of you people 
>"out there" have an intelligent answer to this, I would be very grateful.
>I have been cursing over a program for a while now, and the trouble is
>the compiler barfs on an array of ints, with a size of almost 70000.

In the 4.0 release (currently 4.01 call the BBS for the update) the options
for base address data references was changed. It use to default to false
now it defaults to true. That means your BSS size couldn't be more than 
64K (+/- 32K). The fix is easy, compile it with the -b1 switch which will
turn this mode off and address everything with 32 bit addresses. 
Read the manual under the section 'compiler features' or some such for
a description of these issues.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.

rminnich@udel.EDU (Ron Minnich) (04/14/88)

In article <49386@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>
>In the 4.0 release (currently 4.01 call the BBS for the update) the options
>for base address data references was changed. It use to default to false
>now it defaults to true. That means your BSS size couldn't be more than 
>64K (+/- 32K). The fix is easy, compile it with the -b1 switch which will
>turn this mode off and address everything with 32 bit addresses. 
>Read the manual under the section 'compiler features' or some such for
>a description of these issues.
  Actually for my Lattice compiler it is the -b0 switch. Look under the section
for lc1, since the section for lc not only does not correctly describe
-b but also lies about its setting (the section for lc1 tells the truth).
Note also the -r switch, look at the section for lc1 to get its true setting.
Note also the -l switch, it is kind of important.
 If you have $75 for an upgrade, then forget lattice v4.0 
and save the money and get manx instead. That
is my opinion as a Lattice owner. The reason, in three letters: sdb.
I am trying to get Larry Wall's perl language running, and am almost 
there, and am getting terminally discouraged with the !@#$ guru
situation. sdb would help oh-so-much.
  Also i am sitting here watching Lattice V4.0 using ram only
and still taking 15 minutes to compile a 2100-line file. Something of a 
disappointment, esp. as about 12 of those minutes are code generation.
And its not the floppy: the floppy lies unused about 80% of that time.
This compiler seems unreasonably slow.
   Another major annoyance: trivial differences between unix cc 
and lattice lc. My favorite is that they use -dSYMBOL instead of
-DSYMBOL- i get to rewrite all the unix makefiles. 
   Don't mind me, it has been a long day.

-- 
ron (rminnich@udel.edu)

uzun@wolf.UUCP (Roger Uzun) (04/14/88)

To link big arrays make sure you compile with the -b0 option to turn off
d16(a4) type addressing.  This likely is the culprit

-Roger

fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (04/15/88)

In article <49386@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes:
> In the 4.0 release (currently 4.01 call the BBS for the update) the options
> for base address data references was changed. It use to default to false
> now it defaults to true. That means your BSS size couldn't be more than 
> 64K (+/- 32K). The fix is easy, compile it with the -b1 switch which will
                                                      ^^^
> turn this mode off and address everything with 32 bit addresses. 
> Read the manual under the section 'compiler features' or some such for
> a description of these issues.

The change to the base relative addressing flag is a little confusing.  The
compiler uses base relative addressing by default.  If you want to turn
that off the switch setting is -b0.  It's discussed on page C-19, the
                               ^^^
description of lc1.  The manual says:

-b     Base register relative data addressing.  Note that this [is] now the
       default.  To switch this mode off use -b0 option.  The options -b or
       -b1 will switch base register relative data addressing back on
       again.

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

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

jonasf@kuling.UUCP (Jonas Flygare) (04/18/88)

From article <49386@sun.uucp>, by cmcmanis%pepper@Sun.COM (Chuck McManis):
> In article <692@kuling.UUCP> jonasf@kuling.UUCP (Jonas Flygare) writes:
[Voluminous question deleted]
> 
[Description of how to solve my problem]
> Read the manual under the section 'compiler features' or some such for
> a description of these issues.
I thought I did that. Unfortunately I was looking at the pages on LC, not
LC1.. There it says: "-b	This option *causes* the compiler to use
a base-relative (...) instead of a 32-bit absolute address"
(Note "causes"..) Now, I will award a bag of virtual peanuts to the first
person who guesses what I assumed about LC's default mode... ;-) 


> --Chuck McManis
> uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
> These opinions are my own and no one elses, but you knew that didn't you.
-- 
Jonas Flygare (aka Flax)         +------------------------------------------+
email: jonasf@kuling.UUCP        | "Never try to hack while a playful ferret |
real:  Vaktargatan 32 F:621      |  is watching your toes.                  |
       S-754 22 Uppsala Sweden   +-------- I TRIED....... OUCH! ------------+