Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Unifying the user and control stacks make sense. I don't see any
> point in unifying the pad stack with anything, since it's not really
> a stack as such, or at least ought not be, and it's got a more
> complex linking structure anyway.
Sorry for the uncl
At 11:07 AM +0100 1/13/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ stack layout ]
I'd rather not have the store statically inside the hunk:
- small objects code currently has an upper limit for sized header pools
Doesn't mean we have to use them, honestly. A separate ar
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ stack layout ]
>>I'd rather not have the store statically inside the hunk:
>>- small objects code currently has an upper limit for sized header pools
> Doesn't mean we have to use them, honestly. A separate arena for them
> is fine.
Each sized item (a B
At 5:47 PM +0100 1/12/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
struct hunk {
struct pobj header;
INTVAL used;
INTVAL avail;
Only one of these is needed (and currently used: "used")
struct hunk *upchain;
struct regframe RegisterFram
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> struct hunk {
> struct pobj header;
> INTVAL used;
> INTVAL avail;
Only one of these is needed (and currently used: "used")
> struct hunk *upchain;
> struct regframe RegisterFrame[FRAMES_PER_HUNK];
I'd rather not have t
Picking the last entry in this thread to reply to...
Here's the scoop with register stacks, stacks in general, and continuations.
The pointers to all these stack tops *should* be part of a
continuation, the same as the registers themselves should be. When a
continuation is taken, all the frames
On Jan 8, 2004, at 4:24 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
I think I'm just being dense, but looking at
include/parrot/interpreter.h it appears that they are in the context:
Sorry, yes. They are in the context but not saved. I mixed that up with
the registers themse
Jeff Clites <[EMAIL PROTECTED]> wrote:
> I think I'm just being dense, but looking at
> include/parrot/interpreter.h it appears that they are in the context:
Sorry, yes. They are in the context but not saved. I mixed that up with
the registers themselves, which went out of the context.
leo
On Jan 7, 2004, at 8:15 PM, Melvin Smith wrote:
Leopold Toetsch writes:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
> Exactly the latter:
> That was AFAIK a design decision, when Dan did introduce CPS. At
this
> time register backing stacks went
Melvin Smith <[EMAIL PROTECTED]> writes:
> At 06:37 PM 1/7/2004 -0700, Luke Palmer wrote:
>>Leopold Toetsch writes:
>> > Jeff Clites <[EMAIL PROTECTED]> wrote:
>> > > On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
>> > >> That part is already answered: create a buffer_like structure.
>> > >> *B
Melvin Smith writes:
> The downside to our implementation is in the return continuation case.
> The common case is to create the continuation that you plan to
> return with, and you already know there will be no need for
> copy-on-write in most cases because typically the execution
> path will retu
At 06:37 PM 1/7/2004 -0700, Luke Palmer wrote:
Leopold Toetsch writes:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
> >> That part is already answered: create a buffer_like structure.
> >> *But* again register backing stacks are *not* in the interp
Leopold Toetsch writes:
> Jeff Clites <[EMAIL PROTECTED]> wrote:
> > On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
> >> That part is already answered: create a buffer_like structure.
> >> *But* again register backing stacks are *not* in the interpreter
> >> context.
>
> > I don't understand w
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
>> That part is already answered: create a buffer_like structure.
>> *But* again register backing stacks are *not* in the interpreter
>> context.
> I don't understand what you are getting at. They are not p
On Jan 7, 2004, at 1:46 AM, Leopold Toetsch wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
It makes each chunk into a subclass of Buffer like so:
struct RegisterChunkBuf {
size_t used;
PObj* next;
};
That part is already answered: create a buffer_like structure.
*But* again
Luke Palmer <[EMAIL PROTECTED]> wrote:
> It makes each chunk into a subclass of Buffer like so:
> struct RegisterChunkBuf {
> size_t used;
> PObj* next;
> };
That part is already answered: create a buffer_like structure.
*But* again register backing stacks are *not* in the
On Jan 6, 2004, at 6:42 PM, Luke Palmer wrote:
Jeff Clites writes:
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
It makes each chunk into a subclass of Buffer like so:
struct RegisterChunkBuf {
size_t used;
PObj* next;
};
To do that properly, I think you need a pobj_t as the
At 04:41 PM 1/6/2004 -0700, Luke Palmer wrote:
I want these things to be garbage collected, but DOD doesn't trace the
buffer. I can't seem to find a way to mark the frames without making
the chunks into PMCs (yuck). Is there a way to do this?
I was about to answer your question when I saw your f
Jeff Clites writes:
> On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
>
> >Leopold Toetsch writes:
> >>
> >>Good. Pass it over to me :) COW copy of stacks and of other
> >>buffer-based
> >>items is still broken. These need distinct headers so that they work
> >>like COWed strings.
> >
> >Alright,
On Jan 6, 2004, at 3:41 PM, Luke Palmer wrote:
Leopold Toetsch writes:
Good. Pass it over to me :) COW copy of stacks and of other
buffer-based
items is still broken. These need distinct headers so that they work
like COWed strings.
Alright, I've got a pretty big incomplete patch here (see, when
Leopold Toetsch writes:
> Melvin Smith wrote:
>
> >At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
> >
> >>Aren't continuations supposed to close over the register stacks? In
> >>this code:
> >
> >Currently the Copy-On-Write bit isn't being honored on the register pad
> >stacks,
>
> No. Register
Melvin Smith wrote:
At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
Aren't continuations supposed to close over the register stacks? In
this code:
Currently the Copy-On-Write bit isn't being honored on the register pad
stacks,
No. Register backing stacks are no more in the interpreter context an
At 07:53 AM 1/6/2004 -0700, Luke Palmer wrote:
Aren't continuations supposed to close over the register stacks? In
this code:
I should hope to get 42, but instead I get "no more I frames to pop."
They're not very good continuations if you have to treat them just like
an address stack!
Currently th
Aren't continuations supposed to close over the register stacks? In
this code:
.sub _main
I17 = 42
savetop
newsub P0, .Continuation, second
restoretop
invoke P0
second:
restoretop
print I17
print "\n"
end
.end
I
24 matches
Mail list logo
