I forgot to say that the dataflow list is what you probably guessed: an attempt to specify which of the register arguments to the opcode macros are inputs, and which are outputs. I want to use that for some extra checking ("Rn is unreferenced" or "Rn maybe used uninitialized") and to implement register allocation by setting up a set of constraints, each represented by user-defined variable, and solving the constraints like a sudoku puzzle, maybe. Apparently it is quite quick of you search the most highly constrained variables first. This is just a guess though. Another whacky approach might be to specify the constraints as Prolog terms and throw Harrison's Prolog interpreter at some likely-looking rules. But I am talking out of my hat, really ...

Nevertheless ... it would be nice of we _could_ have the register allocation algorithm described by a formal language, if not Prolog, then a bit like Prolog, because then we would only need to specify the interpreter, as two parts: a resolution solver and a search strategy, say. Then we would have a spec of lightning register allocation that (a) could be changed and easily experimented with, and (b) automatically implemented in any language for which we have written the list functionals like map, find, partition, etc.

And so on and so forth ... I am feeling like I have said rather a lot on these two list lately and should shut up for a while ...

Ian

On Sat, Sep 6, 2014 at 7:40 PM, Ian Grant <ian.a.n.grant-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:

Here is the basis of a lightning interface for Guile. The example shows that I seem to be able to JIT compile a foreign function binding and call it, at least once!

The rest is data that I generated using the rather awful hack at

https://github.com/IanANGrant/red-october/blob/master/src/dynlibs/ffi/testrewrite.sml

which parses the output of GCC's cpp when applied to the text "#include <lightning.h>" from whence it extracts the enum declaration of lightning's opcodes, and the macros that connect the opcodes with the node-generating functions jit_new_node_* Then it tries to infer the types of the jit_new_node functions from their names, and I explicitly define the types of the instruction opcode macros on a case-by-case basis, selecting them by regexps on their names.

I hope a competent scheme programmer could get a full set of lightning primitives going in a matter of a few hours using this. They won't if I have made a lot of mistakes typing the opcode macros, but the same sort of code I used in ML could be replicated in scheme, and then they could apply the fixes in bulk. Once working, the interface could then be used to generate itself, if one were that inclined. Or it could be used to implement a lexical analyser generator, which Guile seems to need.

Anyone interested in this could look at http://www.mpi-sws.org/~turon/re-deriv.pdf which is nicely written and gives a current perspective which seems to have benefited PLT Racket. I think it would be interesting to compile the DFAs into assembler which reads mmapped fles, or guile port buffers, or bytevectors. One could also compile the LALR tables into the same function, and I think the result would perform quite well. Have fun, but try to keep it abstract, so that the interface can be generated from the same formal spec. for EMACS lisp, say.

The same data could be used to generate a C function interface to lightning, which did more argument sanity checking than lightning's CPP macros currently do.

Ian

I've gzipped it just to stop the mailing list sed scripts from editing it. They don't seem to know much about programming :-)