1. Target language (output of the compiler) is a relatively easy thing to change. Most modern compilers are built so that parsing of the input language, static single assignment conversion, data flow analysis, and the majority of algebraic optimizations occur with no knowledge of the target language. APEX is of that nature. At present, it can generate SISAL, SAC, or D, and the only thing that knows that is the back-end code generator.
Similarly, SAC supports single-thread, multi-thread, and CUDA that way. So, choice of a target language is fairly unimportant, in the sense that you can have a bunch of them, ISMOP willing. 2. A much more important decision is that of the intermediate language (IL)of the abstract syntax tree (AST) used in the compiler. APEX, for all practical purposes, does it this way, with single APLish primitives as the nodes. This APL source code: z← a + b × c becomes this in the AST, sort of: tmp1← b × c tmp2← a + tmp1 z← tmp2 SAC represents things in a similar, purely functional manner, e.g., it uses the J-like "m2 = modarray( indexvector, m, value)" as its internal representation for indexed assignment. This preserves the functional nature of the IL. Such high-level (compared to rtl), functional ILs permit algebraic optimizations to take place in a way that any APL or J programmer would immediately comprehend. Usually. A low-level IL such as rtl, often hides or destroys the functional nature of the AST, making high-level optimizations a lot harder to detect, let alone perform. 3. SAC copyright: this is something I hope we can resolve soon. 4. From your first paragraph, I get the impression that you want to create dynamic link libraries, aka shared libraries, which you would then be invoked from an APL or J interpreter. This is not a big deal, as it is, again, merely a back-end option. My APEX SAC back end generates (today) standalone binaries because that facilitates my automated performance benchmarks, and keeps interference from an interpreter out of the picture. Some earlier versions of APEX did support shared libraries, and I was able to invoke the compiled code from APL under Windows. That code would definitely need to be dusted off, but my point is that it can be done, again just by back-end code. 5. "The small fraction of interpreted code that eats the bulk of the time." - it is the lucky programmer who has the luxury of having such a bottleneck, precisely because it can easily be isolated, compiled, and called from the interpreter. There is a caveat here: Calls to/from an interpreter have several overheads, of which the major ones are the potential copying and type conversions of arguments and results between the private heap of the interpreter and the heap of the compiled code. Some of these copies can be avoided, and result space preallocated, given trust and contracts between interpreter and compiled code. I think that Dyalog APL has made substantial improvements in that area of late. Often, the time spent copying arrays will outweigh any or all gains made by executing compiled code fragments. E.g., compiling a scalar-dominated loop is likely worthwhile, but compiling A+B×C may not be a winner, particularly if the arrays are small. On 14-03-02 08:13 PM, Raul Miller wrote:
I was thinking of rtl as a target (after optimizations) rather than anything else. Also, my experience with APL compilers involved creating routines for use within the APL environment. I know it's popular to build compilers for the OS command line, but what I'd like to do is focus attention on the small fraction of interpreted code which eats the bulk of the time. That said, targeting SAC sounds like it might be far less work than targeting RTL. But I am somewhat worried about portability and deployment of SAC (RTL is a bit bulky but it has a compatible copyright and that's a good thing, and it allows support for many kinds of computing devices). Generally speaking, copyright issues get mis-managed. To really take advantage of computing resources you need to scale, and you need to tie your resources back to something else that people value (and there's a lot of such things). There's other ways of making money, of course, but that's a topic for another discussion. Thanks,
-- Robert Bernecky Snake Island Research Inc 18 Fifth Street Ward's Island Toronto, Ontario M5J 2B9 [email protected] tel: +1 416 203 0854 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
