Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!usc!merlin.usc.edu!usc.edu!raulmill From: raulmill@usc.edu (Raul Deluth Rockwell) Newsgroups: comp.lang.apl Subject: Re: APL Machines Message-ID: Date: 13 Sep 89 15:12:16 GMT References: <153557@<1989Sep5> <49700014@uicsrd.csrd.uiuc.edu> Sender: news@merlin.usc.edu Organization: University of Southern California, Los Angeles, CA Lines: 101 In-reply-to: jaxon@uicsrd.csrd.uiuc.edu's message of 11 Sep 89 16:26:00 GMT In article <49700014@uicsrd.csrd.uiuc.edu> jaxon@uicsrd.csrd.uiuc.edu writes: There is a lesson in the APL Machine design, though. The array processor is not enough! . . . The uniprocessors responsible for serial sections of the interpreter, and whatever features are used to synchronize the parallel sections are absolutely critical elements in an APL supercomputer. Anybody have any comments on how how these should be implemented (i.e. deviations from commercial general-purpose CPU design)? Has anyone done any work to analyze the most common (and/or least used) operations in the serial/scalar/small vector portions of the machine? > The "equals" primitive could be written in APL : ...[buggy code > omitted] Several interpreters have tried using "magic functions" to produce new primitives from old. It is never as easy as it looks, and it is NEVER fast - it's not even tolerably slow. The point was not to write APL in APL, but to write APL in a generic vector language. However, let me say that you are probably right: it is too easy to implement []CT at the hardware level (especially if []CT is limited to negative-integer-powers of two) to justify leaving it out of a design. 1) Your definition is wrong -- you must take absolute values before comparing the arguments. I don't see that my definition was unacceptably wrong. Deviation from ideal is []CT squared, and for small values of []CT this is trivial. (I am assuming that I am allowed to limit []CT to small values). 2) Once the correct definition is written, you must make it work even when the intermediate terms exceed the number system's limits. Is good point. 3) By now you've got a function that works for simple scalars. To call it you'll have to create two scalar APL objects, and a stack frame (that's invisible in the caller's ")SI"). You'll have to make a class of APL function capable of returning into a primitive algorithm at the correct place. I'm not sure I'm not taking this level of complexity for granted in my earlier posting. I mean, if I do implement APL some vector language, won't I have to deal with this complexity for most of the primitives? Or, to rephrase: what level of complexity should be in hardware, what in software (feel free to elaborate on what you are expecting in hardware). . . . The dictionary approach ("function rank") is really a wonderful perfection of the original APL array processing ideas. . . . If operators can really manipulate the functions (e.g. pipelining them, carrying temporary results in registers, etc.) then I'd say the dictionary approach is best suited to today's vector supercomputers. But "function rank" seems tied to homogeneous arrays (am I wrong here?) Function rank is tied to what the function can handle. If the primitive function can handle hetrogenous arrays, then function rank is applicable to hetrogenous arrays. Since we are talking about APL machine architecture here, primitive means machine primitive, not language primitive. This leads into your idea of MIMD machines. There are real limits on programmers' ability to forsee what a function expression will do. . . . You can also do all kinds of unorthodox decompositions of your data, which stand no chance of being vectorizable. And "vectorizing" is not the only hope for APL anyway! Multiple instruction Multiple Data parallel machines are growing in number and power, these don't require that "one function" be in control, that "two arguments" be in memory and that "one type" of result is expected. You are probably right. I have been ignoring MIMD because I need to think more about instruction propagation in this type of machine. Know of any good references on the general subject? I think the APL2 approach will provide very rich ground for parallel machine designers. Make that the APL approach, and I will be happy. I do not consider APL2 a complete design at this point. (I do agree with including most of APL2's functionality in a design, but there are a number of issues I still have problems with.) -- btw, does anyone know any good reference works on Heisenberg's original approach to quantum physics? -- Raul Rockwell ! INTERNET: raulmill@usc.edu ! UUCP: ...uunet!usc!raulmill ! 55 mph = 82 nc U.S.SNAIL: 721 E Windsor #4, GLENDALE CA 91205 !