Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!hao!husc6!rutgers!iuvax!pur-ee!j.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc,comp.software-eng Subject: Re: Software Technology is NOT Primitive Message-ID: <598@l.cc.purdue.edu> Date: Thu, 29-Oct-87 06:21:01 EST Article-I.D.: l.598 Posted: Thu Oct 29 06:21:01 1987 Date-Received: Wed, 4-Nov-87 02:09:29 EST References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <5084@utah-cs.UUCP> Organization: Purdue University Statistics Department Lines: 86 Summary: I look at what the compiler produces Xref: mnetor comp.lang.misc:820 comp.software-eng:28 In article <5084@utah-cs.UUCP>, shebs%defun.uucp@utah-cs.UUCP (Stanley T. Shebs) writes: [Which of the tasks to be solved should the software developer consider? On one [machine there may be hundreds or even tens of thousands of users. Some of [these users may have dozens of different types of problems. > > Then the software developer has dozens of tens of thousands of tasks to solve! Definitely not. The job of the software developer is to produce the flexible tools so that the thinking brain can do the job. I think that this can be done by producing typed, but not stongly typed, assemblers with a reasonable syntax (for example, instead of using OPMNEMONIC_TYPE_3 z,y,x on the VAX, if x, y, and z are of type TYPE I want to be able to write x = y OPSYM z where OPSYM is the operation symbol (+,-,*,etc.) The user should also be able to produce macros in the same format. The recent discussion of 16 bit * 16 bit = 32 bit is an example of this. [And should we use the same algorithm on different machines? [I, for one, would question the intelligence [of those who would attempt to enforce such restrictions. > > I find it interesting that the people who have been programming the longest - > numerical analysts - are exactly those who use dozens of different algorithms > to solve the same problem, each with slightly different characteristics. > Could mean either that multiplicity of algorithms is coming to the rest of > computing soon, or that numerical analysts haven't yet found the correct forms > for their algorithms... > I suggest that this means that numerical analysts realize that the algorithm to use depends on the circumstance. A reasonable driver uses dozens of different algorithms in a single trip. > [The VAX has twelve general-purpose registers available. If I write a program [which uses eleven registers, I object to the compiler, which does not need any [registers for other purposes, only giving me six. > > How do you know it "does not need any registers for other purposes"? Are you > familiar with the compiler's code generators and optimizers? Writers of code > generators/optimizers tend to be much more knowledgeable about machine > characteristics than any user, if for no other reason than that they get the > accurate hardware performance data that the customers never see... > I have looked at the code produced. In it, the registers which it will not allow me to use are not used. Therefore, I can see no reason why I should not be allowed to use them. [An obvious example of this is [...] the denial of such [simple elegant ideas as goto. > > "Goto" is neither simple nor elegant on parallel machines. Neither is if ... then...else. Both should be avoided on those machines, and replaced by different procedures. Again, non-portability. There is consider- able effort going into designing algorithms which can take advantage of parallelism and vectorization. For many purposes, I would not even consider using the same algorithm on the VAX and the CYBER205. There are good vector algorithms on the 205 which would be ridiculous on the CRAY, which is also a vector machine. > [The bit-efficient algorithm above starts out [with a case structure; I immediately observed that, by 99.999% of the time [keeping the case as a location only and using goto's, the code would be [considerably speeded up without any loss of clarity. > > OK, this is the time to use assembly language. What's the problem with that? > It's the accepted technique; no one will fault you for it. > This is the time to use goto's. Any language should allow it. > > No silver bullet... I agree. > [<< Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 [> Lawrence Crowl 716-275-9499 University of Rochester [Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 > > stan shebs > shebs@cs.utah.edu -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet