Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!zehntel!hplabs!sdcrdcf!sdcsvax!akgua!mcnc!philabs!cmcl2!seismo!rlgvax!cvl!umcp-cs!zben
From: zben@umcp-cs.UUCP
Newsgroups: net.lang
Subject: Re: Re: Slow Fortran I/O - (nf)
Message-ID: <7795@umcp-cs.UUCP>
Date: Sun, 8-Jul-84 04:45:55 EDT
Article-I.D.: umcp-cs.7795
Posted: Sun Jul  8 04:45:55 1984
Date-Received: Thu, 12-Jul-84 04:37:02 EDT
References: <3746@fortune.UUCP>, <114@bragvax.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 15

One implementation for the Univac 1100 I saw had the format string compiled
(sort of, actually more like P-code-ified) the first time the format was used.
Some kind of flag (like a word of zeroes) was placed in the first word of the
storage used by the format, as a flag not to compile it again.  The big win of
this approach was that even if the format were dynamically built it would be
compiled the first time it was used.  If it was subsequently changed to be
something else, the flag was blown away, and it got compiled again.  I don't
remember what it did to ensure that the compiled format was not longer that
the core allocated by the Fortran compiler though...

I suppose one could always malloc/getmain/mcore$ a buffer for the compiled
format and put a *pointer* to it in the *second* word of the core area...

-- 
Ben Cranston   ...seismo!umcp-cs!zben      zben@umd2.ARPA