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