Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... The answer isn't to reduce the op count. The
> answer's to make the cores manageable, which doesn't require tossing
> ops out.
It seems that it was a bit unclear what my patches did. The confusion
seem to arise from the usage of the term opcode. I use
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... This patch broke a lot of my code.
All opcode permutations [1] are still valid. Can you please provide a
PASM snippet that doesn't work anymore.
[1] except abs I, N which was the only opcode with an integer result for
a float argument and lcm N,I,I w
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:02 PM +0100 11/25/04, Leopold Toetsch wrote:
>>Transcendental (and some other) ops that have a FLOATVAL out
>>argument and INTVAL source argument(s) are deprecated.
> No, dammit, they are *not* deprecated.
Ok. The word deprecated was too strong.
> L
I've moved a lot of the globals into the imc_info structure. The PASM
and PIR compilers are basically re-entrant now (there are likely some
issues with line numbers in error reports).
To achieve this a lot of functions got an interpreter argument, which
unfortunately makes the patch rather big.
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> This patch ensures that the directory exists before trying to write to it.
> (ops2c.pl already had this logic; this patch just replicates it in
> ops2pm.pl.)
Thanks, applied.
leo
# New Ticket Created by Justin DeVuyst
# Please include the string: [perl #32699]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32699 >
This patch will allow all the *.imc and *.pasm benchmarks to be
tested by running
while you weren't looking, Matt Fowles wrote:
>Lexicals, Continuations, Register Allocation, and ascii art
> This thread (and the ones that preceded it) have made me wish that gmail
> and google groups had a fixed width font option. Sadly, this summary
> will probably not get me it
Peter Sinnott <[EMAIL PROTECTED]> wrote:
> eval_4.pasm seems to be falling over on redhat as 3 when running
> with jit.
Fixed.
leo
At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
I just thought of a heuristic that might help with register
preservation:
A variable/register should be preserved over a function call if either of the
following is true:
1. The variable is referred to ag
At 2:51 PM +0100 11/29/04, Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
It seems to me that there is no good solution to this problem without
annotating the register set or killing the register allocator.
I think I've proposed a reasonable solution: putting lexicals in
registers.
Dan Sugalski wrote:
Right, so with at least a basic rework of the string stuff in, it's time
to turn our attention to objects and all the stuff that goes with them.
I'd originally thought that the bits we'd put in place would be
sufficient to do everyone's object system (well, all the languages
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 4) A scheme for calling functions.
> a) we need a class for a namespace, e.g. the interpreter (Python might
>have a "math" object for the call below:)
>$P0 = getinterp
> b) we do a method call
>$N0 = $P0."sin"(3.14)
> c) add a method to
Dan~
On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
>
>
> >On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
> >
> >>I just thought of a heuristic that might help with register
> >>preservation:
> >>
> >>A variable/regi
At 11:48 AM +0100 11/24/04, Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
Should there be one for invoking a sub out of a namespace, say:
.namespace [ "Baz" ]
.sub quux
[ "Foo", "bar" ]()
Looks a bit strange.
I think for this being explicit is fine:
$P1 = g
At 9:36 AM -0500 11/30/04, Matt Fowles wrote:
Dan~
On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
>On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
>
>>I just thought of a heuristic that might help with register
>>prese
Dan~
On Tue, 30 Nov 2004 09:49:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:36 AM -0500 11/30/04, Matt Fowles wrote:
>
>
> >Dan~
> >
> >
> >On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
> >>
> >>
> >>
At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown that we obviously can't handle all
the side effects of continuations correctly. Reusing preserved
(non-vol
Dan~
On Tue, 30 Nov 2004 10:22:29 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
>
>
> >Below inline/attached are some thoughts WRT the subject.
> >
> >leo
> >
> >
> >Lexicals, continuations, and register allocation
> >
> >1) Recent discussion
At 10:10 AM -0500 11/30/04, Matt Fowles wrote:
Dan~
On Tue, 30 Nov 2004 09:49:54 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:36 AM -0500 11/30/04, Matt Fowles wrote:
>Dan~
>
>
>On Tue, 30 Nov 2004 08:28:35 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> At 1:45 AM -0800 11/29/04, J
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Dan Sugalski wrote:
[ method lookup ]
> Parrot_CompositeObject_find_method should do that. object.c should not.
I think, when going down the class hierarchy, we just have to call
class->vtable->find_method() again, istead of the Parrot_find_global.
> And,
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
>>Below inline/attached are some thoughts WRT the subject.
>>
>>leo
>>
>>
>>Lexicals, continuations, and register allocation
>>
>>1) Recent discussions have shown that we obviously can't handle all
>>the sid
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Dan Sugalski wrote:
[ method lookup ]
Parrot_CompositeObject_find_method should do that. object.c should not.
I think, when going down the class hierarchy, we just have to call
class->vtable->find_method() again, istead of the Parrot_find_
Leo~
On Tue, 30 Nov 2004 17:30:43 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
> >>Below inline/attached are some thoughts WRT the subject.
> >>
> >>leo
> >>
> >>
> >>Lexicals, continuations
At 5:30 PM +0100 11/30/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote:
Below inline/attached are some thoughts WRT the subject.
leo
Lexicals, continuations, and register allocation
1) Recent discussions have shown that we obvious
[Snip]
This is interesting. After we're functionally complete we can revisit it.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bea
On Nov 30, 2004, at 5:28 AM, Dan Sugalski wrote:
At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
I just thought of a heuristic that might help with register
preservation:
A variable/register should be preserved over a function call if
either of the
fo
At Tue 30 Nov 6:22pm, Dan Sugalski wrote:
> Architecture changes aren't an option we're entertaining until after we're
> functionally complete.
Just would like to ask a related question:
Is a change that invalidates an existing precompiled bytecode but not
the source code of it
considered as an ar
At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
On Nov 30, 2004, at 5:28 AM, Dan Sugalski wrote:
At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
I just thought of a heuristic that might help with register
preservation:
A variable/register should be pres
At 7:20 PM +0100 11/30/04, Thomas Seiler wrote:
At Tue 30 Nov 6:22pm, Dan Sugalski wrote:
Architecture changes aren't an option we're entertaining until after we're
functionally complete.
Just would like to ask a related question:
Is a change that invalidates an existing precompiled bytecode but
Jeff~
On Tue, 30 Nov 2004 10:15:00 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
>
>
>
> On Nov 30, 2004, at 5:28 AM, Dan Sugalski wrote:
>
> > At 1:45 AM -0800 11/29/04, Jeff Clites wrote:
> >> On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
> >>
> >>> I just thought of a heuristic that mig
On Nov 30, 2004, at 10:27 AM, Dan Sugalski wrote:
At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
Oh. No, it won't. We've declared that return continuations will always
leave the top half registers in the state they were when the return
continuation was taken. In this case, when it's taken to pas
Jeff~
On Tue, 30 Nov 2004 11:20:50 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 30, 2004, at 10:27 AM, Dan Sugalski wrote:
>
>
>
> > At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
>
> > Oh. No, it won't. We've declared that return continuations will always
> > leave the top half regi
At 11:20 AM -0800 11/30/04, Jeff Clites wrote:
On Nov 30, 2004, at 10:27 AM, Dan Sugalski wrote:
At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
None of this should have anything to do with return continuations
specifically, since this is the case where the body of foo (or
something called from i
I have the impression that there has been some confusion about the term
"opcode"
There are IHMO two things that qualify for beeing an "opcode":
* Mnemonics: These are Strings that help humans to write in assembly,
i.e. ' ADD' in PASM.
* Instructions: These are words of bits that are executed by
Sam Ruby wrote:
All objects also must be able to perform the method:
get_anonymous_subclass - to put the object into a singleton
anonymous
subclass
Sorry, you lost me here.
A singleton object is the sole instantiation of a class. You'll always
get that one object.
Python provides the ability for any function to be called with either
positional or keyword [1] arguments. Here is a particularly brutal example:
args={'a':1,'b':2,'c':3}
def f(a,b,c): return (a,b,c)
def g(b,c,a): return (a,b,c)
for j in [f,g]: print j(1,2,3)
for j in [f,g]:
On Tue, 30 Nov 2004 14:45:39 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:20 AM -0800 11/30/04, Jeff Clites wrote:
> >% cat continuation6.ruby
> >def strange
> > callcc {|continuation| $saved = continuation}
> >end
> >
> >def outer
> > a = 0
> > strange()
> > a = a + 1
> >
The FAQ mentions that the JVM and CLR (.Net VM) are not suited to
dynamic languages. I was wondering why this is the case.
Also could the Parrot VM be used effectively with strong typing
languages. I would like to at some stage try to implement a proof of
concept of a language that has strong t
38 matches
Mail list logo
