Hi Steve,
when I first saw the heading I was interested, but seeing the words
BASIC, COBOL and Fortran made me a little uneasy. I honestly don't think
you'd get much traction or interest in a language syntactically similar to
those - it should use modern techniques where valid, for example even Json
would be easily / more accessible than the COBOL PICTURE clause.
I love the idea of having SQL commands built into the language.
I can't wrap my head around the WHEN command - may need some more
information on this, but it appears as though it could have concurrency
issues and odd side effects (due to programmers not using it correctly /
understanding it).
The speed increase using the FPGA is the biggest selling point in my mind,
and for AI work there are large repeatable batches of maths crunching so
there should be an increase. I dont know how long it would take you to
prototype something specific for a single calculation (prime number
generation for example?), but nothing gets interest like a real test.
On the same hardware, using the same algorithm if you can increase the
speed of this compared to other languages on that box, then you will get a
lot of interest.
Another thought could be to implement this as a library that existing
languages can access.
Cheers,
Duncan
[email protected]
On Mon, Aug 3, 2015 at 6:12 PM, Steve Richfield <[email protected]>
wrote:
> PM,
>
> It sounds like you may be too far removed from FPGAs to help here.
>
> FPGAs seem to be positioned to replace CPUs as they now exist. FPGAs are
> able to execute page-long loops completely in parallel, producing
> results-per-clock-cycle, whereas the best conventional CPUs can do is to
> produce operations-per-clock-cycle.
>
> However, no good programming language for them has been forthcoming. What
> they have is even lower than assembly language - closer to horizontal
> microcoding.
>
> Conventional procedural languages are unsuitable for FPGAs, because the
> first step, massive parallelism, must be discarded in order to even use
> languages that presume that only one (or just a few) things can be done at
> once.
>
> Not only are there no suitable languages for FPGAs, there aren't even any
> active discussions about the subject. NO ONE has yet made any proposals,
> despite decades of need. My goal was to ignite such discussions by
> exhibiting a plausible high-level language for FPGAs.
>
> It you are interested in doing things like AGI at practical speeds, you
> REALLY need to come up to speed on FPGAs. There are several proposals
> floating around for attaching FPGAs as co-processors, and there have
> already been such products, though it is my own opinion that there really
> is no need for a CPU once the implementation language problem is solved.
>
> Steve
> =============
>
> On Mon, Aug 3, 2015 at 12:22 AM, Piaget Modeler <[email protected]
> > wrote:
>
>> If the purpose of this languge is to crunch numbers, then you should look
>> at R as well.
>> If the purpose of this language is to move data then you should look at
>> SQL as well.
>> If the purpose of this language is to do pattern matching over data
>> records then you should look at OPS as well.
>> If the purpose of this language is to do literal programming then you
>> should look at Premise as well.
>> If the purpose of this language is to do symbolic manipulation then you
>> should look at Lisp as well.
>> If the purpose of this language is to do object oriented programming then
>> you should look at Java as well.
>>
>> Parallel operations for what purpose? Are these low level parallel
>> operations or high level parallel operations?
>>
>> What is really new here? Same old procedural programming or something
>> special?
>>
>> Your thoughts?
>>
>> ~PM
>>
>> ------------------------------
>> Date: Sun, 2 Aug 2015 23:48:54 -0700
>> Subject: [agi] Design notes for a new parallel computing language
>> From: [email protected]
>> To: [email protected]
>>
>>
>> Hi all,
>>
>> I am working on a high-level FPGA programming language, that should also
>> serve better than existing languages as an AGI implementation language and
>> a robotics programming language. This is designed to be executed on FPGAs
>> rather than CPUs, though a PC version is contemplated.
>>
>> Here are my early thoughts. All comments are welcome.
>>
>> Parallel Computing Language
>> *Design Notes by Steve Richfield *as of Aug 2, 2015
>>
>> The goal of PCL is to provide a language to express algorithms in
>> parallel form for easy compilation to either parallel or sequential
>> platforms, rather than forcing programmers to express their algorithms in a
>> probably inefficient sequential form, for a (nonexistent) compiler to
>> translate to a parallel form.
>>
>>
>> The special need is to be able to translate to FPGA implementations,
>> which presently require efficient translation to be able to fit into
>> existing hardware.
>>
>>
>> *Existing Technology from which to Borrow*
>>
>> *APL structure:* In APL, everything is a matrix of varying
>> dimensionality, including zero dimensions (a simple variable). It includes
>> numerous array operations as operators in the language. Unfortunately, its
>> promoters have adopted syntax reminiscent to Sanskrit, which is enough to
>> chase away anyone not well versed in matrix inversions, etc. Some of the
>> IBM-360 architecture was first worked out in APL.
>>
>>
>> *Dartmouth BASIC MAT statements: *The original Dartmouth BASIC
>> recognized MAT at the beginning of statements to indicate that the
>> statements specified matrix operations, rather than operations on
>> variables. Hence, *MAT C=A*B* multiplied matrix *A* by matrix *B*, and
>> stored the result in matrix *C*. APL-like procedure is MUCH less opaque
>> in this syntax.
>>
>>
>> *COBOL PICTURE clauses:* COBOL provided an easy (though now arcane) way
>> of easily describing variable structure, which could be easily extended to
>> meet present needs. Specifying *PICTURE 9999*, which could be
>> abbreviated *PIC 9(4)*, a programmer could easily state that a variable
>> had to hold 4 decimal digit values. In our implementation, *PICTURE
>> 111111111111* or *PIC 1(12)* could specify a 12-bit field, as could *PICTURE
>> 7777* or *PICTURE FFF*. COBOL also allowed for fixed-point notation,
>> which is also important in FPGA context, e.g. with *PICTURE 999V99* to
>> represent 3 digits to the left and two digits to the right of the implied
>> decimal point. Provision would have to also be made for logarithmic
>> notation. Note that in addition to precisely specifying “variables”, this
>> also guides debuggers on how to display what they find. This approach would
>> allow for specifying pipeline widths to be as narrow as possible for each
>> operation.
>>
>>
>> *FORTRAN Arithmetic Statement Functions:* FORTRAN provides a one-line
>> way of specifying simple function subroutines, e.g.
>> *RMS(A,B)=SQRT((A**2)+(B**2))* that are usually implemented by simple
>> string substitution into their references, so they are executed as an
>> in-line subroutine in C, but without the need to specify they are in-line.
>> Data chaining in complex operations would be easy to specify with such
>> syntax.
>>
>>
>> *Eliminating **GOTO** statements: *Parallel processing aside, there are
>> plenty of good reasons to eliminate *GOTO* statements. In the process,
>> we should probably eliminate everything else that specifies anything
>> conditional beyond conditional storage of computed results. The presence of
>> a particular condition that necessitates particular processing should be
>> handled as an event, though it would be possible to fake it by translating
>> conditional logic into an event handler.
>>
>>
>> *All “procedure” will be event-driven:* Where sequence is needed, it
>> will be triggered step-by-step, e.g. by *WHEN* statements. Where a long
>> sequence is needed, each step must be triggered by completing the previous
>> step. To avoid programming flags and *WHEN* clauses for each step, a
>> *PROCEDURE* will be declared, that necessarily starts with a *WHEN*
>> clause, after which the compiler will assume that each step starts when the
>> previous step has completed. There may be any number of procedures
>> simultaneously active at any one time, but only one instance of any
>> particular procedure, unless it is declared as being *RECURSIVE* and/or
>> *REENTRANT*. Where a procedure requires conditional operation within it,
>> the conditional operation will be triggered and entered via a *WHEN*
>> statement. Note that complex *WHEN* statements, when implemented in
>> hardware, only cost gates and NOT any time.
>>
>>
>> *Familiar Operations: *Familiar operations like SELECT ... CASE
>> statements will be provided, though they will “execute” in unfamiliar ways.
>> For example, a SELECT statement will simultaneously “execute” all CASEs for
>> which the stated conditions are satisfied.
>>
>>
>> *Syntax:* Three different syntaxes will be supported, which can be
>> intermixed on input. They are mathematical, familiar (similar to C), and
>> verbose (similar to COBOL). For example, familiar *MAT C=A*B *in the
>> example above would be simply *C=A*B* in mathematical form, and *Multiply
>> matrix A by matrix B giving matrix C* in verbose form. Error messages
>> from the compiler would show both the input and the equivalent verbose
>> forms, to show how the compiler interpreted the statements.
>>
>>
>> *Early implementations:* Initially this PCL will be a publication
>> language to specify the construction of complex programmable logic. Then, a
>> translator will be written in a portable language like C to translate
>> programs from PCL to C so that programs can be tested on personal
>> computers, etc. Then, translators will be written to translate to FPGAs
>> programming languages *Verilog* and *VHDL*, and finally, FPGAs will be
>> adapted to become better targets for code produced by this process, much as
>> IBM 360/370 mainframes were designed as prime targets for COBOL programs.
>>
>>
>> *Other Applications:* This language comes VERY close to also meeting the
>> needs for robotics applications, with many simultaneous tasks and close
>> coupling to I/O, so it should be expanded to include anything that might be
>> missing to also serve robotics.
>>
>>
>> *Comments:* PLEASE comment on this at any level, most especially what
>> other languages might serve this need, what features of other languages
>> should be incorporated, what it might be missing, what might be wrong, etc.
>>
>>
>> Steve
>>
>>
>>
>>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now>
>> <https://www.listbox.com/member/archive/rss/303/19999924-4a978ccc> |
>> Modify <https://www.listbox.com/member/?&;> Your Subscription
>> <http://www.listbox.com>
>> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now>
>> <https://www.listbox.com/member/archive/rss/303/10443978-6f4c28ac> |
>> Modify <https://www.listbox.com/member/?&;> Your Subscription
>> <http://www.listbox.com>
>>
>
>
>
> --
> Full employment can be had with the stoke of a pen. Simply institute a six
> hour workday. That will easily create enough new jobs to bring back full
> employment.
>
> *AGI* | Archives <https://www.listbox.com/member/archive/303/=now>
> <https://www.listbox.com/member/archive/rss/303/25449614-a78bbfa7> |
> Modify
> <https://www.listbox.com/member/?&;>
> Your Subscription <http://www.listbox.com>
>
-------------------------------------------
AGI
Archives: https://www.listbox.com/member/archive/303/=now
RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657
Powered by Listbox: http://www.listbox.com
