Loading ...
Sorry, an error occurred while loading the content.

Re: APL on a chip [was Re: Whither APL or wither APL ??]

Expand Messages
  • News Gateway
    X-From: James L. Ryan On Wed, 9 Apr 2003 21:11:26 -0400, Curtis A. Jones wrote ... The best way to sum it up was that the Analogic APL
    Message 1 of 43 , Apr 10, 2003
      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?
      > Curtis

      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
    • News Gateway
      X-From: johnjakson@yahoo.com (john jakson) Devon McCormick wrote in message news: ... ... snipped
      Message 43 of 43 , Apr 19, 2003
        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 -
        > mightn't on-chip memory widen the scalar/small array
        > bottleneck?
        > 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
        esp normalisation.

        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
        dedicated HW.

        my 2 cents
      Your message has been successfully submitted and would be delivered to recipients shortly.