On Mon, 24 Sep 2001, Uri Guttman wrote:
> > "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>
> AB> If you are interested, I'll try to get a copy of the paper to you.
> AB> It has some interesting ideas. By having 'arenas' for each object
> AB> type, you can remove a large part of th
At 10:46 AM 9/24/2001 -0400, Michael Maraist wrote:
>Why aren't we just using the perl5 memory manager?
Because it's not what I ultimately want, or what Parrot ultimately needs.
That and it would've been more work than it was worth when Parrot was first
set up. (We don't *do* much, so I didn't
> DS> At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>
> >> >Horribly wasteful of memory, definitely, and the final allocation system
> >> >will do things better, but this is OK to start.
> >>
> >> So to stop it waste memory, subtract 1 first and add it again later.
>
> DS> Nah, it'll
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>> >Horribly wasteful of memory, definitely, and the final allocation system
>> >will do things better, but this is OK to start.
>>
>> So to stop it waste memory, subtract 1 firs
At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>[I'm behind on my mail :-)]
>
>On Wed, 12 Sep 2001 13:19:40 -0400, Dan Sugalski wrote:
>
> >We're trying to align to a power-of-two boundary, and mask is set to
> >chop off the low bits, not the high ones. It should be something like:
> >
> >11
[I'm behind on my mail :-)]
On Wed, 12 Sep 2001 13:19:40 -0400, Dan Sugalski wrote:
>We're trying to align to a power-of-two boundary, and mask is set to
>chop off the low bits, not the high ones. It should be something like:
>
>
>
>The calc:
>
> mem & mask + (~mask + 1)
>
Yep, you were right...I made a patch for you and applied it :)
Thanks!
Tanton
Philip Kendall wrote:
* The trickier one: with the above two changes, test and test2 work,
but test3 tries to pop a non-existent stack frame. In Parrot_pop_i,
should the fragment:
if (chunk_base->prev) {
l'; [EMAIL PROTECTED]
>Sent: 9/12/2001 12:19 PM
>Subject: RE: Parrot coredumps on Solaris 8
>
>At 09:57 AM 9/12/2001 -0700, Hong Zhang wrote:
> > > Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> > > read_constants_table on my Alpha. P
I'm trying to understand the memory allocation logic and failing
miserably.
Thanks!
Tanton
-Original Message-
From: Dan Sugalski
To: Hong Zhang; 'Philip Kendall'; [EMAIL PROTECTED]
Sent: 9/12/2001 12:19 PM
Subject: RE: Parrot coredumps on Solaris 8
At 09:57 AM 9/12/2001 -0
At 10:17 PM 9/12/2001 +0100, Philip Kendall wrote:
>On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote:
>
>[Coredumps on Alpha]
>
> > Quick research reveals the obvious problem: even when IVs are 64 bit,
> > assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
> > Ch
On Wed, Sep 12, 2001 at 07:21:06PM +0100, Philip Kendall wrote:
[Coredumps on Alpha]
> Quick research reveals the obvious problem: even when IVs are 64 bit,
> assemble.pl is still 32 bit (as $pack_types{i} is the 32-bit type 'l').
> Changing this over to 'q' means I get further, but it's still
>
On Wed, Sep 12, 2001 at 02:54:49PM +0100, Philip Kendall wrote:
> On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote:
> > At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
> > >
> > >Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> > >read_constants_table on my Alph
At 09:57 AM 9/12/2001 -0700, Hong Zhang wrote:
> > Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> > read_constants_table on my Alpha. Problems with the integer-pointer
> > conversions in memory.c? (line 29 is giving me a warning).
>
>The line 29 is extremely wrong. It assign
> Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> read_constants_table on my Alpha. Problems with the integer-pointer
> conversions in memory.c? (line 29 is giving me a warning).
The line 29 is extremely wrong. It assigns IV to void* without casting.
The alignment calculatio
On Wed, Sep 12, 2001 at 09:45:42AM -0400, Dan Sugalski wrote:
> At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
> >On Wed, Sep 12, 2001 at 09:24:06AM -0400, Dan Sugalski wrote:
> > >
> > > CHUNK_BASE was OK, it was Allocate_Aligned that was broken. That and the
> > > problems with the assembler
At 02:40 PM 9/12/2001 +0100, Philip Kendall wrote:
>On Wed, Sep 12, 2001 at 09:24:06AM -0400, Dan Sugalski wrote:
> > At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote:
> > >On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
> > > > test3.pbc is still segfaulting on me though.
> > >
> >
On Wed, Sep 12, 2001 at 09:24:06AM -0400, Dan Sugalski wrote:
> At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote:
> >On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
> > > test3.pbc is still segfaulting on me though.
> >
> >Yes, it is here too; I've sent some debugging info to Dan
>
At 12:18 PM 9/12/2001 +0100, Simon Cozens wrote:
>On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
> > test3.pbc is still segfaulting on me though.
>
>Yes, it is here too; I've sent some debugging info to Dan
>and he's having a look at it. I'm trying to take a look at
>it too. I sus
On Wed 12 Sep 2001 13:23, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Can we usefully smoke parrots yet?
> Or is this something that someone (Schwern?) is working on?
>
> [in that as all the world is not a vax^Wx86 it would be useful to smoke on
> "obscure" architectures that SIGBUS on unaligned
On Wed, Sep 12, 2001 at 12:11:35PM +0100, Philip Kendall wrote:
> test3.pbc is still segfaulting on me though.
Yes, it is here too; I've sent some debugging info to Dan
and he's having a look at it. I'm trying to take a look at
it too. I suspect that CHUNK_BASE isn't doing what it should.
Simon
On Tue, Sep 11, 2001 at 10:23:51AM -0700, Daniel Sully wrote:
[Parrot coredumps on Solaris]
> It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is
> fine. The coredump doesn't show much, only that it keeled over at
> interpreter.c line 16, which is the while() loop.
That was
It also coredumps on Solaris 7, when running the test2.pbc - test.pbc is
fine. The coredump doesn't show much, only that it keeled over at
interpreter.c line 16, which is the while() loop.
Once upon a time Philip Kendall shaped the electrons to say...
>
>
> Hi.
>
> I've just tried getting Pa
Hi.
I've just tried getting Parrot running on a Solaris 8 box here, but it's
coredumping on me with test2.pasm and test3.pasm:
cass87:pak:~/data2/parrot$ ./test_prog test.pbc
I reg 1 is 1000206849
I reg 5 is 1000206859
I reg 2 is 1000
I reg 2 is 10
I reg 4 is 3000
N reg 1 is 3000.
23 matches
Mail list logo