Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>> We should keep the fingerprinting, since we can still have an issue where
>> new bytecode can't run on old interpreters, but it's probably time to take
>> another look at how we set the fingerprint.
> If we
Dan Sugalski <[EMAIL PROTECTED]> writes:
> On Fri, 17 Oct 2003, Leopold Toetsch wrote:
>
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > Put them *back*, please, unless you're going to fix core.pm.
> >
> > Done. op2pm.pl now has the renumbering. Its simpler and cleaner.
> >
> > Now, that 12
On Fri, 17 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Put them *back*, please, unless you're going to fix core.pm.
>
> Done. op2pm.pl now has the renumbering. Its simpler and cleaner.
>
> Now, that 1237 opcodes are fixed numbered, shall we remove the
> finger-
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Put them *back*, please, unless you're going to fix core.pm.
Done. op2pm.pl now has the renumbering. Its simpler and cleaner.
Now, that 1237 opcodes are fixed numbered, shall we remove the
finger-printing? Currently we just don't read PBCs, when the
fing
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
>
> > Have a small number of _real_ core.ops which have fixed assigned
> > numbers below say 256.
>
> The problem with this approach is the JIT/EXEC subsystem. Dynamically
> loaded oplibs and JIT don't play
At 02:49 PM 10/17/2003 +0200, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> I've asked this before: Please, someone give me an example
> where a dynamic opcode lib gives us something
> that a well designed set of core ops and an extension
> interface does not.
Can you explain th
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Fri, 17 Oct 2003, Leopold Toetsch wrote:
>> *If* we renumber opcodes, then lib/Parrot/OpLib/core.pm should be sorted.
>> This file is the base (and holds the numbering) of all utilities using
>> ops. When this file is ordered to our needs, *no* other ch
On Fri, 17 Oct 2003, Leopold Toetsch wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
>
> > Have a small number of _real_ core.ops which have fixed assigned
> > numbers below say 256.
>
> The problem with this approach is the JIT/EXEC subsystem. Dynamically
> loaded oplibs and JIT don't play t
Melvin Smith <[EMAIL PROTECTED]> wrote:
> I've asked this before: Please, someone give me an example
> where a dynamic opcode lib gives us something
> that a well designed set of core ops and an extension
> interface does not.
Can you explain the difference? Dynamic opcode libraries are extension
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Have a small number of _real_ core.ops which have fixed assigned
> numbers below say 256.
The problem with this approach is the JIT/EXEC subsystem. Dynamically
loaded oplibs and JIT don't play together. To make this work, it would
need probably a tota
On Fri, 17 Oct 2003, Melvin Smith wrote:
> At 08:55 AM 10/17/2003 -0400, Dan Sugalski wrote:
> >On Fri, 17 Oct 2003, Juergen Boemmels wrote:
> >
> > > Why not this way:
> > >
> > > Have a small number of _real_ core.ops which have fixed assigned
> > > numbers below say 256. This ops never change d
On Fri, 17 Oct 2003, Melvin Smith wrote:
> At 12:53 PM 10/17/2003 +0200, Juergen Boemmels wrote:
> >Robert Spier <[EMAIL PROTECTED]> writes:
> >
> > > > The goals are to assign permanent numbers to the opcodes. What the
> > > > numbers are is generally irrelevant, but they must be constant across
At 08:55 AM 10/17/2003 -0400, Dan Sugalski wrote:
On Fri, 17 Oct 2003, Juergen Boemmels wrote:
> Why not this way:
>
> Have a small number of _real_ core.ops which have fixed assigned
> numbers below say 256. This ops never change during the lifetime of
> parrot. All other libs are inited (not nec
On Fri, 17 Oct 2003, Juergen Boemmels wrote:
> Why not this way:
>
> Have a small number of _real_ core.ops which have fixed assigned
> numbers below say 256. This ops never change during the lifetime of
> parrot. All other libs are inited (not necessary loaded) at byte-code
> loadtime. The byteco
On Fri, 17 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote:
> >>
> >>I don't know yet, what are the goals of this patch. There is not any
> >>sign in the list, that ops should be numbered like that and so on ...
>
> >
On Thu, 16 Oct 2003, Robert Spier wrote:
> > The goals are to assign permanent numbers to the opcodes. What the
> > numbers are is generally irrelevant, but they must be constant across
> > all systems for the lifetime of parrot.
>
> At first glance, gut reaction, that seems "really hard"(tm) and
At 12:53 PM 10/17/2003 +0200, Juergen Boemmels wrote:
Robert Spier <[EMAIL PROTECTED]> writes:
> > The goals are to assign permanent numbers to the opcodes. What the
> > numbers are is generally irrelevant, but they must be constant across
> > all systems for the lifetime of parrot.
>
> At first g
Robert Spier <[EMAIL PROTECTED]> writes:
> > The goals are to assign permanent numbers to the opcodes. What the
> > numbers are is generally irrelevant, but they must be constant across
> > all systems for the lifetime of parrot.
>
> At first glance, gut reaction, that seems "really hard"(tm) a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote:
>>
>>I don't know yet, what are the goals of this patch. There is not any
>>sign in the list, that ops should be numbered like that and so on ...
> The goals are to assign permanent numbers to the opcodes.
> The goals are to assign permanent numbers to the opcodes. What the
> numbers are is generally irrelevant, but they must be constant across
> all systems for the lifetime of parrot.
At first glance, gut reaction, that seems "really hard"(tm) and
"really limiting"(tm)...
since there's going to
At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Folks,
I've added in the infrastructure needed to implement fixed opcode numbers.
There's now a file ops.num that holds the opcode name/number pairs for all
ops with a fixed number.
I don't know yet, what
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Folks,
> I've added in the infrastructure needed to implement fixed opcode numbers.
> There's now a file ops.num that holds the opcode name/number pairs for all
> ops with a fixed number.
I don't know yet, what are the goals of this patch. There is not an
Folks,
I've added in the infrastructure needed to implement fixed opcode numbers.
There's now a file ops.num that holds the opcode name/number pairs for all
ops with a fixed number. Right now it's only got two entries (one of which
really ought to be redone) but I'd like to get all the extant stan
23 matches
Mail list logo
