Leopold Toetsch <[EMAIL PROTECTED]> writes:
> JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
>
> > There are still some things to do:
> > - a global hash is still not totally right. It should be moved to the
> > interpreter structure
>
> As Dan already outlined, macros should have some limited sc
On Wed, 15 Oct 2003, Jeff Clites wrote:
> My brain was in PMC == class mode when I wrote what I wrote above, but
> now I need to rethink, since that's not a given (yet?).
Not a given ever. PMCs may have a backing namespace, and that namespace
may be a HLL class, but it might not.
The terminology
Okay, it's pretty obvious I need to rethink things a bit for objects. (I'd
have responded to everyone in turn, but I lost power last night and the
mail came in this morning in odd order) I'll get back to everyone on this
later on today.
Dan
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
> The IMCC_INFO does not need to be part of the interpreter.
I don't like to have global state variables around. I don't know yet,
what happens if 2 interpreter threads both do eval()...
>> It will be repla
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > The IMCC_INFO does not need to be part of the interpreter.
>
> I don't like to have global state variables around. I don't know yet,
> what happens if 2 i
At 10:21 AM 10/16/2003 -0400, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > The IMCC_INFO does not need to be part of the interpreter.
>
> I don't like to have global state variabl
Now all run cores[2] are able to execute dynoplibs/test.pasm [1].
This is currently done for all cores except the function (slow) core by
running the wrapper__ opcode, which calls the real function in the
parrot function core.
Cores with an address table for function dispatch (CGoto, CGP) get a
Melvin Smith <[EMAIL PROTECTED]> wrote:
> I don't like the idea of IMCC becoming so tightly coupled with the
> interpreter. I still wish to be able to build it standalone. Hopefully
> we can keep this in mind going forward.
IMCC_INFO is a macro, easily changable. But building it standalone would
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
On Oct 16, 2003, at 7:21 AM, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Leopold Toetsch wrote:
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
The IMCC_INFO does not need to be part of the interpreter.
I don't like to have global state variables around. I do
On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote:
> As JIT code is unrolled, it IMHO can only call the function core (or CGP
> again) for loaded opcodes.
As is this would mean that the JIT can't JIT any opcodes that are brought
in by dynamically loaded classes, it would be pain fo
On Thu, 16 Oct 2003, Nicholas Clark wrote:
> On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote:
>
> > As JIT code is unrolled, it IMHO can only call the function core (or CGP
> > again) for loaded opcodes.
>
> As is this would mean that the JIT can't JIT any opcodes that are brought
What should this code print?
newclass P1, "Foo"
instantiate P2, P1
isa I0, P2, "Foo"
print I0
print "\n"
end
How about this?
newclass P1, "Foo"
instantiate P2, P1
isa I0, P2, "ParrotObject"
print I0
print "\n"
end
(NB Both will segfau
>From mmd.pod:
=item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
Like C, only it returns a FLOATVAL.
Wouldn't it be more sensible to call the function mmd_dispatch_floatval ?
Simon
On Thu, 16 Oct 2003, Simon Glover wrote:
>
> >From mmd.pod:
>
> =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
>
> Like C, only it returns a FLOATVAL.
>
> Wouldn't it be more sensible to call the function mmd_dispatch_floatval ?
Yep. The terminology's mixed in a number
On Thu, 16 Oct 2003, Dan Sugalski wrote:
> On Thu, 16 Oct 2003, Simon Glover wrote:
>
> >
> > >From mmd.pod:
> >
> > =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
> >
> > Like C, only it returns a FLOATVAL.
> >
> > Wouldn't it be more sensible to call the function mmd
On Oct 16, 2003, at 2:40 PM, Simon Glover wrote:
On Thu, 16 Oct 2003, Dan Sugalski wrote:
On Thu, 16 Oct 2003, Simon Glover wrote:
From mmd.pod:
=item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
Like C, only it returns a FLOATVAL.
Wouldn't it be more sensible to call th
On Thu, 16 Oct 2003, Jeff Clites wrote:
> On Oct 16, 2003, at 2:40 PM, Simon Glover wrote:
>
> > On Thu, 16 Oct 2003, Dan Sugalski wrote:
> >
> >> On Thu, 16 Oct 2003, Simon Glover wrote:
> >>
> From mmd.pod:
> >>>
> >>> =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num)
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
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote:
>> As JIT code is unrolled, it IMHO can only call the function core (or CGP
>> again) for loaded opcodes.
> As is this would mean that the JIT can't JIT any opcodes that are brought
> in b
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
Can someone explain to me the lexical pad stack and static nesting
depth?
I'm trying to write "global" for tcl, and trying to pull out a variable
from the outermost pad, and failing to find it. - I'm fairly certain
this is because I'm abusing "new_pad" and "store_lex" (always using 0
as the st
> 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
On Oct 16, 2003, at 10:53 PM, Will Coleda wrote:
I'm trying to write "global" for tcl, and trying to pull out a
variable from the outermost pad, and failing to find it.
Globals aren't stored in the lexical pads--there are find_global and
store_global ops (see var.ops)--is that what you are looki
24 matches
Mail list logo
