On Sat, Nov 03, 2001 at 03:53:10PM -0500, James Mastros wrote:
Hey all.
I'm having a parrot-project weekend, y'all might have noticed.
Cool. Any chance you could write some of the functions in
classes/scalarclass.c? :)
More details coming soon, once Robert and I have finished playing with
On Sat, Nov 03, 2001 at 09:00:25PM +, Simon Cozens wrote:
Cool. Any chance you could write some of the functions in
classes/scalarclass.c? :)
No. I say this because I have /no idea/ how they fit into the rest of
existance. To whit, I don't know how to access them from pasm. I'm not
On Sat, Nov 03, 2001 at 04:11:23PM -0500, James Mastros wrote:
No. I say this because I have /no idea/ how they fit into the rest of
existance. To whit, I don't know how to access them from pasm. I'm not
nearly good enough to be writing code that I can't test.
Sombody care to clue me in?
On Sat, 3 Nov 2001, Simon Cozens wrote:
On Sat, Nov 03, 2001 at 04:11:23PM -0500, James Mastros wrote:
No. I say this because I have /no idea/ how they fit into the rest of
existance. To whit, I don't know how to access them from pasm. I'm not
nearly good enough to be writing code that
On Sat, Nov 03, 2001 at 09:49:02PM +, Simon Cozens wrote:
Look at vtable.ops. However, this probably doesn't help because we don't
currently have an op that creates PMCs.
Even worse, we never seem to do anything with vtable_opinfo (etc). That's
the big reason that I started my current
On Sat, Nov 03, 2001 at 03:53:10PM -0500, James Mastros wrote:
Here's what I'm thinking: The high 16 bits (or so) of the opcode can identify
the oplib (as an index to the table of oplibs, see the next para), the rest
can identify the opcode. This shouldn't be too bad a limit: 64k opcodes
On Sat, Nov 03, 2001 at 06:00:42PM -0500, James Mastros wrote:
Right now, I'm thinking that the opcodes are going to be assigned to oplibs
linearly (eg the last opcode in core.ops is 292, so the first opcode in the
next oplib loaded will be 293).
I thought that Dan's plan was that oplibs
On Sat, 3 Nov 2001, Simon Cozens wrote:
On Sat, Nov 03, 2001 at 06:00:42PM -0500, James Mastros wrote:
Right now, I'm thinking that the opcodes are going to be assigned to oplibs
linearly (eg the last opcode in core.ops is 292, so the first opcode in the
next oplib loaded will be 293).
Brent --
How about, instead of just saying 'oplib foo' in the bytecode header, we
say 'first N opcodes of oplib foo'? After all, you generally don't have
any use for opcodes added after you assembled. :^)
I agree, although I take it further by allowing you to cherry-pick the
ops you need
On Sat, Nov 03, 2001 at 07:17:49PM -0500, Gregor N. Purdy wrote:
I've been working on this. I've added an opcode_table section that
contains (oplib, opindex) pairs (they are constant table string indexes to
allow lookup by name). The custom opcode table for the bytecode in the
packfile is
10 matches
Mail list logo
