> The original GOOPS implementation had a somewhat crazy feature that an
> application of a generic function to a specific argument list first
> resulted in the standard MOP procedure for finding a set of applicable
> methods and, second, from this/these generated something called a "cmethod"
> (co
Many thanks for these links!
It seems like the GCC JIT interface is the kind of "adaptation" of gcc
which I asked for. :-)
Then there's the calling convention problem which Helmut brough up earlier
in this thread. But I guess there could be workarounds. In any case one
would have to look closer r
Mikael Djurfeldt writes:
> [I apologize beforehand for being completely out of context.]
> Are there fundamental reasons for not re-using the gcc backends for native
> code generation? I'm thinking of the (im?)possibility to convert the cps to
> some of the intermediate languages of gcc.
> If i
Mikael Djurfeldt writes:
> Are there fundamental reasons for not re-using the gcc backends for native
> code generation? I'm thinking of the (im?)possibility to convert the cps to
> some of the intermediate languages of gcc.
Also there is llvm. If there are issues, they may be different.
The following message is a courtesy copy of an article
that has been posted to gmane.lisp.guile.devel as well.
On Sat, Dec 03 2016, Mikael Djurfeldt wrote:
> Are there fundamental reasons for not re-using the gcc backends for
> native code generation? I'm thinking of the (im?)possibility to
> con
