Hi Noah, On Thu 27 May 2010 23:03, Noah Lavine <noah.b.lav...@gmail.com> writes:
> I now have a start at working bindings for Lightning, which you can > see at http://github.com/noahl/guile-lightning. Fascinating! Congrats on getting through the foreign function docs; a high-level interface is really necessary there... But very cool to see that you were able to get something working with so little code! > - Second, what would a good interface to a native code generation > system be? (I'm assuming we'll want Lightning available as a regular > module in addition to using it to speed up the language.) My current > prototype just mimics the Lightning API, but it's not necessarily the > best way to do this. Is there a better way? Second question first :) I collected my general thoughts on native code compilation here: http://thread.gmane.org/gmane.lisp.guile.devel/10234 I feel quite strongly that the calling convention for native code should be the same as that of bytecode, and that it should use the same stack. This way we don't have to maintain separate stack walkers or debuggers or the like. Also this way we get proper tail calls and multiple value handling as well. I tend to think that Ludovic's proposal, or something like it, is the most practical means to get a portable JIT compiler going; though I don't really know. In the end though Guile needs to be generating native code ahead-of-time, I think. Doing that portably is hard; we'll need to leverage some other project. I think that project should be GCC. I was talking to Dodji Seketeli the other day, a GCC dev, and he says that GCC maintainers are willing to allow other programs to use it for code generation, but they don't know yet what abstractions they need to provide. So first we should probably implement a native code compiler directly ourselves, for one architecture, and see how that experience changes our internal language barriers and then go to GCC with a set of requirements. (Since I know the question will come up, possibilities are numerous -- basically we want to emit something on the RTL level, I think, though I'm sure there will be much back-and-forth here; and licensing-wise, it might involve a build server (already planned), or a plugin, or a library. It will take a couple years I think.) > - First, would you like Lightning bindings? As I said, I think it's > the fastest way to get some native code generation going, but I don't > think it'll ultimately be the best. At the very least it's an interesting tool to have! Though I do agree though that it's not ideal. > (I can clean up and post my notes on different code generation systems > if you'd like them.) I would be very interested in your observations, yes :) > Thank you > Noah Lavine Thank you! Andy -- http://wingolog.org/
