chip@tct.com (Chip Salzenberg) (05/02/91)
According to hrubin@pop.stat.purdue.edu (Herman Rubin): >Satisfysing my requests would require nothing of the sort. I see no >reason why I should have to hire a compiler writer for each augmentation. You're right, of course. Nor can I see a reason why we should endure endless tirades about how the all-singing all-dancing Herman Rubin Language Compiler will solve the world's problems, when you STILL haven't written ... [wait for it] the SPECIFICATION. Give us a spec, and we'll have something to discuss. Why spend all this time yammering about a hypothetical compiler, when that same effort expended in spec-writing could produce a REAL IMPLEMENTATION? -- Brand X Industries Sentient and Semi-Sentient Being Resources Department: Because Sometimes, "Human" Just Isn't Good Enough [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
hrubin@pop.stat.purdue.edu (Herman Rubin) (05/03/91)
In article <282002D1.EA1@tct.com>, chip@tct.com (Chip Salzenberg) writes: > According to hrubin@pop.stat.purdue.edu (Herman Rubin): > >Satisfysing my requests would require nothing of the sort. I see no > >reason why I should have to hire a compiler writer for each augmentation. > > You're right, of course. > > Nor can I see a reason why we should endure endless tirades about how > the all-singing all-dancing Herman Rubin Language Compiler will solve > the world's problems, when you STILL haven't written ... > > [wait for it] > > the SPECIFICATION. > > Give us a spec, and we'll have something to discuss. Why spend all > this time yammering about a hypothetical compiler, when that same > effort expended in spec-writing could produce a REAL IMPLEMENTATION? I have several times responded to this type of posting in email, and have not even received clarification of my questions. 1. I am not quite sure what you mean by a specification. 2. To the extent that I understand it, I do not think that one even should be produced. Now, I do not mean that it is all a mystery. I will try to clarify the problem and objectives. I envision a user as having some things to be done, which for purposes of discussion we shall call transformations. There are many ways of producing these transformations by sequences of operations. The compiler cannot be expected to know how to do this; the user must carefully instruct it by the program. Now this means that the program may present the compiler with alternatives to assess for speed, memory requirements, etc. For convenience, the arguments of these operations may be typed. The collection of types is at the user's disposal. This allows overloaded operations. However, it may be convenient to have a few "standard" types. Next, these operations may be further decomposed into sequences of other operations, sequences of machine instructions, etc. The user should have control over this. There may be a default set of operations, but the user should have essentially free rein over operation symbols, etc. Again, it is possible that there will be situations in which altenate translation sequences should be made available to the compiler. I have not specified a language, but a frame on which to hang a language. Unlike the present languages, this frame does not declare certain operations, such as + - * / & | ~ ^ ** << >> as THE primitive operators, but allows free extension of the notion of primitive operator. If a user wishes to use [) as an operator symbol, there is no bar to this. If the user wishes to deliberately override types, likewise. If the user wishes to define an operation in a maner using assembler instructions, transfer on overflow, etc., which cannot be conveniently done with the present "portable" primitives, go ahead. I have given examples of this. To some extent, this was done by the AUGMENT preprocessor to handle multiple precision arithmetic, but this was limited. This essentially unrestricted translation phase can be combined with whatever optimization techniques are to be further implemented. Even here, allowing the compiler to lay out alternatives to the user and get input can be desirable. -- 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)
msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) (05/04/91)
In <11813@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >I have not specified a language, but a frame on which to hang a language. >Unlike the present languages, this frame does not declare certain operations, >such as + - * / & | ~ ^ ** << >> as THE primitive operators, but allows free >extension of the notion of primitive operator. If a user wishes to use [) as >an operator symbol, there is no bar to this. If the user wishes to deliberately >override types, likewise. If the user wishes to define an operation in a maner >using assembler instructions, transfer on overflow, etc., which cannot be >conveniently done with the present "portable" primitives, go ahead. Sounds vaguely (buzzword alert) object oriented to me. Except that you not only don't want to pay the usual performance penalty of OO languages, you want a speed boost over plain C or whatever. And you don't want to write any assembly (although another user might)? (I'm assuming that this is a modified C. If you like Ada better, replace `C' with `Ada' in the following text...) What if you could define new operations example: @ is defined here as some complicated function of two variables using either C or assembler later on you get to write stuff like this: x = y @ z The code for the @ operation is automagically inlined. Appropriate ifdefs would let you include in the source file several versions of the @ code, perhaps in portable C and two different assembly languages. You (H. Rubin) would like (I think) to be able to write several different but equivalent versions in portable C, and have the compiler automagically select the one it can produce the best code for. This sounds like it could be hard. Perhaps you could include some test examples, and the compiler could compile each version and benchmark it? Am I getting close? -- < Michael Pereckas <> m-pereckas@uiuc.edu <> Just another student... > "This desoldering braid doesn't work. What's this cheap stuff made of, anyway?" "I don't know, looks like solder to me."
hrubin@pop.stat.purdue.edu (Herman Rubin) (05/04/91)
In article <1991May3.195856.13671@ux1.cso.uiuc.edu>, msp33327@uxa.cso.uiuc.edu (Michael S. Pereckas) writes: > In <11813@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > >I have not specified a language, but a frame on which to hang a language. > >Unlike the present languages, this frame does not declare certain operations, > >such as + - * / & | ~ ^ ** << >> as THE primitive operators, but allows free > >extension of the notion of primitive operator. If a user wishes to use [) as > >an operator symbol, there is no bar to this. If the user wishes to deliberately > >override types, likewise. If the user wishes to define an operation in a maner > >using assembler instructions, transfer on overflow, etc., which cannot be > >conveniently done with the present "portable" primitives, go ahead. > Sounds vaguely (buzzword alert) object oriented to me. Except that > you not only don't want to pay the usual performance penalty of OO > languages, you want a speed boost over plain C or whatever. And you > don't want to write any assembly (although another user might)? I do not mind using machine operations, but I do not like to write the vague and confusing, and different for different machines, assembler symbolism. On any machine, one of the things I would do is to include my own notation for the machine operations, and the corresponding translation. I have no problem whatever in thinking in terms of machine operations where necessary, and I have no objection to using them. But we no longer need to write these operations in a form designed to be easy for the assembler to parse. > (I'm assuming that this is a modified C. If you like Ada better, > replace `C' with `Ada' in the following text...) > What if you could define new operations > example: > @ is defined here as some complicated function of two variables > using either C or assembler > later on you get to write stuff like this: > x = y @ z > The code for the @ operation is automagically inlined. > Appropriate ifdefs would let you include in the source file several > versions of the @ code, perhaps in portable C and two different > assembly languages. Almost right! I may wish to define @ in terms of other things defined. It may be desirable to use primitives which even mess up coding, such as overflow. > You (H. Rubin) would like (I think) to be able to write several > different but equivalent versions in portable C, and have the compiler > automagically select the one it can produce the best code for. This > sounds like it could be hard. Perhaps you could include some test > examples, and the compiler could compile each version and benchmark > it? > Am I getting close? One of the claims of the posters is that compilers can greatly outdo humans. They can only outdo humans if they can take into account what the humans can consider. This they cannot do without being told. Now how does a compiler operate now? It parses the code, translates into its primitive operators, decides how to make things more efficient, which in some cases requires consideration of alternatives (Simple example: on the CDC6600, there were three "standard" methods of putting 0 in an X-register. These used different functional units, and each functional unit could only do one thing at a time, and the units were used for other purposes. So the compiler would decide which alternative to use.), and then optimize the resulting hardware instruction code. This means that the programmer must adequately instruct the compiler on the possible ways to do things if the compiler is to do well. Automagic selection is certainly an important part of optimization. -- 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)
chip@tct.com (Chip Salzenberg) (05/07/91)
According to hrubin@pop.stat.purdue.edu (Herman Rubin): >In article <282002D1.EA1@tct.com>, chip@tct.com (Chip Salzenberg) writes: >> Give us a spec, and we'll have something to discuss. Why spend all >> this time yammering about a hypothetical compiler, when that same >> effort expended in spec-writing could produce a REAL IMPLEMENTATION? > >I have several times responded to this type of posting in email, and >have not even received clarification of my questions. Rubin-san has not E-Mailed me on this subject -- but no matter; he chooses to carry on his correspondence in comp.arch. >1. I am not quite sure what you mean by a specification. A detailed and precise description of the desired compiler features and input format. It would tell me what I need to know to write a HROL (Herman Rubin Oriented Language) compiler. Let me give a tiny example. To define a binary operator <op> to be supported by a machine instruction <inst>, code the following: OPERATOR "<op>" ; { BINARY | UNARY } ; PRECEDENCE { AFTER | BEFORE | SAME } <other-op> ; ARGUMENT 1 (<type>, ...) [ IN ("reg1",...) ] ; [ ARGUMENT 2 (<type>, ...) [ IN ("reg2",...) ] ; ] INSTRUCTION "<inst> ARG1,ARG2" ; RESULT (<type>) IN ("reg") ; Of course, this tiny example doesn't address indirection, or processor addressing modes, etc, etc. But it does give the flavor of what I mean by "specification". Got the picture yet? -- Brand X Industries Sentient and Semi-Sentient Being Resources Department: Because Sometimes, "Human" Just Isn't Good Enough [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>