APL converter
lautrec2
convert APL code to C or C# code ?
Thanks in advance
Bjorn
There is no need
kai
In particular there is not need for comments of this sort.
Bjorn
Why is that?
Do you think there is a need for Apl to generate C code?
If there were a need and someone willing to pay for it I am sure
someone would create one.
It is actually much better to run Apl code as Apl code than try to run
Apl code as C code so there is no need for Apl to generate C code.
So please explain?
kai
> So please explain?
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.
Ibeam2000
http://en.wikipedia.org/wiki/APL_programming_language
There is a section on "Compilers".
PLJ
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
Phil Last
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.
kai
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...
Phil Last
> They leave that to the Germans I suppose...
Ha, ha, ha!
Excellent!
Bjorn
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.
kai
> 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.
Kerry Liles
Oui, chacun à son goût.
Ira Baxter
news:87042948-0b3f-4015...@y26g2000yqd.googlegroups.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.
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).
To serve the needs of the custom tools/translators/compilers market,
we build a general purpose translation engine called the
"DMS Software Reengineering Toolkit".
See http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html
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.
--
Ira Baxter, CTO
www.semanticdesigns.com
Dr. Beau Webber
> "lautrec2" <ocuch...@gmail.com> wrote in message
>
> news:87042948-0b3f-4015...@y26g2000yqd.googlegroups.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.
>
> 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).
>
> To serve the needs of the custom tools/translators/compilers market,
> we build a general purpose translation engine called the
> "DMS Software Reengineering Toolkit".
>
> 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.
>
> --
> 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.
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
Ira Baxter
"Dr. Beau Webber" <be...@Lab-Tools.co.uk> wrote in message
news:85a5fec7-85e4-48b6...@a17g2000yqn.googlegroups.com...
On Mar 31, 3:45 pm, "Ira Baxter" <idbax...@semdesigns.com> wrote:
> "lautrec2" <ocuch...@gmail.com> wrote in message
>
> news:87042948-0b3f-4015...@y26g2000yqd.googlegroups.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.
>
> (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!).
>
> 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.
-- IDB
Ibeam2000
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.
Ibeam2000
Sorry, there is a minor omission, subscripting.
+/ A x B * C
where A, B, and C are conformable arrays may emit something to the
effect of
r = 0;
for (i = 0; i < A.length; i++) { r = r + A[i] * exp(B[i], C[i]); }
Dr. Beau Webber
> 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 :
aplc_trace("main", 7);
/* genassign */
/* lookup */
/* assignment */
/* asgn_named shape */
if (A.type == APLC_UKTYPE) aplc_error("undefined value (A) used");
mp7.ip = A.value.ip;
if (B.type == APLC_UKTYPE) aplc_error("undefined value (B) used");
mp6.rp = B.value.rp;
if (C.type == APLC_UKTYPE) aplc_error("undefined value (C) used");
mp5.rp = C.value.rp;
i5 = 5;
/* asgn_named shape val */
/* typesmatch(node, RIGHT) 1, asgn_pass_trs(node) 0 */
/* type(node) APLC_REAL; type(right) APLC_REAL*/
/* asgn_named shape val scalar or singleton */
res2.r = 0;
for (i3 = 0; i3 < i5; i3++) {
(res7.r = *mp5.rp++ );
(res6.r = *mp6.rp++ );
aplc_power_res(&res6, &res6, APLC_REAL, &res7, APLC_REAL);
(res2.r = ((((double) *mp7.ip++ ) * res6.r) + res2.r));
}
D.value.rp[0] = ((double) res2.r);
/* genassign done */
/* genassign */
/* lookup */
/* assignment */
/* asgn_named fin */
/* genassign done */
i.e.
res2.r = 0;
for (i3 = 0; i3 < i5; i3++) {
(res7.r = *mp5.rp++ );
(res6.r = *mp6.rp++ );
aplc_power_res(&res6, &res6, APLC_REAL, &res7, APLC_REAL);
(res2.r = ((((double) *mp7.ip++ ) * res6.r) + res2.r));
}
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
PLJ
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
Dr. Beau Webber
> 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.
Stefano "WildHeart"
> > 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
Dr. Beau Webber
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.