20 opcodes

Allison Randal allison at parrot.org
Thu Jul 8 19:11:19 UTC 2010


This is a very early draft of the first 20 opcodes at the lowest level 
of the microcode. The main question is "Can we implement all of Parrot 
in terms of these opcodes?" It'll be quick and easy to implement a tiny 
VM for these 20 opcodes, so a little practical experimentation is a good 
way to find what's missing. (i.e. chromatic and I talked about a great 
"stress test" of implementing a hash PMC in the microcode.)

------

add REG, REG, REG (integer/float with boxing/unboxing for PMC)
sub
mul
div

set REG, REG (by value, set from constant value or another register, 
boxing/unboxing for int, num, str, pmc)

goto LABEL
if BOOL, LABEL
iseq
isgt
islt
and
or

new PMC, PMC (create an instance object from an existing class object or 
"struct" definition, which was defined using declarative syntax)

read (fill a register from stdin, absolute minimum for testing)
write (write a register to stdout, absolute minimum for testing)

setattr (set/get a class attribute or "struct" member of a PMC)
getattr
call (a vtable function on a PMC, passing a varargs argument signature)

load (bytecode file)

end (halt the interpreter cleanly)

------

As a side note, if we have dynamic vtables, there's not so much reason 
to make strings a separate type from PMCs.

Can we drop the 'PMC' name and just call them objects?

One alternative to the variable number of arguments on 'call' is a 
series of 'pusharg' ops before it, but I'd rather preserve the abstraction.

The invocation of sub/method objects will happen by building up a 
callcontext object, and calling the 'invoke' vtable function on a PMC, 
passing it the call context object as an argument, and receiving the 
result context object as the return.

There is another alternative in memory allocation at this level of the 
microcode, and that is to allocate raw blocks of memory of a requested 
size, and allow direct manipulation of that memory. On the whole, this 
is one of the most error-prone aspects of C (user error, that is), and 
makes it harder to abstract away multiple garbage collection models. 
But, we may absolutely need it to implement some of the lower-level 
features.

Allison


More information about the parrot-dev mailing list