> -----Original Message----- > From: [email protected] [mailto:parrot-dev- > [email protected]] On Behalf Of Allison Randal > Sent: Thursday, July 08, 2010 12:11 > To: [email protected] > 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
