Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Interpreter. What is the best way ? nick@nsis.cl.nec.co.jp (1991-11-14) |
| Re: Interpreters (and now, byte code standards) nick@nsis.cl.nec.co.jp (1991-11-15) |
| Interpreters: Summary nick@nsis.cl.nec.co.jp (1991-11-21) |
| Re: Interpreters: Summary jesup@cbmvax.cbm.commodore.com (1991-11-23) |
| Newsgroups: | comp.compilers |
| From: | nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) |
| Keywords: | interpreter, design |
| Organization: | Compilers Central |
| References: | 91-11-048 |
| Return-Path: | <nick@nsis.cl.nec.co.jp> |
| Date: | Fri, 15 Nov 91 15:12:53 JST |
Thanks to everyone who responded so far. It seems that a majority prefer
the idea of byte compilation to trees or tokenisation. I will summarise
when this thread has wound up completely.
I thought that rather than having an instruction for *each* function a
single CALL INTERNAL code (like CSP in PCODE) would be best. Does anone
have any better ideas ?
On another (related) note. The old PASCAL P-CODE has been hacked around
so much that I am sure that there are almost no standards for P-CODE any
more. Would anyone be interested in creating a standard P-CODE? My idea is
that if there is a standard (virtual) machine achitecture, and a standard
object code format for this machine, then it would allow anyone making
(extension) languages to use the same basic machine, and the languages
would be able to be linked together. I am willing to write
linker/loader/emulator to a standard if there is enough interest. (I'm
going to write it anyway..... so why not ?)
Send email, or post to the net. I WILL summarise.
Gavin Nicol (alias "nick" or "nick-san")
NEC Scientific Information System Development Ltd.
R&D KSP Bldg.
100-1 Sakato Takatsu-ku, Kawasaki, Kanagawa-ken 213,
Japan
Phone : <Japan> (044) 812-8411
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.