Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |