|[4 earlier articles]|
|Re: Incremental Compilers email@example.com (Matthew Markland) (2000-05-12)|
|Re: Incremental Compilers HSauro@fssc.demon.co.uk (Herbert M Sauro) (2000-05-12)|
|Re: Incremental Compilers firstname.lastname@example.org (Mike Kent) (2000-05-12)|
|Re: Incremental compilers brunix!apollo!alan (Alan Lehotsky) (1986-09-18)|
|Incremental compilers email@example.com (1989-01-24)|
|Re: Incremental compilers firstname.lastname@example.org (Paul Fuqua) (1989-01-15)|
|Re: Incremental compilers rogerson@PEDEV.Columbia.NCR.COM (1989-01-26)|
|Re: Incremental Compilers email@example.com (Nick Rothwell) (1989-01-27)|
|From:||rogerson@PEDEV.Columbia.NCR.COM (Dale Rogerson)|
|Date:||26 Jan 89 16:48:15 GMT|
|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.
Return to the
Search the comp.compilers archives again.