20 opcodes

Christoph Otto (Excell Data Corporation) a-chotto at microsoft.com
Thu Jul 8 21:15:11 UTC 2010


> -----Original Message-----
> From: parrot-dev-bounces at lists.parrot.org [mailto:parrot-dev-
> bounces at lists.parrot.org] On Behalf Of Allison Randal
> Sent: Thursday, July 08, 2010 12:11
> To: parrot-dev at lists.parrot.org
> Subject: 20 opcodes
> 
> 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)

So would keyed access be a form of set that uses 3 args?

> 
> goto LABEL
> if BOOL, LABEL
> iseq
> isgt
> islt

What's the purpose of having both of these?  Writing one in terms of the 
other is trivial, especially from the pov of the assembler.

> and
> or

No "not"?

> 
> 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)

How would calls into external (or internal, especially while we're 
bootstrapping Lorito) C-level functions work?

> 
> load (bytecode file)

Would the same op be used for Parrot bytecode and shared libraries?

> 
> 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.

I don't see how that can be avoided.  If we need Lorito to do whatever C 
can do, we'll need to let code mess with memory.  We can cut down on bugs by 
having optional range checking on direct memory access similar to the 
(non-optional) range checking in ByteBuffer.  Allocation could go through 
the GC by default and could reach down into libc's malloc/free if needed.

> 
> Allison
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev



More information about the parrot-dev mailing list