Related articles |
---|
[4 earlier articles] |
Re: Incremental Compilers markland@vnet.ibm.com (Matthew Markland) (2000-05-12) |
Re: Incremental Compilers HSauro@fssc.demon.co.uk (Herbert M Sauro) (2000-05-12) |
Re: Incremental Compilers mkent@acm.org (Mike Kent) (2000-05-12) |
Re: Incremental compilers brunix!apollo!alan (Alan Lehotsky) (1986-09-18) |
Incremental compilers charlie@genrad.com (1989-01-24) |
Re: Incremental compilers ti-csl!csc.ti.com!pf@cs.utexas.edu (Paul Fuqua) (1989-01-15) |
Re: Incremental compilers rogerson@PEDEV.Columbia.NCR.COM (1989-01-26) |
Re: Incremental Compilers nick@lfcs.ed.ac.uk (Nick Rothwell) (1989-01-27) |
From: | rogerson@PEDEV.Columbia.NCR.COM (Dale Rogerson) |
Newsgroups: | comp.compilers |
Date: | 26 Jan 89 16:48:15 GMT |
References: | <3225@ima.ima.isc.com> |
Organization: | NCR Corp., Engineering & Manufacturing - Columbia, SC |
I believe that in QuickBasic the incremental compiler compiles to p-code which
is then interpreted. From what I understand (I have an old version which is
not really incremental) the compiler will check the lines as you type them.
The p-code is based on token threaded byte codes.
The "perfect" package would allow integration of pre-compiled modules and the
environment would consist of a Turbo/Codeview type debugging environment from
which you not only debug, but you CHANGE variables and functions on the source
level and continue to run. Then after you have finished debugging you preform
a final compile which would compile to machine code. The neat thing about this
method is that the final compile only needs to be done once, therefore, it
does not have to be fast i.e. it can really optomize!
Austin Code works has an interactive C interpreter with source code. This
might be a good place to start some projects.
-----Dale Rogerson-----
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.