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, 2015The 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 BorrowAPL 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 | Modify Your Subscription ------------------------------------------- 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
