Xref: utzoo comp.lang.fortran:1860 comp.sys.att:5927
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!umbc3!mbph!hybl
From: hybl@mbph.UUCP (Albert Hybl  Dept of Biophysics  SM)
Newsgroups: comp.lang.fortran,comp.sys.att
Subject: Gigantic character variables
Keywords: Muckraking Standards Neglect_of An_apology
Message-ID: <589@mbph.UUCP>
Date: 24 Mar 89 18:56:14 GMT
Organization: University of Maryland, School of Medicine, Baltimore, MD 21201
Lines: 60


In article <587@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl 
Dept of Biophysics  SM), I muckraked fortran language
implementors for converting the standardization process into
a demolition derby and the standards organizations of egregious
neglect in the enforcement of the standard.  The X3.9-1978
standard was pregnant with many potentially useful feature. One
of them was the CHARACTER typing statement; both character
arrays and character variables were allowed.  While the
implementors proceeded to render the character variable unserviceable
for use in portable programs, the standards committee with remarkable
indifference entered hibernation.  History seems about ready to
repeat itself.

I also posted a short validation program and reported that only
AT&T, showing a kinder-gentler attitude toward standardization,
allowed a character variable to be 750000 bytes long.  I
received an email message from Daniel Levy, att!ttbcad!levy,
suggesting that the string variable be put into COMMON:

*     PROGRAM GIGANTIC_STRING
      PARAMETER (K=7280900)
      COMMON /GENE/ AND
        CHARACTER AND(K)*1
        CHARACTER*(K) DNA
        EQUIVALENCE (DNA,AND)
      DNA(K-23:K) = 'An exercise in futility!'
      PRINT *,K,(AND(J+K-24),J=1,24)
      END

For (K .LE. 7280900), the AT&T XLA+ fortran compiler compiled the
program and its execution on our AT&T 3B2 worked!  That is not bad
for a machine with only 4 M bytes of RAM memory.  Daniel also said
"...modern paging operating systems should make the issue of gigantic
arrays and small core practically moot. ...  You should be able to have
an uninitialized array almost as big as the maximum process size on
the 3B2 (16 meg)."

When (K .GT. 7280900 Mbytes), the following run time diagnostics are
printed and the executions are killed:
  XLA+ NOTICE:  growreg -- Insufficient memory to allocate 3621 pages -
         system call failed.      /* For K=7284000 */
  XLA+ NOTICE:  growreg -- Insufficient memory to allocate 8145 pages -
         system call failed.      /* For K=16665045 */
  XLA+  a.out too big         /* For K=16670045 and K=100000000 */
Hmmm.. The diagnostics suggest that I may be able to tweak the
system into giving me another 8 M bytes.  Does anyone know how
I might do it?  

Let me apologize to AT&T for selling them 7 Mbytes short.  I
must say they do seem to know how to do it right.  I think I
should also say that I am not connected with AT&T.

----------------------------------------------------------------------
Albert Hybl, PhD.              Office UUCP: uunet!mimsy!mbph!hybl
Department of Biophysics       Home   UUCP: uunet!mimsy!mbph!hybl!ah
University of Maryland                CoSy: ahybl
School of Medicine
Baltimore, MD  21201                 Phone: (301) 328-7940 (Office)
----------------------------------------------------------------------