On Sat, 2001-11-03 at 22:11, Gregor N. Purdy wrote:
Brian --
None of these are issues with the approach I've been working on /
advocating. I'm hoping we can avoid these altogether.
I think this is a cool concept, but it seems like a lot of overhead with
the string lookups.
. These must have constant numbers that don't change over
the life of perl.
2) The core library set. These will have reserved sets of opcode numbers
and shouldn't change either. (Stuff like the socket library, for example)
We load 'em at runtime, though
3) User libraries. These we should have some
Hey all.
We're going to have to think about assigning static opcode numbers,
instead of the current order-defined. For one thing, we're looking at
perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
need to:
1) Define an ordering on things like open(i, s|sc, i|ic, i|ic
James --
We're going to have to think about assigning static opcode numbers,
instead of the current order-defined. For one thing, we're looking at
perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
need to:
1) Define an ordering on things like open(i, s|sc, i|ic
On Sat, 2001-11-03 at 21:40, Gregor N. Purdy wrote:
James --
We're going to have to think about assigning static opcode numbers,
instead of the current order-defined. For one thing, we're looking at
perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
need
Brian --
None of these are issues with the approach I've been working on /
advocating. I'm hoping we can avoid these altogether.
I think this is a cool concept, but it seems like a lot of overhead with
the string lookups.
I'm hoping we can keep the string lookups in order to
On Sat, Nov 03, 2001 at 09:40:14PM -0500, Gregor N. Purdy wrote:
Let me try to illustrate what I'm thinking a little more clearly. The
program:
.use core
set I0, 5
set I1, 37
add I2, I0, I1
print I2
print \n
end
would have an opcode_table in the packfile:
5
--- Gregor N. Purdy [EMAIL PROTECTED] wrote:
Brian --
None of these are issues with the approach I've been
working on /
advocating. I'm hoping we can avoid these altogether.
I think this is a cool concept, but it seems like a lot
of overhead with
the string lookups.
I'm
