There is not much to explain: I would assume that when someone asks a question like this he did so for a good reason. Other people have a brain as well.
If you would like to know why somebody is requesting this you could ask rather than patronizing people.
I've written a VB .Net implementation of APL. As part of that effort, there is an APL to VB compiler. Since all .Net DLLs are callable from other .Net languages, this could easily be used in one of two ways.
1) Use my compiler as is, produce a VB DLL, call the DLL thus produced from C#.
2) Get a copy of my compiler, modify it to produce C# DLLs. Other than function header differences, that is mostly a matter of using [] instead of () for arguments to an object's default properties.
Both of these paths require the PLJsAPL.DLL which is were the real work takes place. If this sounds like what you are looking for, please go to http://home.comcast.net/~paul.l.jackson/PLJsAPL/ where everything above, except option 2, is available today for free. Please contact me privately with any detailed questions.
Paul
On Mar 29, 3:10 am, lautrec2 <ocuch...@gmail.com> wrote:
> I've written a VB .Net implementation of APL. As part of that effort, > there is an APL to VB compiler. Since all .Net DLLs are callable from > other .Net languages, this could easily be used in one of two ways.
> 1) Use my compiler as is, produce a VB DLL, call the DLL thus > produced from C#.
> 2) Get a copy of my compiler, modify it to produce C# DLLs. Other > than function header differences, that is mostly a matter of using [] > instead of () for arguments to an object's default properties.
> Both of these paths require the PLJsAPL.DLL which is were the real > work takes place. If this sounds like what you are looking for, > please go to > http://home.comcast.net/~paul.l.jackson/PLJsAPL/ > where everything above, except option 2, is available today for free. > Please contact me privately with any detailed questions.
> Paul
> On Mar 29, 3:10 am, lautrec2 <ocuch...@gmail.com> wrote:
> > Hello! I'd like to know whether some technology still exists to > > convert APL code to C or C# code ? > > Thanks in advance
I believe Bjorn might have missed the point of the question which I think Paul rightly understood as a request for a translator or compiler of APL to C rather than a C code generator written in APL.
But taken in another light I have sympathy with Bjorn's point. Huge resources are put into the attempt to rewrite in C or any one of its derivatives systems that were originally written and continue to work and be developed in APL.
There being "no need" is demonstrated by the gap between the current state of the production APL system and its replacement which lags ever further behind at every change requested by the users and quickly supplied by the APL developers.
> On Mar 30, 9:28 pm, PLJ <plj...@gmail.com> wrote:
> > I've written a VB .Net implementation of APL. As part of that effort, > > there is an APL to VB compiler. Since all .Net DLLs are callable from > > other .Net languages, this could easily be used in one of two ways.
> > 1) Use my compiler as is, produce a VB DLL, call the DLL thus > > produced from C#.
> > 2) Get a copy of my compiler, modify it to produce C# DLLs. Other > > than function header differences, that is mostly a matter of using [] > > instead of () for arguments to an object's default properties.
> > Both of these paths require the PLJsAPL.DLL which is were the real > > work takes place. If this sounds like what you are looking for, > > please go to > > http://home.comcast.net/~paul.l.jackson/PLJsAPL/ > > where everything above, except option 2, is available today for free. > > Please contact me privately with any detailed questions.
> > Paul
> > On Mar 29, 3:10 am, lautrec2 <ocuch...@gmail.com> wrote:
> > > Hello! I'd like to know whether some technology still exists to > > > convert APL code to C or C# code ? > > > Thanks in advance
> I believe Bjorn might have missed the point of the question which I > think Paul rightly understood as a request for a translator or > compiler of APL to C rather than a C code generator written in APL.
> But taken in another light I have sympathy with Bjorn's point. Huge > resources are put into the attempt to rewrite in C or any one of its > derivatives systems that were originally written and continue to work > and be developed in APL.
> There being "no need" is demonstrated by the gap between the current > state of the production APL system and its replacement which lags ever > further behind at every change requested by the users and quickly > supplied by the APL developers.
Yes, it well may be so. But we don't know WHY the question was asked. There are all sorts of possible reasons:
* Need for "managed" code * Technical interest * Performance problems * Someone looking for references while writing an article * ... (many more possible reasons)
When I was asked this question in person - and I was several times over the last 30 years) my answer in about 90% of the cases was "don't even consider this an option" - after finding out what the intention was.
Sometimes strange demands need to be fullfilled. One former client happily used an APL system for a long period of time. However, they fellt that they were in need for a kind of insurance to make sure that in case of a disaster like a deadly desease killing all APLers in the world there IT guys could carry on with a "C copy" of the APL application. Of course this is rubbish: code constructed in this way is not going to be comprehensible. But when you tell this a customer and the customer still insists, well, so it be.
But that's not the point. Point is that I am get increasingly thrilled by Bjoern's approach to boss poeple around. I know that quite a number people share this feeling but most people are too polite to tell him. They leave that to the Germans I suppose...
> It is interesting to see that after decades of effort we get further > away from the object of getting a compiler.
> Apl gets more and more advanced and the possibility of compiling it > gets ever harder.
> At the same time the reason to create a compiler gets ever less > important and the need for one is ever less important.
Just the opposite:
- There is Visual APL available which isn't compiling into C but byte code. - Bob Bernecky is still making a living with compiling APL. - Soon you will see inline compiling in Dyalog.
There might be more.
BTW, don't trust any information on Wikipedia regarding APL: it's almost impossible to change anything in the APL related articles on the Wikipedia nowadays even it's a simple mistake.
> Hello! I'd like to know whether some technology still exists to > convert APL code to C or C# code ?
Still exists? I recall a few research efforts, but no commercial compilers. Usually the reason is that the market simply isn't big enough to justify it.
I understand the need, in the sense of making a complex APL computation *accessible* to C or C#, or to build a high-performance implementation of an APL computation (like it or not, APL is an interpreter).
DMS is designed to easily accept explicit language definitions (e.g., APL) and already has a large collection of existing langauge definitions (e.g., C, C++, C#, Java, COBOL, ... each in variety of dialects). It has control and flow analyzers and means to build custom analyzers.
A DMS-based translator requires language definitions for the input language, the output language, and a set of translation rules. APL doesn't exist but is pretty easy to parse (based on my experience with APL) regardless of whether you choose a strange character set, or asciified operators.
Presumably after parsing APL, you want to do a control flow and data flow analysis (generally pretty easy with APL) but more importantly a type- and shape- analysis for the various operations. Using this information you would want to produce optimized chains of array computations, maybe even to the point of generating SIMD instructions (both C and C# have ways to support this, amazingly!). [Aside: We've done SIMD code generation from C++ code using DMS].
You could probably build a translator this way. While the parsing is easy, the rest is probably a fair amount of work.
> > Hello! I'd like to know whether some technology still exists to > > convert APL code to C or C# code ?
> Still exists? I recall a few research efforts, but no commercial compilers. > Usually the reason is that the market simply isn't big enough to justify it.
> I understand the need, in the sense of making a complex APL computation > *accessible* to C or C#, or to build a high-performance implementation > of an APL computation (like it or not, APL is an interpreter).
> DMS is designed to easily accept explicit language definitions (e.g., APL) > and already has a large collection of existing langauge definitions > (e.g., C, C++, C#, Java, COBOL, ... each in variety of dialects). > It has control and flow analyzers and means to build custom analyzers.
> A DMS-based translator requires language definitions for the input language, > the output language, and a set of translation rules. APL doesn't > exist but is pretty easy to parse (based on my experience with APL) > regardless of whether you choose a strange character set, or > asciified operators.
> Presumably after parsing APL, you want to do a control flow and > data flow analysis (generally pretty easy with APL) but more importantly > a type- and shape- analysis for the various operations. Using > this information you would want to produce optimized chains of > array computations, maybe even to the point of generating SIMD > instructions (both C and C# have ways to support this, amazingly!). > [Aside: We've done SIMD code generation from C++ code using > DMS].
> You could probably build a translator this way. While the parsing is easy, > the rest is probably a fair amount of work.
I am puzzled that so little seems to be known about the current state of Tim Budd's Aplc Apl to C compiler. Sam Sirlin has been developing this, and I did a number of years work on it, adding real-time and multi-tasking capabilities. Sam has extended the complex number capabilities to quaternions, and octonions. See : http://home.earthlink.net/~swsirlin/aplcc.html for freely downloadable source.
Sort of tool I built using it can be seen at : http://www.lab-tools.com/instrumentation/html/dod22.html This was a Show and Analyse for Large Area Multidetector Data for the Intstitute of Laue Langevin - Small Angle Neutron Scattering Instrument D22 (the size of a locomotive and carriage, all precision computer controlled). Compiled for Unix & Linux, graphical.control interface using Postscript graphical displays, Tcs & Tk, with heavy use of multi-tasking. Doubt if it still runs without re-compiling. cheers Dr. Beau Webber http://www.Lab-Tools.com
> > Hello! I'd like to know whether some technology still exists to > > convert APL code to C or C# code ?
> Still exists? I recall a few research efforts, but no commercial > compilers. > Usually the reason is that the market simply isn't big enough to justify > it.
> [SNIP] Using > (code flow) information you would want to produce optimized chains of > array computations, maybe even to the point of generating SIMD > instructions (both C and C# have ways to support this, amazingly!).
> You could probably build a translator this way. While the parsing is easy, > the rest is probably a fair amount of work.
> -- > Ira Baxter, CTOwww.semanticdesigns.com >I am puzzled that so little seems to be known about the current state >of Tim Budd's Aplc Apl to C compiler. >Sam Sirlin has been developing this, and I did a number of years work >on it, adding real-time and multi-tasking capabilities. >Sam has extended the complex number capabilities to quaternions, and >octonions. >See : http://home.earthlink.net/~swsirlin/aplcc.html for freely > downloadable source.
So... tell us about it. What are interesting properties of the compilation, other than it produces C code? Does it compile individual operators one-at-a-time? Does it do blocked operations considering cache lines? Does it does optimized code generation across multiple operators? Does it use SIMD instructions?
I got to play with the IP Sharp "interpreter" on a Sigma 7 back in the early 70s. It compiled APL statements into machine code using what it knew about the array ranks/sizes as it interpreted them; it was impressive fast compared to the IBM APL on 360 model 40 that I had concurrent experience with. That seems to me to be the bottom end of what one should expect from an APL compiler in 2010. If one has a "simple" compiler that just generates C code without knowing the temporally local properties of the variables, and doesn't do any interesting optimzations, it isn't clear to me that it would execute code much faster than the IP Shart Interpreter.
A good compiler should go considerably further these days; the compiler technology is certainly there.
Tim Budd wrote a book about his APL compiler, it's long out of print though from time to time there is a reasonably priced ($20) copy on Amazon.
I don't think it is correct to call this kind of program a "compiler". "Translator", perhaps.
To answer your questions to the best of my ability,
> What are interesting properties of the compilation, > other than it produces C code?
Budd changes the language around to make it easier to "compile". Specifically, he disposes of APL's famous dynamic scoping and goes to a [strictly] local scoping. Budd also tries to go to strong typing but somehow keeps vestiges of dynamic typing around.
Budd also went with a demand driven approach where an expression like
1 0 0 1 / (some array expression)
would attempt to avoid computing the elements from rows 2 and 3.
There was also the facility to do compositions of some structural functions like transpose, rotate, take, and drop. (Overtake, i.e. 10 10 take 3 3 reshape iota 9, was not supported)
> Does it compile individual operators one-at-a-time? > Does it does optimized code generation across multiple operators?
I guess the question is what would it do with a code fragment like
+/ A x B * C
It may emit something to the effect of
r = 0; for (i = 0; i < A.length; i++) { r = r + A * exp(B,C); }
This solution exploits the fact that +/ is well behaved in that + is associative and has an identity of 0.
In APL, "operator" means a kind of higher-order function.
> Does it do blocked operations considering cache lines?
No, this program was developed in the early 1980s for something like a PDP-11. Cache wasn't the problem then it is now. Arguably, the APL concept of large arrays, that is, large contiguous stretches of memory and code having to deal with several of these at once, doesn't sit too well with modern cache properties. The C approach of arrays of arrays starts to look better here.
> Does it use SIMD instructions?
Like MMXn? 3dNow and Then? Certainly not directly. I suppose some C compilers (like Intel) would use them more than others (MS).
As this translator emitted C, the best it could do is leave hints behind so that the C compiler down the line could do the best with what it had. The philosophy here is to concentrate as much as possible on the APL and array issues, and leave the details of MMX, the cache, and the little reduction of strength issues to the underlying target language compiler.
Generally, some APL solutions depended on "overcomputing" approach, where the program would compute a large intermediate result then extract the answer. Billions and billions of numeric operations, compiled or otherwise, still take time. Compilation cannot magically solve this, only a better algorithm can.
> Budd also went with a demand driven approach where an expression like
> 1 0 0 1 / (some array expression)
> would attempt to avoid computing the elements from rows 2 and 3.
This can sometimes be one of its most significant ways of speeding up the calculations
> There was also the facility to do compositions of some structural > functions like transpose, rotate, take, and drop. (Overtake, i.e. 10 > 10 take 3 3 reshape iota 9, was not supported)
I believe there are in the present version of the compiler two versions of take, you choose the one that works best for the case in hand.
> > Does it compile individual operators one-at-a-time? > > Does it does optimized code generation across multiple operators?
> I guess the question is what would it do with a code fragment like
> +/ A x B * C
> It may emit something to the effect of
> r = 0; > for (i = 0; i < A.length; i++) { r = r + A * exp(B,C); }
> This solution exploits the fact that +/ is well behaved in that + is > associative and has an identity of 0.
The above assumes that the highest rank in A,B,C is vector, One major problem with compiling Apl is that one could have arrived at this line of code as a jump from anywhere. i.e. the types and ranks of A,B,C are effectively undefined.
Aplc partially gets around this by having optional declarations :
:decl #vector #int A :decl #vector #real B,C :decl #scalar #real D
A .is .iota 5 A B .is 0.1 .times A B C .is 1 + B C D .is +/ A .times B .exp C D
Without the declarations this compiles to 300 lines of c, (mostly comments, or checks/safety coding in the event things are undefined). Adding the declarations takes 60 lines off the code. They also act as a validation - the compiler is intelligent enough complain if you define D as say vector.
The line D .is +/ A .times B .exp C then compiles to :
which is fairly close to what the suggested code should be .... [this is compiled using aplc-6.13, in Cygwin under Windows 7 64bit] It outputs : 1 2 3 4 5 0.1 0.2 0.3 0.4 0.5 1.1 1.2 1.3 1.4 1.5 3.873304
Extending the vector : A .is .iota 1000000 B .is 0.0000001 .times A (and not printing A,B,C) runs and gives execution times on a 1.6 GHz Intel i7 as : 2.754187e+10 0.358u 0.015s 0:00.46 78.2% 0+0k 0+0io 7528pf+0w
> In APL, "operator" means a kind of higher-order function.
> > Does it do blocked operations considering cache lines?
> No, this program was developed in the early 1980s for something like a > PDP-11. Cache wasn't the problem then it is now. Arguably, the APL > concept of large arrays, that is, large contiguous stretches of memory > and code having to deal with several of these at once, doesn't sit too > well with modern cache properties. The C approach of arrays of arrays > starts to look better here.
> > Does it use SIMD instructions?
> Like MMXn? 3dNow and Then? Certainly not directly. I suppose some C > compilers (like Intel) would use them more than others (MS).
> As this translator emitted C, the best it could do is leave hints > behind so that the C compiler down the line could do the best with > what it had. The philosophy here is to concentrate as much as > possible on the APL and array issues, and leave the details of MMX, > the cache, and the little reduction of strength issues to the > underlying target language compiler.
Full agreement.
> Generally, some APL solutions depended on "overcomputing" approach, > where the program would compute a large intermediate result then > extract the answer. Billions and billions of numeric operations, > compiled or otherwise, still take time. Compilation cannot magically > solve this, only a better algorithm can.
There seems to be some code in the compiler looking for branching, and structured flow-control is now supported, which together offer significant possibilities for simplification of the compiled code.
I hope this gives some idea of the pitfalls inherent in trying to compile Apl and of the capabilities of aplc. cheers, Beau
Even if it is known that all the arguments are vectors, how does this compiler deal with singletons?
For any scalar APL function there are three cases: Same shape Left is singleton Right is singleton
Since all of these are conformable, there would be a substantial explosion of the number of expressions one would have to provide to take care of all conformable expressions involving multiple functions.
The IPSA compiler someone mentioned was an in memory compile of a few machine instructions to build the loop. I'm not aware of it handling multiple functions, but I never worked on that code.
Paul
On Apr 3, 4:40 am, Ibeam2000 <ibeam2...@gmail.com> wrote:
> Even if it is known that all the arguments are vectors, how does this > compiler deal with singletons?
> For any scalar APL function there are three cases: > Same shape > Left is singleton > Right is singleton
> Since all of these are conformable, there would be a substantial > explosion of the number of expressions one would have to provide to > take care of all conformable expressions involving multiple functions.
> The IPSA compiler someone mentioned was an in memory compile of a few > machine instructions to build the loop. I'm not aware of it handling > multiple functions, but I never worked on that code.
> Paul
Yes indeed there are a number of cases for these examples. One has to consider the additional cases where they are single known constants, named variables (that could change), etc. This compiler tracks these, evaluates how much it knows about each expression, and emits something reasonably efficient.
for : Res .is 10 + .iota 5 Res
the crucial parts are : .... int i_main[4] = {0, 1, 10, 5}; .... i5 = aplc_ixorg; .... aplc_settrs(&trs1, APLC_INT, 1, &i_main[3]); i1 = aplc_talloc(&trs1); mp1.ip = trs1.value.ip; for (i2 = 0; i2 < i1; i2++) { /* asntchk (type known and simple) mkrktype */ (*mp1.ip++ = (i5++ + 10));
}
....
emits : 11 12 13 14 15
Of course for such code it is always possible to first run parts of the code though an interpreter, and pre-evaluate Tables of Constants etc. I did that using pre-processor type declarations calling early versions of aplc on a Vax750 (1 mip.s-1, 1 mflop.s-1), when NMR imaging had just been thought of, to speed up iterative calls.
On Apr 3, 7:56 pm, "Dr. Beau Webber" <b...@Lab-Tools.co.uk> wrote:
> > Budd also went with a demand driven approach where an expression like
> > 1 0 0 1 / (some array expression)
> > would attempt to avoid computing the elements from rows 2 and 3.
> This can sometimes be one of its most significant ways of speeding up > the calculations
Please notice that this breaks the APL specs which imposes that all the elements of an array are computed before the execution moves to the following instruction on its left. From a theorical point of view, APL is a language that doesn't offer simple ways to simplify the execution of its expressions. For instance, according to the specs, the expression:
1 0 0 1/1 2 3 4 %1 0 2 3
(where % should be the "divide by" primitive) MUST fail with a DOMAIN ERROR, even though the division by zero can be avoided because it won't influence the result...
A compiler that optimises the division by zero in theory is compiling a language that cannot be called APL from the point of view of the official specs. -- Stefano
> > > Budd also went with a demand driven approach where an expression like
> > > 1 0 0 1 / (some array expression)
> > > would attempt to avoid computing the elements from rows 2 and 3.
> > This can sometimes be one of its most significant ways of speeding up > > the calculations
> Please notice that this breaks the APL specs which imposes that all > the elements of an array are computed before the execution moves to > the following instruction on its left. From a theorical point of view, > APL is a language that doesn't offer simple ways to simplify the > execution of its expressions. For instance, according to the specs, > the expression:
> 1 0 0 1/1 2 3 4 %1 0 2 3
> (where % should be the "divide by" primitive) MUST fail with a DOMAIN > ERROR, even though the division by zero can be avoided because it > won't influence the result...
> A compiler that optimises the division by zero in theory is compiling > a language that cannot be called APL from the point of view of the > official specs. > -- > Stefano
Thanks - A clear case where the compiler exhibits a robustness for real-life computation that I have used to keep the earlier example of SANS data analysis up and running.
