Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] FORTRAN -> ???



My first real programming job was in a bank on Burroughs medium systems.
Back in those days memory was measured in K, and 1MB memory system was
pretty large. The computer languages of the day had ways of segmenting
the system. it was the programmer who chose how to segment the code.
Demand paged virtual memory systems were very new in the early 1970s. We
had a brand-new IBM 370 running OS/VS1 with 2K page size, but most of my
code was on Burroughs. But even on a VM system you had to arrange your
code somewhat memory efficient. Burroughs at that time did not have a
linkage editor, but on Burroughs, the system was somewhat efficient. On
Burroughs when you wanted to sort, you called the sort directly from
COBOL, and the compiler would effectively swap out the rest of the
program during the sort. On IBM, the sort very was terrible. The better
way to do it was to use JCL where the input to the sort was generated by
a job step, you then called the sort command from JCL, then the next job
step would take the results. Back in the day programmers spent a lot of
time making their programs work in tight memory. Today we tend to be
lazy about memory because we have an OS that automatically segments our
code and data into pages. But, those who work in embedded systems still
have to consider the memory constraints.

On 01/24/2012 10:30 AM, Jerry Natowitz wrote:
> As I remember, and I think this is Digital PDP-11 RSX11, you could have disk resident overlays, memory resident overlays, or a mixture of the two. 
>
> Memory resident overlays were a bizarre manifestation of the 16 bit program address spaces  (64K each) coupled with the ability to have at least 22 bits worth of memory ( 4096K).  The base, and all memory resident overlays, were loaded into memory, but the program's address space was limited to the base, one tree of memory resident overlays, and/or one tree of disk overlays.
>
> I can remember spending days on shoe-horning what we thought were huge programs to run in these tiny spaces.  I have a vague recollection that disk overlays were defined using "*" and memory overlays "!".
>
> Now don't get started on core dumps :-)
>
> ---- Original message ----
>> Date: Tue, 24 Jan 2012 07:42:19 -0500
>> From: discuss-bounces+j.natowitz=rcn.com at blu.org (on behalf of Jerry Feldman <gaf at blu.org>)
>> Subject: Re: [Discuss] FORTRAN -> ???  
>> To: discuss at blu.org
>>
>> On 01/23/2012 04:55 PM, Jay Kramer wrote:
>>>   Excuse me if this is a stupid question given the email chain.  Is it
>>> still possible to compile Fortran IV?   Will it run on linux?  I wrote a
>>> program in FORTRAN IV that uses overlays but other than that is straight
>>> forward code.
>> Strange. I have not heard of overlays being used in decades :-)
>> BTW: Before we had virtual memory, overlays were used to create a
>> smaller memory footprint in a fixed-memory system.


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org