Why these original FORTRAN quirks?
in [Fortran]
|
From: Rostyslaw J. Lewyckyj on 16 Oct 2006 20:45 jmfbahciv(a)aol.com wrote: > In article <E_ydnYwN6JVCva_YnZ2dnUVZ8sydnZ2d(a)bt.com>, > Andrew Swallow <am.swallow(a)btopenworld.com> wrote: > >>jmfbahciv(a)aol.com wrote: >>[snip] >> >> >>>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. > > >> A call to a proper function >>that simply returns a number takes takes 10 to 20 assembler >>instructions. An assignment takes 2 instructions. > > > That depends on the architecture and implementation of the > compiler. OTOH, the value of pi was different if you had > 8bits, 16, 24, 32, 36, 64, or calculated it every time it > was needed. (This didn't happen with pi but could with other > constants. > > I'm talking about an intrinsic function and not one that > required a formal CALL statement. > > The compiler could furnish the constant at compilation time > (I'm assuming that EXEs could not be transported between > architectures back then). So no extra instructions were > required. That's what intrinsic call could mean. > > /BAH > 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. :) The more modern Fortran PARAMETER statement serves some of this purpose. It allows one to define named constants with assigned values to be literaly used in the compilation process. i.e. if you write PARAMETER (XYZ={value}) then the compiler will literally substitute {value} where ever it recognizes XYZ Then the statements containing XYZ are eligible for any and all optimizations that would occur, as if {variable} had been coded. i.e. XYZ is not variable , i.e. not changeable at execution. However XYZ = {value} is being defined by the programmer at the time of writing the code, so the source code must be edited if one is moving the code and wants to change the value. Note; The difference between PARAMETER (XYZ={value}) and DATA ABC/{value} is that XYZ is literally a constant and gets to affect the compilation, while ABC is a variable whose value is initialized at compilation, but that variable can have its value changed any time during execution. (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) -- Rostyk
From: glen herrmannsfeldt on 16 Oct 2006 21:12 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. (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. -- glen
From: Joe Morris on 17 Oct 2006 08:46 "Rostyslaw J. Lewyckyj" <urjlew(a)bellsouth.net> writes: >sqrfolkdnc wrote: >> Joe Morris wrote: >>>And before someone asks, I've never seen the source for the original >>>FORTRAN compiler based on the first version of the language specs. >>>Does anyone know if it's available? >> >> Nobody has ever seen the source, not even the author. Denise Hopper >> wrote it in machine language (octal?) before the first assembler was >> written. >> >Really? >before the first assembler? Wow! :) Not unreasonable, although I've not previously seen the statement that the original implementation was hand-coded. One point to remember is that in the early days of electronic computers there were jobs for *programmers* and jobs for *coders*. Programmers designed the logic required to implement the end user's requirements and generated a detailed logic document; coders translated the logic into machine instructions. Many, many years ago Jackson Granholm wrote songs for the enjoyment of attendees at SIGBOOZE at ACM meetings; one was a mournful song about a coder's loss of his job because of the arrival of a compiler. To the tune of "Tom Dooley" the chorus went: Hang down your head, Sam Neulshaw [*] Hang down your head and cry, Hang down your head, Sam Neulshaw, Our compiler's gonna fly! [*] No, I never knew how Jackson spelled the name Several of us at the 1966 ACM meeting in Los Angeles tried to convince Jackson to publish the lyrics, but AFAIK he never did. Joe Morris
From: Joe Morris on 17 Oct 2006 08:56 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes: >(someone else wrote) >>> Columns 73 to 80 were for card sorting. BASIC is the language with >>> the label on every line. Putting a label on every line in Fortran >>> uses up the symbol table and switches the optimiser off. >The 704 read each card row into two 36 bit words, ignoring the last >eight columns. (I would hate to write the code that converted that >into columnwise data.) The unit record equipment on the 704/709/7090 (and presumably 7094 as well) used plugboards to map the interface to specific column positions, but regardless of how you set the plugs the hardware interface processed 24 words of data for the card reader or punch, which with the usual plugging were 12-row left, 12-row right, 11-row left, 11-row right, and so on through 9-row right. With 36 bits per word that comes out to 72 columns of data. One oddity of FMS (at least as I remember it) was that despite the miniscule amount of available memory by today's standards (a fully- equipped machine had 32768 words of memory) was that the executing load included the code to translate text between BCD and card image format. Joe Morris
From: sqrfolkdnc on 17 Oct 2006 11:17
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". |