Re: APL on a chip [was Re: Whither APL or wither APL ??]
- X-From: James L. Ryan <taliesinsoft@...>
On Wed, 9 Apr 2003 21:11:26 -0400, Curtis A. Jones wrote
(in message <3E94C4BE.A4DC213C@...>):
> What became of Analogic's APL Machine?The best way to sum it up was that the Analogic APL Machine was a
technological success and a market failure. The implementation team of some
ten persons was disbanded and manufacturing ceased in 1985.
The APL Machine had an interpreter running on a Motorola 68000 which in turn
passed the processing of the primitive functions onto an Analogic array
processor. Work had started on moving the interpreter itself onto the array
The implementation of APL was somewhat unusual in that the library was
organized into a collection of objects -- functions and variables, and if the
same object was used in more than one workspace there was no need to store
additional copies of it unless a change was made.
The APL language was compatible with STSC's pre-APL2 implementation, but
there were plans to advance it to an APL2 level.
The user interface was through what was called the "APL workstation" which
was a windowing environment, "InSight," implemented by Analogic, "and which
ran on an IBM PC and under the QNX operating system. InSight provided the
user with up to ten windows which could be concurrently active.
The APL Machine came with a rich library of sophisticated mathematical
routines which were implemented in the array processor's machine code and
which were interfaced with APL as either quad functions or library functions.
In 1984 The APL Machine was selected as "computing product of the year" by
Data Products magazine.
-- James L. Ryan -- TaliesinSoft
- X-From: johnjakson@... (john jakson)
Devon McCormick <devonmcc@...> wrote in message news:<20030408.104231.23733@...>...
> APL on a chip would be a great thing to test -snipped
> mightn't on-chip memory widen the scalar/small array
> It's possible too that one could use off-chip memory
> more efficiently if the processor had up-front
> information about array sizes. The way I understand
> it is that processors are so much faster than memory
> that it's hard to keep pipelines filled with data.
In a past life APL was one of my favourite languages, esp when used
with real APL KB. One of my 1st and fondest text books on computer
architecture used APL in all its glory to describe architectures circa
60s-70s. In a perverse way it can still be used to describe HW at
least as well as C if not better because of the variable vectors etc.
Nowadays the HDLs are much better. Thats probably true also for many
APL app areas, a specialised language for each domain can be more
efficient than a general purpose language.
Now having been a chip meister for >20years also and being pretty
comfortable in compilers I would probably say an APL chip makes no
sense at all.
1st an ASIC would be a few $M project and it wouldn't even run as well
as a fast x86 unless perhaps it could make use of many datapaths in
parallel, which could be mostly idle.
2nd FPGAs could be interesting as the dev costs can be small to large
depending on size of project. But FPGAs are better suited to all Int
structured parallel apps like DSP etc. Some big point against FPGAs is
that they generally only run up to 150MHz for cpu like structures such
as MicroBlaze, and FPU has been rarely implemented, (but apparently a
core is now available) because it is disproportionately bad in FPGA
It would make more sense to write a hand tuned assembler optimized
interpreter for whatever cpu takes your fancy, but x86 will likely
come out fastest, but I could be wrong on that. I thought that many of
the interpreters from the past were precisely that. It would seem that
underneath the few APL engines you can find, lies a common cpu after
Now if APL userbase were close to that of C, I would think more about
my 2 cents