hrubin@pop.stat.purdue.edu (Herman Rubin) (04/08/91)
In article <1991Apr5.172533.6717@agate.berkeley.edu>, doug@eris.berkeley.edu (Doug Merritt) writes: > In article <1991Apr4.125122.1@capd.jhuapl.edu> waltrip@capd.jhuapl.edu writes: > > He observes that "Few compilers use any of the nifty instructions that > > a CISC has." I believe I read recently that RISC was based on the > > observation that, in fact, only about 30% of the instructions in CISC > > computers were used by compilers. The rest of the instructions, for > > all practical purposes, were just excess baggage. ......................... > Anyway, the point is that even if compilers *do* use every possible feature > of a CISC, it still usually won't make the CISC s/w competitive with RISC > s/w. CISC cpus almost never put sufficient h/w optimization into the support > of the fancy instructions. (There are exceptions to this, of course, and I > haven't been watching the 030 and 040 to see how they do in this regard. > CISC may yet rise again, but not until after superscalar RISC has been > completely exploited.) If the languages do not allow the user to communicate the use of those features of the CISC architecture which can make the object code considerably faster, the compiler cannot take advantage of them. This IS the situation. For example, suppose there was an instruction, which could be effectively used, which would divide a float by a float, obtaining an integer quotient and a float remainder. Now just how is the compiler to recognize that this is in fact wanted? There is, at present, no language designed to take into account the collection of "natural" useful hardware which the present users can find uses for, and which are far more expensive in software than in hardware. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
hrubin@pop.stat.purdue.edu (Herman Rubin) (04/12/91)
In article <11APR91.21114644@uc780.umd.edu>, cs450a03@uc780.umd.edu writes: > Michael Turner writes: > > >Guy Harris's example (if I remember correctly) was that no language he > >knew of had semantics for retrieving both the integer quotient and the > >remainder from a floating divide ... > You mean like > 0 3.141592654 #: 20 > 6 1.150444076 Translate, please. Seeing the results, I still do not have any idea what the instruction does or how to put the results in a useful place, probably registers. The problem with APL and other such wierdos (like 99+% of the assembler languages) is their highly artificial syntax. I can, even at my age, learn the machine instructions quickly, but the stupid "mnemonics" of assembler language are another matter. This is what computer language people do not realize; they seem to think that memorizing even highly obscure notation is easy, and understanding slightly unusual operations is difficult. APL does have one feature lacking in at least most other languages; it attempts to have a reasonably compact notation. But there is no adequate macro processor available. An adequate macro processor would include the capability of easily translating APL into other languages, for example, and even having the translation take into account types. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
cs450a03@uc780.umd.edu (04/13/91)
Herman Rubin > Me >| Michael Turner >** >** Guy Harris's example (if I remember correctly) was that no >** language he knew of had semantics for retrieving both the integer >** quotient and the remainder from a floating divide ... >| You mean like >| 0 3.141592654 #: 20 >| 6 1.150444076 >Translate, please. Seeing the results, I still do not have any idea what >the instruction does or how to put the results in a useful place, probably >registers. Well, (x,y) #: z where x, y, and z are all single numbers returns two results. The "number on the right" is the remainder from z divided by y. The "number on the left" is the quotient of that division modulo x. "N modulo 0" is defined to be N. Therefore, (0,y) #: z computes the dividend and remainder of y divided by z. Finally, note that for constants, the notation (x, y) may be abbreviated by just writing the two numbers separated by a space. >The problem with APL and other such wierdos (like 99+% of the >assembler languages) is their highly artificial syntax. Anything you understand is simple. Anything you do not understand is not simple. I suppose I should also point out that in infix notation a function takes arguments on both the right side and the left side. I don't know if it is relevant to describe the details of this mechanism. Also note that #: is a single symbol. >APL does have one feature lacking in at least most other languages; >it attempts to have a reasonably compact notation. But there is no >adequate macro processor available. An adequate macro processor >would include the capability of easily translating APL into other >languages, for example, and even having the translation take into >account types. He he... APL is just now getting around to using ASCII... give it a little time before it translates to every language under the sun. :-) Other than that, it looks like all you are asking for is constant folding. Raul
sfk@otter.hpl.hp.com (Steve Knight) (04/14/91)
Just for the sake of the record, Pop11 has infix function that does a
divide & remainder at the same time. It's called "//" which is kind-of
mnemonic for a divide that has two results. Pop11 is a dynamically
typed language which supports the Common Lisp model for numbers
(i.e. from integers through rationals & floats to arbitrary precision
complex numbers.) So "//" does rather more than was asked for, really.
The previous example of 20 // pi would be written in Pop11 as
20 // pi;
the results would be
1.15044 and 6
Steve