Another option would be RPython (PyPy) -- it doesn't save a native binary executable, although it might be able to; but it's got some amazing JIT capabilities at a very low cost. (Of course, the negative is that it wouldn't inherit any of the C code.)
-Wm On Fri, Feb 28, 2014 at 10:38 AM, Raul Miller <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
