Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcuhb!hpcllla!hpclisp!cary@hpclcac.HP.COM
From: cary@hpclcac.HP.COM (Cary Coutant)
Newsgroups: comp.sys.hp
Subject: Re: f77 and 2 MB data segment limit
Message-ID: <1340153@hpclcac.HP.COM>
Date: 24 Oct 90 17:48:14 GMT
References: <TOIVANEN.90Oct21030017@tukki.jyu.fi>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 48

> Without -K option variables are allocated dynamically from the stack.
> I am quite sure that stack size limit is more than 2 MB, so that the
> problem shouldn't be stack size limit. I would like to know what is
> causing this 2 MB limit and how I can make big programs work without
> -K option or statical variable allocation.

The default stack size limit is probably around 4 MB -- I'm not sure
exactly (it's 8 MB on my 800 here at work).  You can check by running
adb on your kernel:

	echo "maxssiz?D" | adb /hpux

The number will be in 2K pages, so 4096 pages is 8 MB.

When you use -K with the Fortran compiler, locals are allocated
statically, but they are allocated in BSS, so your .o and a.out
files should not be any larger.

If you're running on an old version of HP-UX, it's possible that
an older version of Fortran allocated locals in the initialized data
area, but it doesn't on my 7.0 system.  You can easily check to see
if this is the case -- try compiling the following file with
"f77 -c -K big.f":

	subroutine big
	real x(4000000)
	x(1) = 0
	x(4000000) = 1
	return
	end

Then run "nm big.o".  Here's the output that I get:

	Symbols from big.o:

	Name                    Value   Scope  Type    Subspace

	$global$            |          |undef |data   |
	big                 |         0|extern|entry  |$CODE$
	M$2$big             |  16000000|undef |common |$DATA$
	S$2$big             |        32|static|data   |$LIT$

The third symbol indicates that the local array is a "common" symbol,
which the linker will allocate from BSS.  This won't make your
executable big.


Cary Coutant, HP Language Lab, Cupertino, CA