This is a great classic book on programming languages, the Programming Language Landscape.
http://www.amazon.com/Programming-Language-Landscape-Semantics-Implementation/dp/0023758716/ref=sr_1_1?ie=UTF8&qid=1438630302&sr=8-1&keywords=programming+language+landscape My favorite chapter is "The Swamp of Complexity." In a nutshell -- too many languages with too much crap in them! It looks like you can get a copy for less than a buck.... Mike A On 8/3/15, Steve Richfield <[email protected]> wrote: > 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 > RSS Feed: https://www.listbox.com/member/archive/rss/303/11943661-d9279dae > Modify Your Subscription: > https://www.listbox.com/member/?&; > Powered by Listbox: 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
