On Sep-17, Matt Diephouse wrote:
> Having mentally absorbed the forth.pasm code, I thought I'd rewrite it
> in PIR and try to make it a full parrot compiler and, hopefully, a bit
> more approachable. I've already begun on this (see attached file).
> Unfortunately, I've run into a few issues/questions along the way.
>
> In the following, the term "eval" refers to the use of the
> compreg/compile opcodes.
>
> o In current builds evaling non PASM/PIR code segfaults (or gives a
> bus error on OS X) as a result of the last patch to op/core.ops (See
> #31573). Any plans here?
Leo made the change as a result of a discussion I kicked off, so it's
probably my fault. :-| But more to the point, I abandoned that
particular interface at the same time, and at least until the bug is
fixed, I recommend you do the same. Instead of using the compile op,
just call your PMC as a subroutine:
$P0 = compreg "forth"
$P1 = $P0("...forth code...")
Personally, I plan to stick to this interface unless C<compile> becomes
useful, but other people (eg, Dan) disagree that my usage is correct.
> o Evaling PIR code requires a named subroutine and the use of the
> 'end' opcode. Someone mentioned on IRC that this might not be the
> desired behavior. Is it?
Leo talked about adding an @ANON attribute to subs, but I don't believe
he has implemented it yet. For now, just use a fixed name every time you
compile; the symbol table entry will be overwritten every time you
compile, but the compilation should return the sub object for you to
keep track of, so you don't need to care about the symbol table.
> o Calling subroutines from an eval creates a copy of the user stack,
> so all changes are lost (rendering my Forth code unusable). Is this
> behavior correct? If so, how should I go about this?
Dunno. Don't use an Eval? (Use a plain Sub or something instead)
> Any clarifications or statuses, as well as any comments on the PIR
> code, would be very much appreciated. I'm more or less stalled at this
> point until I get some answers/help. It would be nice to get this to
> the point where it can be used to test parrot (as well as serve as an
> example to anyone wanting to write a compiler).
I have finally gotten around to committing my example compiler in
languages/regex. Read the README for usage instructions. Or for a
painful account of my attempts to accomplish what you're doing, just
for a different language, see http://0xdeadbeef.net/wiki/wiki.pl?FinkBlog
parrot/examples/japh/japh15.pasm is a good source of example code too.
