Duncan, On Mon, Aug 3, 2015 at 2:37 AM, Duncan Murray <[email protected] > wrote:
> 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 don't see how Json could specify the minimal word sizes and modes needed to conserve gates in an FPGA. Perhaps you see something I missed? Explain? There is an old adage "There is nothing new in computing" because just about everything has been done before, somewhere. Here, I was just showing that these things are NOT new - in the present situation where "modern" is unusable. Also, why invent something when there is a perfectly usable way already in existence? > > I love the idea of having SQL commands built into the language. > Yea, SQL is my favorite AI language - but not suitable as an implementation language, or inside of FPGAs, though an FPGA might be programmed in this language to become an SQL engine. > > 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). > For sure. It is the nature of FPGAs to want to do EVERYTHING at the same time - or add gates to keep this from happening. A big plus for any language is having less efficient things take more code. Perhaps I should pay more attention to scope - to better control side effects? I suspect there may be good ways to keep order with such things, only no one has yet worked this problem because no previous high-level language ran in this environment. > > The speed increase using the FPGA is the biggest selling point in my mind, > YES. > 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. > FPGAs are already used in large numbers, with pipelined data chaining as would also be the result of this language. Presently, "compiling" is a months-long grueling effort hand-writing low-level code, that the right language translator/compiler could do easily. > > 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. > That has already been done in several places. Often they get astronomical boosts from crazy methods that aren't programmable on PCs, like switching around the addressing lines to a block of memory to change its organization, soft-wiring complex functions, etc. > > Another thought could be to implement this as a library that existing > languages can access. > I had no intention of accelerating PCs with this, as this is a bit of a misfit for them. However, this might be better for implementing some highly parallel things, like robots, where functionality outweighs speed. Thanks for your comments. Steve ================= > > 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> > <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 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
