Why these original FORTRAN quirks?
in [Fortran]
|
From: krw on 17 Oct 2006 12:51 In article <1161098254.337809.64750(a)b28g2000cwb.googlegroups.com>, carey.schug(a)gmail.com says... > > James Parsly wrote: > > When I was in high school, back in 1975, we had an IBM 1620 > > with a Fortran II compiler. It had 20K digits of memory and no > > disk or tape of any kind. > > in 1965-66, we had 40K of memory (60K was the max you could get). BTW, > the 1620 model 1 used table lookup for addition and subtraction, using > locations 100-199 for the add table and 200-399 for the multiply table. Wasn't the 1620 also known as the CADET (Can't Add Didn't Even Try)? They're a little before my time though. > The model 2 only used table lookup for multiply. The optional > floating point hardware would do decimal mantissas up to 98 digits > long, more precision than any other computer I know of. Might have > only been 48 or 49 for division. -- Keith
From: Gordon Sande on 17 Oct 2006 13:00 On 2006-10-17 13:51:11 -0300, krw <krw(a)att.bizzzz> said: > In article <1161098254.337809.64750(a)b28g2000cwb.googlegroups.com>, > carey.schug(a)gmail.com says... >> >> James Parsly wrote: >>> When I was in high school, back in 1975, we had an IBM 1620 >>> with a Fortran II compiler. It had 20K digits of memory and no >>> disk or tape of any kind. >> >> in 1965-66, we had 40K of memory (60K was the max you could get). BTW, >> the 1620 model 1 used table lookup for addition and subtraction, using >> locations 100-199 for the add table and 200-399 for the multiply table. > > Wasn't the 1620 also known as the CADET (Can't Add Didn't Even Try)? > They're a little before my time though. The use of look up tables meant that they were great at octal arithmetic if you replaced the tables with the suitable values for octal! >> The model 2 only used table lookup for multiply. The optional >> floating point hardware would do decimal mantissas up to 98 digits >> long, more precision than any other computer I know of. Might have >> only been 48 or 49 for division.
From: James Parsly on 17 Oct 2006 14:41 The compiler we used did have an option that allowed you to read in the fixed subroutine deck, and it would add the parts that your program used to your deck. I suppose that idea was to create a "stand alone" deck that didn't require you to dig out the fixed subroutine deck every time you wanted to run. We were encouraged not to do this, as it wasted a whole bunch of cards. Of course, most of what we were doing was running class assignments anyhow. I remember doing a numerical integration using inscribed rectangles of f(x) = 1/x from 0 to 2 using various delta x values. For a 10000 iteration case it took 45 minutes to run. My father ran the same program on the mighty IBM 360 computer at ORNL and it took 15 seconds. My very first job was working with this same computer the summer after I graduated. We spent the later part of our senior year writing a set of programs to handle class scheduling for the high school. I spent my summer running programs that added up enrollment, checked for conflicts, etc.. "sqrfolkdnc" <carey.schug(a)gmail.com> wrote in message news:1161098254.337809.64750(a)b28g2000cwb.googlegroups.com... > > James Parsly wrote: >> When I was in high school, back in 1975, we had an IBM 1620 >> with a Fortran II compiler. It had 20K digits of memory and no >> disk or tape of any kind. > > in 1965-66, we had 40K of memory (60K was the max you could get). BTW, > the 1620 model 1 used table lookup for addition and subtraction, using > locations 100-199 for the add table and 200-399 for the multiply table. > The model 2 only used table lookup for multiply. The optional > floating point hardware would do decimal mantissas up to 98 digits > long, more precision than any other computer I know of. Might have > only been 48 or 49 for division. > > My recollection: > > First, real programmers don't use precompilers to check syntax. > > 1. load in pass one of compiler > 2. read in source program, punching intermediate output, maybe 1/5 the > size of source. > 3. remove intermediate output and put aside > 4. hit start and punch out symbol table. > 5. load in pass 2 of compiler > 6. put symbol table IN FRONT OF intermediate output and read into pass > 2, punching object deck, maybe double the size of the original source. > 7. read in subroutine library, punching out those that you needed > 8. Read in "loader" followed by object deck to execute? > > I'm not sure of #7 & #8, maybe you did or could skip #7 that and > instead read in the subroutine library when you executed the program, > maybe the "loader" was just the 3 card "clear storage and load". >
From: Gerard Schildberger on 17 Oct 2006 15:08 | sqrfolkdnc wrote: |> James Parsly wrote: |> When I was in high school, back in 1975, we had an IBM 1620 |> with a Fortran II compiler. It had 20K digits of memory and no |> disk or tape of any kind. | in 1965-66, we had 40K of memory (60K was the max you could get). BTW, | the 1620 model 1 used table lookup for addition and subtraction, using | locations 100-199 for the add table and 200-399 for the multiply table. | The model 2 only used table lookup for multiply. The optional | floating point hardware would do decimal mantissas up to 98 digits | long, more precision than any other computer I know of. Might have | only been 48 or 49 for division. | | My recollection: | | First, real programmers don't use precompilers to check syntax. | | 1. load in pass one of compiler | 2. read in source program, punching intermediate output, maybe 1/5 the | size of source. | 3. remove intermediate output and put aside | 4. hit start and punch out symbol table. | 5. load in pass 2 of compiler | 6. put symbol table IN FRONT OF intermediate output and read into pass | 2, punching object deck, maybe double the size of the original source. | 7. read in subroutine library, punching out those that you needed | 8. Read in "loader" followed by object deck to execute? | | I'm not sure of #7 & #8, maybe you did or could skip #7 that and | instead read in the subroutine library when you executed the program, | maybe the "loader" was just the 3 card "clear storage and load". You are recollecting the IBM FORTRAN II compiler. There was a Kingston FORTRAN II compiler that needed: 40k no hardware floating point and did it at card reader speed --- in one pass. Fantasic compiler --- I still have the language specs. _______Gerard S.
From: Rostyslaw J. Lewyckyj on 17 Oct 2006 15:41
glen herrmannsfeldt wrote: > In comp.lang.fortran Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > > (someone wrote) > >>>>>I don't know why PI wasn't a function. > >>>>I do. Fortran did not support macros. > >>>I don't understand what you meant here. > > (snip) > >>But, To have the compiler automatically furnish a value >>at compilation time you need to name it eg "PI" , and then >>you refer to it using that name "PI" throughout the code. >>I.e. you have introduced the mis feature of reserved keywords >>into the language. :) > > As an intrinsic function it would not be any different > than any other intrinsic function. It could even > have an argument which was then multiplied by pi. > (Especially useful on non-binary machines.) > > Original PL/I has argumentless functions that don't > require the (). While not exactly a reserved word > problem, it does complicate adding new features to the > language. (That, and implicit variable typing.) > Later, the use of () was added. > Well yes and no. The intrinsics are not really a part of the language, though almost. I don't believe any such functions are mandated for the language in the standard. They are functions known to the compiler that are a part of the supporting libraries, and the compiler generates special execution time calls to the these functions. (I don't think any of these are evaluated at compile time ) Also while the compiler may generate special calls to its' own versions of these routines by default, it can be informed to treat these names as user provided EXTERNAL routines called with the standard subroutine, function, linkage. > (snip on initializing variables in a DATA statement.) > >>(An interesting detail of this is that if for any reason >>the code module into which the initialization of ABC is compiled >>is reloaded during execution e.g. overlays, then the value >>of ABC is reset ). (I don't know if SAVE would take care of this) > > > It tends to be a linker function, and so might violate the > standard. Compilers I used to know put static data into > the same CSECT (relocatable unit) as code, and so could > have this problem. COMMON blocks should be able to be > moved into the appropriate overlay segment, the root > segment if they should not be overlayed. PL/I compilers > that I used to know put static initialized data into a > separate CSECT, possibly for this reason. > Well plain DATA initializes local variables which are kept in the same CSECT as the code. Theoretically, I suppose, these variables could be placed into a seperate CSECT with a special name, which the linker would automatically move to the root segment, But I don't know of such. The BLOCK DATA subroutine is used to initialize variables in named COMMONs, and named COMMONs can be positioned in the overlay under programmer control in the linker. I know that one can have several different pre compiled versions of a BLOCK DATA subroutine and link one in to customize a program without needing to recompile the other pieces. (I'm not explaining this well :( ) > -- glen P.s. The start of this thread in alt.folklore.computers was about some features of the original FORTRAN. I added c.l.f to the distribution, so that experts might correct my misstatements. :) -- Rostyk |