Hi, Ian...
After studying your design suggestions and experimenting for the past
couple of weeks, I suggest the following changes to the method ABI:
1) Pepsi Methods begin with:
oop method(struct __frame *_frame, oop v_self /* ARG... */)
{
# define v_frame ((oop)&_frame->_self)
[...]
}
Jolt methods would become:
(method (formals...) body...) =>
(lambda (_frame self formals...)
(let (frame (+ _frame 4))
body...))
2) "v_frame" is thus a proper object:
struct __frame
{
oop _vtable;
oop _self; /* v_frame begins here */
oop other_members[0];
};
3) The reason for the explicit _self member and struct is to allow us
to change the preamble to C code snippets to read as follows without
losing much efficiency (one indirection per member variable
reference):
{
# define self ((struct t_DataType *)_frame->_self)
[...]
# undef self
}
4) The compiler idiom:
v_self = v_stateful_self = ...;
becomes:
v_self = (oop)self = ...;
5) Message sends each need to construct a frame struct:
struct __frame _f = {_frame_vtable, (RCV)};
struct __closure *_c= _libid_bind((MSG), _f._self);
(_c->method)(&_f, _f._self /* ARG... */);
6) Message sends are free to construct a frame with a different vtable
and more members to implement #argc, #_closure, or whatever other data
a callee might want.
Please let me know what you think of this new plan. I think it gives
the most flexibility at a low cost. I've chosen the data types and
variable names to flush out any abuses of v_stateful_self versus
v_self.
As for your suggestion to put some information in a register
somewhere, I think that the stack is a good compromise between
efficiency, safety, and portability. It might be a good future
optimisation, but that's platform-specific and I don't want to get
ahead of myself.
--
Michael FIG <[EMAIL PROTECTED]> //\
http://michael.fig.org/ \//
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
