Re: f95 interpreter

glen herrmannsfeldt <gah@ugcs.caltech.edu>
24 Oct 2004 23:39:11 -0400

          From comp.compilers

Related articles
Re: f95 interpreter gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-10-21)
Re: f95 interpreter genew@mail.ocis.net (Gene Wirchenko) (2004-10-23)
Re: f95 interpreter gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-10-24)
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.lang.fortran,comp.compilers
Date: 24 Oct 2004 23:39:11 -0400
Organization: Comcast Online
References: <Pine.LNX.4.60.0410161511130.2756@janus> 04-10-142 04-10-169
Keywords: interpreter, PL/I, comment
Posted-Date: 24 Oct 2004 23:39:11 EDT

Gene Wirchenko wrote:


> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:


(snip)


>>Most are closer to incremental compilers, where at minimum each
>>statement is compiled to an intermediate form, converting language
>>tokens (keywords) to an internal form, and possibly user symbols
>>(variable names) also. Most BASIC systems work like that, many
>>compiling each line when it is entered. On the continuum between


> IME, no. They simply convert it to a tokenised form.


Sorry, yes, that is what I meant. That might include a
pointer to the symbol table entry and converting numeric
constants to their internal representation, though.
Some would do it as the line was entered, others only
with the RUN command.


There is also a story of one HP machine that converted
algebraic expressions to RPN on entry, and back again
to display them (as in the list command).


>>compilers and interpreters, it is most of the way toward interpreters.


> [snip]


>>[Back in the early 1970s, IBM had two PL/I compilers, the X compiler
>>which generated optimized machine code and the CK (checkout) compiler
>>which generated bytecodes and interpreted them. They used the same
>>front end and accepted the same input language. The CK compiler
>>offered all of the nice debugging stuff you'd expect from an
>>intepreter, full range checks, bogus pointers, type mismatches, all
>>that. You could even tell CK to generate code with call stubs so you
>>could run a mix of X and CK code if you wanted. Of course, high
>>quality debugging support like that is now obsolete. -John]
(snip)


I never use the checkout compiler. I think it was too expensive
for many to buy. (I suppose rent is more accurate.)


> [Do keep in mind that back in those days the fast computers ran at 1 MHz,
> so the difference in code speed could make the difference between a
> minute-long run and an all-night run. But it is my impression that the
> call stubs were mostly used to call code in precompiled libraries. -John]


I am not sure how small a machine those compilers would be
used on. The 360/91 and 370/168 were closer to 16 MHz.


PL/I (F) was supposed to be able to run on a 360/40 with 64K
of core, 20K for the OS, 44K for the compiler. I don't believe
that feature was kept for the newer compilers.


-- glen
[My assistant, Mr. Google, points out that an article in the IBM
Systems Journal published in 1973 about the checkout compiler is
available as http://www.research.ibm.com/journal/sj/123/ibmsj1203G.pdf
and another from the UK Computer Journal is at
http://www3.oup.co.uk/computer_journal/hdb/Volume_15/Issue_02/150099.sgm.abs.html
The former says the interpreter was about 250K but they used overlays
to fold it into 60K. The latter says it ran reasonably fast on the
1MHz 360/65 in 100K. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.