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
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 unclear
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
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
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 the store
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
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.
*But* again register
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 out of
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 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
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 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
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 physically
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 what you are
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 interpreter
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 return
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
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 the
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
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 backing stacks are
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
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, I've got a pretty big
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
23 matches
Mail list logo
