Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!ginosko!usc!apple!motcsd!hpda!hpcuhb!hpcllla!hpcllz2!dhandly
From: dhandly@hpcllz2.HP.COM (Dennis Handly)
Newsgroups: comp.sys.hp
Subject: Re: HP9000 Pascal Buglist / Wishlist
Message-ID: <3770029@hpcllz2.HP.COM>
Date: 6 Oct 89 02:59:30 GMT
References: <2258@mva.cs.liv.ac.uk>
Organization: Hewlett Packard Calif. Language Lab
Lines: 28

> 1. Extremely large executable size (On Series 800 machines only)
>    -------------------------------
>    Try compiling the following HP Pascal program on a Series 800 machine...
>    (WARNING: Make sure you have at LEAST 250 MBs of free disk space !)
>    program bigexec ( input , output ) ;
>    type str255 = string [ 255 ] ;
>    var huge : array [ 1..1000 , 1..1000 ] of str255 ;
>    ...

The above problem used to create an object file (.o) of the same large size.
This was solved with a partial roll to the object file format that caused all
compilers and the linker to be changed.
Another roll had an explicit design for these large uninitialized areas.

On MPE XL, an attempt was made to change the executable, NMPRG, size in the
linker, but certain areas were not initialized properly, and the enhancement
was backed out.  (COBOL is more complex than Pascal since its items can 
be initialized or not, which creates gaps.)

This problem currently affects only Pascal, COBOLII/XL and RPG/XL.
Other languages don't use the $GLOBAL$ subspace.

A simple work-around, other than NEW, is documented in the COBOLII/XL manual:
Use the EXTERNAL clause.  (This puts the item in $BSS$.)

A similar work-around for Pascal would be to put the item in a module or to
compile with the $GLOBAL$ option (all or nothing).  The later method may 
cause extra code to be generated to load/store items.