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
22 matches
Mail list logo
