The basic status is that lots of people, many of them coincidentally
named Leopold Toetsch, have been fixing zillions of things and
implementing a number of new features. Nearly everything needed for
0.0.9 has happened, and a lot else besides.
I personally have been busy with my day job, shipping
On Nov-15, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >I replied to ticket #16941 a while back but I don't think I had RT
> >actually send any mail to anybody. Anyone have an opinion on the patch
> >I put in it? (I'm trying to clean out some local changes so I can
> >apply other people's patch
At 4:47 PM -0800 11/18/02, kj wrote:
Hello Jonathan,
I just dropped my shell resources back down (datasize 6144k,
stacksize 512k) and the tests pass for the version compiled with the
gcc-3.1-based compiler. Looks like we found our culprit, at least
for Darwin 5.5.
I wonder which version
Hello again,
I tried upping the datasize to 80 meg and stacksize to 8 meg in my
shell, and compiled with gcc3:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1041, based on gcc version 3.1 20020105
(experimental)
Parrot built c
Hello Jonathan,
I just dropped my shell resources back down (datasize 6144k, stacksize
512k) and the tests pass for the version compiled with the gcc-3.1-based
compiler. Looks like we found our culprit, at least for Darwin 5.5.
I wonder which version of the compiler is on glastig? Having
If memory serves me right, Leopold Toetsch wrote:
>
> > Hmm... I guess I can only quote the ECMA spec here ...
> > conv.i1 Convert to int8, pushing int32 on stack
>
>
> truncate to [-128..127]? And why the push?
IL is a fully stack language ... pop int32, trunc, push int8 ...
Yes,
Leopold Toetsch wrote:
> > If memory serves me right, Leopold Toetsch wrote:
>
>^^^...
>
> Your mailer should know ;-)
That's his mailer talking. It always does that. :-)
> > Hmm... I guess I can only quote the ECMA spec here ...
> > conv.i1 Convert to int8, pushing int32 on
On Mon, 18 Nov 2002, Iacob Alin wrote:
> > Hmm... I guess I can only quote the ECMA spec here ...
> > conv.i1 Convert to int8, pushing int32 on stack
> > conv.i2 Convert to int16, pushing int32 on stack
[etc.]
> This might be a stupid question, but are this datatypes going to be PMCs?
It's a ve
Iacob Alin wrote:
This might be a stupid question, but are this datatypes going to be PMCs?
Only types bigger then our current native types:
INTVAL typically 32 bit long on 32 bit machines
FLOTVAL typically double
Alin
leo
Gopal V wrote:
If memory serves me right, Leopold Toetsch wrote:
^^^...
Your mailer should know ;-)
Hmm... I guess I can only quote the ECMA spec here ...
conv.i1 Convert to int8, pushing int32 on stack
truncate to [-128..127]? And why the push?
What is the behaviour on overflow?
co
Gopal V said:
> If memory serves me right, Leopold Toetsch wrote:
>
> > Please have a look at include/parrot/datatypes.h. I hope that there are
> > all types you'll need.
>
> It seems so ... but I'm not really certain about Float data types ...
>
> > Can you specify, what opcodes you would need?
>
> -Original Message-
> From: kj [mailto:[EMAIL PROTECTED]]
>
> I'm getting mixed results building from this morning's CVS -- on
> Linux/x86 I only get the t/op.lexicals.t failures, but on Darwin/PPC I'm
> also getting failures in t/pmc/scratchpad.t. Would your patch have
> anything to do
If memory serves me right, Leopold Toetsch wrote:
> Please have a look at include/parrot/datatypes.h. I hope that there are
> all types you'll need.
It seems so ... but I'm not really certain about Float data types ...
> Can you specify, what opcodes you would need?
Hmm... I guess I can only q
Rhys Weatherley wrote:
I've been working on some other stuff lately, so this is the
first opportunity I've had to catch up on Parrot.
I'm interested in the current status of the following within
Parrot:
- object/class support
- fixed-sized integers and/or conversion opcodes
- embedding
I've been working on some other stuff lately, so this is the
first opportunity I've had to catch up on Parrot.
I'm interested in the current status of the following within
Parrot:
- object/class support
- fixed-sized integers and/or conversion opcodes
- embedding of binary extension sect
Simon Glover (via RT) wrote:
# New Ticket Created by Simon Glover
# Please include the string: [perl #18445]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18445 >
Applied, thanks
leo
The biggest problem currently seems to be string_to_cstring. Some time
ago, I made a change, that the returned cstr has the
BUFFER_immobile_FLAG set, which should be the Right Thing(tm), *but* -
though immobile strings don't move - the memory_pool, where these
strings live, get freed at the end
JIT has big improvement in integer related programs but did lack to
improve real world i.e. PMC using apps.
I wanted to test, how much we can gain, by doing vtable calls directly
in JIT and did optimize 4 ops (dec_p, inc_p, if_p_ic, unless_p_ic)
(which happen to be used in mops_p.pasm's MOPS lo
18 matches
Mail list logo
