I had been thinking gcc rtl - I've built gcc a number of times and while it can be complicated, most of the complications are irrelevant during the early development of a project. In particular, there are a number of subtleties which matter for cross compilation - where the compiler cannot know what it is compiling for just by looking at itself - which should not matter for the first few drafts of a compiler. Those abstractions can come later.
Still, that might mean that llvm is better for us than rtl, simply for its focus on native compilation (as opposed to cross compilation). Of course a third path involves something like CUDA (which, in its current state of development can only be supported through cross compilation, and which also needs a certain amount of native support, to get anything useful done). I imagine that an LLVM subset would focus on rank zero operations with a small amount of rank 1 and rank _ operations. CUDA would probably focus on rank 1 and rank 2 (I'm not certain whether CUDA could efficiently implement dyadic transpose, or boxed arrays - there's better things to start on). Actually... probably the best place to start with a language subset would be: First draft: rank 0 only + - * dyads, - monad, only one data type (floating point, probably) Second draft: rank 1 arrays and indexing Third draft: whatever you need to implement ;: (mostly this means arbitrarily ranked arrays - basically a pair of rank 1 arrays and integer division and modulo). Fourth draft: First pass at J parsing (but no names yet, no adverbs yet, no conjunctions yet) http://www.jsoftware.com/help/dictionary/dicte.htm Mostly these passes would be practice. But once you had the parser you could start using the tests which come packaged in the J sources. You would not so much use those in order (and some would never be done successfully - for a J subset you'd identify the fraction of the tests that your subset could handle) but you would use them to help you find things which can be done (relatively) easily which fit what you already have. Basically to manage a large body of code, you wind up using errors of some sort (compilation errors, testing errors, or whatever else) to help you focus on your next steps. Thanks, -- Raul On Thu, Feb 27, 2014 at 10:19 PM, Joe Bogner <[email protected]> wrote: > I started to toy with the idea of working on a subset of J that can be > compiled. The idea has been brought up before in the past. Yes, I > realize it's a path fraught with peril and a likely premature demise. > Still, as a toy, I figure it would be fun. > > Options for intermediate language: > > 1. GCC RTL - It looks very challenging and as far as I can tell would > require recompiling GCC, which is something I don't want to do > > 2. LLVM IR - I cobbled together a small example that emits IR which > can then be compiled. Hypothetically, we could use the LLVM C bindings > to generate IR from J words directly from J. For my proof of concept, > I used fsharp bindings since that seemed to be the easiest path on > wndows. Julia, Rust, and Haskell have LLVM targets. > > 3. C - Either clang, gcc or tinycc. Generating C doesn't seem as > stable and professional grade as the earlier options. However, I have > come across decent languages that do it (Chicken Scheme and others). > ELI does it, http://fastarray.appspot.com/compile.html. APEX also does > it, http://www.snakeisland.com/apexup.htm. Could be used to also JIT > code from J for small functions. > > I'm currently edging towards the C path. Maybe that makes more sense > as a little proof of concept since it seems like it'd be quicker to > get up and running. My vision here is to implement a subset of verbs > in C ({ i. # $) .. really basic .. and then have a parser that takes a > series of J expressions and translates them into the corresponding > running list of C function calls - all in a single main(). > > Some things I'm excited about trying out: > > 1. clang/llvm vectorization - > http://blog.llvm.org/2013/05/llvm-33-vectorization-improvements.html > > 2. parallel computation and concurrency - > http://opensource.mlba-team.de/xdispatch/docs/current/index.html > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
