Dan Sugalski wrote:
At 5:34 PM +0200 10/21/04, Leopold Toetsch wrote:
The question
is: is saveall supposed to copy registers or just prepare a fresh set
of registers.
What about that?
I think the next steps are:
1) Implement the new indirect register frame
2) Note in the calling conventions
Jeff Clites wrote:
Are we still planning to move the current return continuation and
current sub, out of the registers and into their own spots in the
interpreter context
The current sub, continuation, and object already have a storage in the
context structure and are accessible via the
At 9:20 AM +0200 10/22/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 5:34 PM +0200 10/21/04, Leopold Toetsch wrote:
The question is: is saveall supposed to copy registers or just
prepare a fresh set of registers.
What about that?
Missed that, sorry. A copy.
and we see where we go from there.
Dan Sugalski [EMAIL PROTECTED] wrote:
... It *could* spill the used registers, or it could
just push the whole set onto the register stack and start fresh,
popping off the old set when the code's done.
Or probably much simpler: given a fairly big linear register frame, just
advance the base
On Oct 20, 2004, at 12:09 PM, Leopold Toetsch wrote:
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing the
registers from out of the interpreter structure, which'd leave us
needing two pointers, one for the interpreter struct and one for the
registers.
Ok,
Jeff Clites [EMAIL PROTECTED] wrote:
Just to clarify: This is the approach wherein each frame gets a fresh
set of registers, and function call and return (or continuation
invocation) copy the relevant registers between the register sets?
Yes. Function arguments and return values get copied as
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd like to
do with the interpreter, the register frame, and the register backing
stack. I'll muddle it about some and see where it goes.
JIT/i386 is up to date now that is: it doesn't do any absolute register
I almost forgot: there is Fdocs/nanoparrot.c in CVS, which shows both
the current and a possible future register layout (-DINDIRECT). You can
time the normal function calling core with the mops benchmark by
compiling it with -DMOPS.
Have fun,
leo
At 5:34 PM +0200 10/21/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd
like to do with the interpreter, the register frame, and the
register backing stack. I'll muddle it about some and see where it
goes.
JIT/i386 is up to date now
On Oct 21, 2004, at 8:34 AM, Leopold Toetsch wrote:
Dan Sugalski wrote:
In that case I won't worry about it, and I think I know what I'd like
to do with the interpreter, the register frame, and the register
backing stack. I'll muddle it about some and see where it goes.
JIT/i386 is up to date
Dan Sugalski [EMAIL PROTECTED] wrote:
The first is the CPS style chews through continuation objects at a
massive rate, and using them means that everything needs to be COW.
We don't have COWed stacks, they are all single chunk already.
A return continuation is a *potential* continuation.
At 9:16 AM +0200 10/20/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
The first is the CPS style chews through continuation objects at a
massive rate, and using them means that everything needs to be COW.
We don't have COWed stacks, they are all single chunk already.
Yeah, I
Dan Sugalski wrote:
At 9:16 AM +0200 10/20/04, Leopold Toetsch wrote:
Right. Any time an actual continuation is created we need to walk back
up the call chain and mark all the pending return continuations as
non-recyclable.
Ok.
If we're not saving much on the register stacks (and with the
At 6:13 PM +0200 10/20/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 9:16 AM +0200 10/20/04, Leopold Toetsch wrote:
Right. Any time an actual continuation is created we need to walk
back up the call chain and mark all the pending return
continuations as non-recyclable.
Ok.
If we're not
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing the
registers from out of the interpreter structure, which'd leave us
needing two pointers, one for the interpreter struct and one for the
registers.
Ok, short summary of future layout of JIT regs:
item
At 9:09 PM +0200 10/20/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
'Kay, now I'm confused. I thought we were talking about removing
the registers from out of the interpreter structure, which'd leave
us needing two pointers, one for the interpreter struct and one for
the registers.
Ok, short
Okay, since my calendar's off and it's apparently time to rehash this
*again* (I had this down for next month, but I guess it's a chaotic
cycle). Normally I'd just let it spin out, but we *do* have an issue
with sub call speeds, and I don't see how fiddling with this will do
any harm
17 matches
Mail list logo
