On Nov 8, 2004, at 11:15 AM, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully specified and implemented...
[EMAIL PROTECTED] wrote:
On Nov 8, 2004, at 11:15 AM, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully
At 12:58 AM -0800 11/9/04, Jeff Clites wrote:
On Nov 8, 2004, at 11:15 AM, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
I've already said no changes to the calling conventions, quite a
while ago. I don't see inconvenience in the register allocation code
as a reason to change it. Got a better reason?
--
Dan
Dan Sugalski [EMAIL PROTECTED] wrote:
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
... Got a better reason?
And there is of course:
4) invoke's (and friends) register usage is assymmetrical and ugly. It's
like defining:
set 5 # set I0, 5
Ad
At 7:17 PM +0100 11/8/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
... Got a better reason?
And there is of course:
4) invoke's (and friends) register usage is assymmetrical and ugly.
Dan~
On Mon, 8 Nov 2004 13:23:36 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
Neither of those are sufficient, individually or together.
It feels to me like you are dismissing Leo's
Dan Sugalski [EMAIL PROTECTED] wrote:
At 1:11 PM +0100 11/6/04, Leopold Toetsch wrote:
[calling convention change snippage]
I've already said no changes to the calling conventions, quite a
while ago.
This doesn't really change calling convention, it changes call opcodes.
It makes register
At 1:38 PM -0500 11/8/04, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:23:36 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
Neither of those are sufficient, individually or together.
It
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully specified and implemented... *then* we can consider changes.
Until then,
At 2:15 PM -0500 11/8/04, Matt Fowles wrote:
Dan~
On Mon, 8 Nov 2004 13:45:08 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
The calling conventions and code surrounding them will *not* change
now. When all the sub stuff, and the things that depend on it, are
fully specified and implemented...
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
That flaw is caused by the assymmetry of opcodes, or by indirect
register usage if opcodes like bare Cinvoke.
But as that shall not be fixed now,
At 9:39 PM +0100 11/8/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
Okay, aesthetics and making up for a flaw in the implementation of
how IMCC tracks opcodes and registers.
That flaw is caused by the assymmetry of opcodes, or by indirect
register usage if opcodes like bare
We now have dedicated PMC* pointers in the context that hold
current_cont, current_sub, and current_object. This is necessary to
create traceback information. But subroutine and return opcodes are not
adapted yet.
We have e.g.:
invoke # implicitely P0 and use P1 for return
14 matches
Mail list logo
