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
near
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 cod
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 pr
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 *w
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 29
James Mastros:
# 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 to
James --
> I'm having a parrot-project weekend, y'all might have noticed. Right now,
> I'm thinking of multiple oplibs, specificly how to get the bytecode/packfile
> to express it.
I've been working on this. I've added an opcode_table section that
contains (oplib, opindex) pairs (they are con
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 nee
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
12 matches
Mail list logo
