In my ongoing quest to understand the possibilities (and possible
limitations) of parrot, here's another one. ;-)
How close a mapping can there be between regular (x86 in this example)
assembly (as generated by c-compilation) and pasm?
I can't figure out if the stack ops can approximate this kind
Sam Vilain:
# > Okay, here's another shot at the semantics for objects [for
# perl 6].
# > If folks, especially non-perl folks, would look this over and chime
# > in, I'd much appreciate it.
# > Objects have (all optional):
# > *) Properties
# > *) Methods
# > *) Attributes
#
# Add to that:
#
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
>
> Does a couroutine end? And how?
> The current implementation jumps forth and back by the B opcode,
> one is a "call coroutine" the other is a "yield". There seems to be no
> possibility, that the coroutine states, "I
Does a couroutine end? And how?
The current implementation jumps forth and back by the B opcode,
one is a "call coroutine" the other is a "yield". There seems to be no
possibility, that the coroutine states, "I'm finished now" - with
possibly meaning "don't call me again".
And from imcc's regis
At 7:36 PM -0500 3/3/03, Benjamin Goldberg wrote:
Dan Sugalski wrote:
Benjamin Goldberg wrote:
Jason Gloudon wrote:
Piers Cawley wrote:
I think you're overlooking the "restoreall" done just before
the jump-no-save-returnaddress operation... I see two "saveall"s
and two "restoreall"s.
But w
Steve Peters (via RT) wrote:
# New Ticket Created by Steve Peters
# Please include the string: [perl #21386]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21386 >
This patch fixes compilier warnings generated when compilin
Steve Peters (via RT) wrote:
# New Ticket Created by Steve Peters
# Please include the string: [perl #21389]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21389 >
This patch is to stop warnings from being generated when co
Steve Peters (via RT) wrote:
# New Ticket Created by Steve Peters
# Please include the string: [perl #21387]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21387 >
This patch is to stop compilier warnings in embed.c. The l
Steve Peters (via RT) wrote:
# New Ticket Created by Steve Peters
# Please include the string: [perl #21385]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21385 >
This patch eliminates compiler warnings generated when comp
Jason Gloudon (via RT) wrote:
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #21457]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21457 >
Here are some additional ops for the sun4 jit, a bit of
K Stol wrote:
hello,
Is it possible to have a program, which consists of multiple IMCC source files?
Not yet, directly.
As a workaround, other files can be .include-ed into main, at least from
now on, I have committed a change and a test for this.
Are there some kind of 'header'-like files?
> And attributes are essentially member variables of objects, which you
> can access as "$obj.foo". Another possible description of
> them might be
> lvalue methods which never take arguments, and which fetch and store
> class-specific pieces of data. Different classes may define their own
> pr
Hello all.
I'm here mostly as a lurker to keep up with the evolving structure of
p6, but will try to contribute something useful when I can.
Good to be aboard.
Paul
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #21457]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=21457 >
Here are some additional ops for the sun4 jit, a bit of name juggling to use
templates
Leopold Toetsch wrote:
Phil Hassey wrote:
But with a processor with > 16 registers (do such things exist?).
Parrot would be overflowing registers that it could have been using
in the JIT.
RISC processor have a lot of them. But before there are unused
processor registers, we will allocate P
hello,
Is it possible to have a program, which consists of multiple IMCC source files?
So, something like this: (pseudo code, don't know IMCC (yet))
-
/* File #1: */
...
call funcA
...
sub funcB(x)
/* do something */
end sub
...
During this change (recalculate BB and life info on the fly for spilled
regs) I encountered another problem with the INOUT ARG_DIR argument of
P-registers:
set P0, P1[2]
and similar instructions don't need, that P0 already exists at this
instruction. P0 is set to point to a PMC located in th
Allen Short <[EMAIL PROTECTED]> writes:
> > "Peter" == Peter Seibel <[EMAIL PROTECTED]> writes:
>
>
> > Hi, I'm new to this list and haven't had a chance to grovel
> > through the old archives yet so please forgive me for jumping in
> > in the middle of things.
>
> > Anyway,
Dan,
Sorry if I'm flogging a dead horse, but I just caught this call via the
summarizer.
> Okay, here's another shot at the semantics for objects [for perl 6]. If
> folks,
> especially non-perl folks, would look this over and chime in, I'd
> much appreciate it.
> Objects have (all optional):
>
Benjamin Goldberg wrote:
Erm, my statement was actually just an assumption that the first op
would be a 'saveall' -- I haven't looked at actual imcc output.
imcc does not emit any additional instructions currently. This is why I
did start this thread in the first place.
- imcc takes the code
20 matches
Mail list logo
