At 10:24 PM +0200 3/29/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 8:16 PM +0200 3/29/04, Leopold Toetsch wrote:
Did you consider ussng PMCs as instead of plain function pointers.
As outlined a NCI, C, and PASM Sub PMC would be equally just
invoke()d.
Yeah, I did. You end up with a twofo
At 10:28 PM +0200 3/29/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
[ cvs ci library/vtable_constants.pasm ]
Isn't working IMHO. C<.const int ..> is PIR syntax. *And* that file
could be easily auto-created like almost all inside
F
Ah, damn, that's what I get for not double-checking my working
Dan Sugalski wrote:
[ cvs ci library/vtable_constants.pasm ]
Isn't working IMHO. C<.const int ..> is PIR syntax. *And* that file
could be easily auto-created like almost all inside
F
leo
Dan Sugalski wrote:
At 8:16 PM +0200 3/29/04, Leopold Toetsch wrote:
Did you consider ussng PMCs as instead of plain function pointers. As
outlined a NCI, C, and PASM Sub PMC would be equally just invoke()d.
Yeah, I did. You end up with a twofold problem there--not only do you
have extra indir
At 9:40 PM +0200 3/29/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
You've got me confused here.
Well, the question is: Is it allowed to create a continuation in one
subroutine with the destination label being in a different
subroutine?
Oh, OK.
Erm. No. Mostly.
Subs must be considered self-co
Dan Sugalski wrote:
You've got me confused here.
Well, the question is: Is it allowed to create a continuation in one
subroutine with the destination label being in a different subroutine?
.sub _f1
label = get_addr dest_label
_f2(label)
...
dest_label:
.end
.sub _f2
.param int
At 11:12 AM +0100 3/27/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ mmd functions ]
Another question:
,--[ pdd15 ]--
|While vtable methods may take a continuation, those
|continuations may not escape the
At 10:29 AM -0800 3/29/04, chromatic wrote:
On Mon, 2004-03-29 at 10:23, Dan Sugalski wrote:
Ultimately it ought to be doable to have the JIT,
on JIT capable systems, construct custom C function headers which
means we could skip the second table *and* not bother with PMCs or
anything equally f
On Mon, 2004-03-29 at 10:23, Dan Sugalski wrote:
> Ultimately it ought to be doable to have the JIT,
> on JIT capable systems, construct custom C function headers which
> means we could skip the second table *and* not bother with PMCs or
> anything equally fat for the function entries.
Would b
At 8:40 AM +0100 3/27/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
So, I'm doing these, because I need 'em, and we might as well get the
things in now. For the record, these things will be called as
functions (not methods), with three parameters, so the signature
looks lik
At 8:16 PM +0200 3/29/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 8:40 AM +0100 3/27/04, Leopold Toetsch wrote:
A short question WRT implementation: shouldn't all MMD functions just
use one function slot? You now seem to duplicate the whole table.
Yes, I do.
Did you consider ussng PMCs as
Dan Sugalski wrote:
At 8:40 AM +0100 3/27/04, Leopold Toetsch wrote:
A short question WRT implementation: shouldn't all MMD functions just
use one function slot? You now seem to duplicate the whole table.
Yes, I do.
Did you consider ussng PMCs as instead of plain function pointers. As
outlined
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ mmd functions ]
Another question:
,--[ pdd15 ]--
|While vtable methods may take a continuation, those
|continuations may not escape the vtable method's
|execution. This is due to
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> So, I'm doing these, because I need 'em, and we might as well get the
> things in now. For the record, these things will be called as
> functions (not methods), with three parameters, so the signature
> looks like:
A short question WRT implementation: shou
14 matches
Mail list logo
