Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!wuarchive!psuvax1!psuvm!brl102
From: BRL102@psuvm.psu.edu (Ben Liblit)
Newsgroups: comp.sys.apple2
Subject: HyperC P-code (was Re: two questions...)
Message-ID: <90331.121946BRL102@psuvm.psu.edu>
Date: 27 Nov 90 17:19:46 GMT
References: <m0iVm8Q-0001erC@jartel.info.com> <8530@darkstar.ucsc.edu> <1990Nov5.141216.28524@mintaka.lcs.mit.edu> <4673@tellab5.tellabs.com>
Organization: Penn State University
Lines: 51

In article <4673@tellab5.tellabs.com>, toth@tellabs.com (Joseph G. Toth) says:
>
>Has anybody investigated Manx, Apprentice C or HyperC to determine
>whether either of these is a P-code system??

HyperC does have P-code capabilities.  And I must say that it is truly one of
the sweetest P-code systems I've ever seen.  Check this out:

   - The HyperC compiler translates tokenized source (from the preprocessor)
     into P-code source.  That's right, *source*.  You can even read / edit the
     file if it makes you happy.

Now, once you've got the P-code source, there's two things you can do:

   - Put the source through the P-code assembler, which generates object P-code

Or:

   - Put it through the macro expander with an include file (I forget the name)
     that defines a macro for each of the P-code opcodes.  For the most part,
     these are expanded into JSR's.  So now, instead of P-code source, you've
     got good old 65xxx assembly source with lots of JSR's to the P-code
     driver.

   - Take the output from this and pump it through the native code assembler.
     It generates normal 65xxx object code with lots of references to external
     symbols.  These are entry points in the P-code driver.

Now, here's the really nice part.  The driver itself is a native code object
file.  So if you've got native code, with all those external references, just
specify the driver as one of the input files to the linker.  It resolves all
of the references and presto!  Your native code and the driver are doing the
tango.

HyperC also lets you mix native code and P-code freely within the WSM shell.
The shell sets the BRK vector to point to the start of the P-code interpreter.
The P-code *assembler* cooperates by putting a BRK at the start of every P-code
routine.

So, say your main() is executing in native code and you call a P-code routine.
Well, you JSR right to a BRK instruction.  The P-code interpreter kicks in and
the P-code executes, no problem.  When the P-code routine exits, the P-code
interpreter exits too, and you're back in native code to continue executing
main().

Is it just me, or is this one amazingly nifty way to implement a mixed native
code / P-code system?

                            Ben Liblit
                            BRL102 @ psuvm.bitnet -- BRL102 @ psuvm.psu.edu
                            "Fais que tes reves soient plus longs que la nuit."