Re: Curses Life
Dan Sugalski [EMAIL PROTECTED] writes: At 4:45 PM + 12/5/02, Leon Brocard wrote: Leon Brocard sent the following bits through the ether: Now to get the hand of the signatures... Ah, well, I gave up on SDL as it was a little complicated. Instead, I played with curses. Please find attached a cute little curses life program loading and calling curses at runtime with dlfunc. Oh, and I made the shape a small spaceship as it's more interesting. Leon, you're really scary, y'know that? :) [It's a bit of the pain the way it stomps over registers all the time, though ;-] There are ways to get around that, and there are some inefficiencies in the implementation there. I think we can work around some of those--I am rather tempted to have invoke promise not to alter non-parameter registers or something so you don't have to pushall every time you make a call to what could be assumed to be an atomic and non-parrot function. Doesn't that rather invalidate the whole 'caller saves' principle?
Re: Curses Life
Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: There are ways to get around that, and there are some inefficiencies in the implementation there. I think we can work around some of those--I am rather tempted to have invoke promise not to alter non-parameter registers or something so you don't have to pushall every time you make a call to what could be assumed to be an atomic and non-parrot function. Doesn't that rather invalidate the whole 'caller saves' principle? The 'caller save' principle is IMHO subotimal. The caller doesn't know, how a sub is implemented, so has always to save everything. When the called sub is responsible for preserving the environment, only a minimal set of needed registers can be saved in the sub. I would vote for above non-parameter registers are preserved. BTW imcc needs some extensions: - subroutine return values in registers are OUT params WRT the invoke call, which imcc isn't aware of - popX/clearX/restoreall do change registers, though this isn't flagged in the opcode. imcc assumes, that all registers are preserved over function calls. leo
Re: Curses Life
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: There are ways to get around that, and there are some inefficiencies in the implementation there. I think we can work around some of those--I am rather tempted to have invoke promise not to alter non-parameter registers or something so you don't have to pushall every time you make a call to what could be assumed to be an atomic and non-parrot function. Doesn't that rather invalidate the whole 'caller saves' principle? The 'caller save' principle is IMHO subotimal. The caller doesn't know, how a sub is implemented, so has always to save everything. When the called sub is responsible for preserving the environment, only a minimal set of needed registers can be saved in the sub. Whichever style you choose will be suboptimal. However, if you move to callee saves you lose the possibility of adding tail call optimization at a later date, and some subs will end up saving registers that don't need saving. (I also wonder how continuations are going to work with callee saves since the continuation needs to get the register set back into a sane state and it gets created at call time.) I coness I'm somewhat bemused to see any sub doing 'save all', a given sub knows which registers it uses, and they are the only ones that it needs to save (because it's callers have already saved anything that's important to them). I would vote for above non-parameter registers are preserved. BTW imcc needs some extensions: - subroutine return values in registers are OUT params WRT the invoke call, which imcc isn't aware of - popX/clearX/restoreall do change registers, though this isn't flagged in the opcode. imcc assumes, that all registers are preserved over function calls. Looks like IMCC needs fixing.
Re: Curses Life
At 7:12 AM + 12/16/02, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 4:45 PM + 12/5/02, Leon Brocard wrote: Leon Brocard sent the following bits through the ether: Now to get the hand of the signatures... Ah, well, I gave up on SDL as it was a little complicated. Instead, I played with curses. Please find attached a cute little curses life program loading and calling curses at runtime with dlfunc. Oh, and I made the shape a small spaceship as it's more interesting. Leon, you're really scary, y'know that? :) [It's a bit of the pain the way it stomps over registers all the time, though ;-] There are ways to get around that, and there are some inefficiencies in the implementation there. I think we can work around some of those--I am rather tempted to have invoke promise not to alter non-parameter registers or something so you don't have to pushall every time you make a call to what could be assumed to be an atomic and non-parrot function. Doesn't that rather invalidate the whole 'caller saves' principle? Nope. There's nothing wrong with having a set of more stringent rules. Since invoke is for C functions that we know are C functions and thus we can't tail-call into them (and they aren't likely to use any parrot registers) it seems a reasonable optimization. I think the general rule is When you cross an interpreter/C boundary, you must assume the caller has no clue what you might do and you must be careful or something like that. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Curses Life
On Tue, Dec 10, 2002 at 06:04:44PM +, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: At 4:45 PM + 12/5/02, Leon Brocard wrote: Leon Brocard sent the following bits through the ether: Ah, well, I gave up on SDL as it was a little complicated. Instead, I played with curses. Please find attached a cute little curses life program loading and calling curses at runtime with dlfunc. Oh, and I made the shape a small spaceship as it's more interesting. Leon, you're really scary, y'know that? :) I've suggested he work on getting Readline working next. Then, once he's done the zmachine loader and got a zmachine opcode set up and running... and then all get digressed into playing http://astray.com/Bookshop.z5 (see http://london.pm.org/pipermail/london.pm/Week-of-Mon-20010924/005441.html ) Nicholas Clark
Re: Curses Life
Dan Sugalski [EMAIL PROTECTED] writes: At 4:45 PM + 12/5/02, Leon Brocard wrote: Leon Brocard sent the following bits through the ether: Now to get the hand of the signatures... Ah, well, I gave up on SDL as it was a little complicated. Instead, I played with curses. Please find attached a cute little curses life program loading and calling curses at runtime with dlfunc. Oh, and I made the shape a small spaceship as it's more interesting. Leon, you're really scary, y'know that? :) I've suggested he work on getting Readline working next. Then, once he's done the zmachine loader and got a zmachine opcode set up and running... -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Curses Life
At 4:45 PM + 12/5/02, Leon Brocard wrote: Leon Brocard sent the following bits through the ether: Now to get the hand of the signatures... Ah, well, I gave up on SDL as it was a little complicated. Instead, I played with curses. Please find attached a cute little curses life program loading and calling curses at runtime with dlfunc. Oh, and I made the shape a small spaceship as it's more interesting. Leon, you're really scary, y'know that? :) [It's a bit of the pain the way it stomps over registers all the time, though ;-] There are ways to get around that, and there are some inefficiencies in the implementation there. I think we can work around some of those--I am rather tempted to have invoke promise not to alter non-parameter registers or something so you don't have to pushall every time you make a call to what could be assumed to be an atomic and non-parrot function. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
