Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!alberta!cdshaw From: cdshaw@cs.UAlberta.CA (Chris Shaw) Newsgroups: comp.arch Subject: It looks like he's at it again! Summary: Herman, shut up! Message-ID: <1990Jul10.072443.4844@cs.UAlberta.CA> Date: 10 Jul 90 07:24:43 GMT References: <2328@l.cc.purdue.edu> Sender: news@cs.UAlberta.CA (News Administrator) Distribution: comp.arch Organization: University of Alberta, Edmonton, Canada Lines: 82 In article <2328@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >In article <3627@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: > [Example of weird instruction omitted.] > >But there are lots of reasonable hardware >instructions which have either disappeared or were rarely implemented. The problem is, Herman, you're one of the very few people who are interested in these well-known "reasonable instructions". The other problem is that you know diddly about building programs much longer than 1000 lines, I'll wager. Anybody who gripes about the slowness of his machine, and who can afford to spend the substantial amount of time it takes to tweak code for the last drop of CPU power is dealing with programs that are pretty small. Usually. The basic problem with assembly coding by hand vs assembly coding by compiler is that IT DOESN'T SCALE. There are extremely limited application areas where coding by hand is much faster, and you, Herman, live in one. Just because you have purple lenses on your glasses doesn't mean the world is purple. Just because you can code for speed better than your compiler can doesn't mean that more than a tiny minority "out there" can do the same. Plus assembler is a nightmare unless one of three things is true: 1: The project is performed by 1 person. 2: The project is small (less than 5000 lines) 3: All modules adhere strictly to a call-return convention. In other words, you can do it, but it's extremely hard work if you're building something non-trivial. Anywhere up to 1000 lines of code is trivial. Besides you're still going to suff a drop in productivity vs HLL's. You brought up the example of computer chess recently. The fact of the matter is that unless you are an international chess master, the program Deep Thought will beat you. Why did I mention this? Well, the major reason Deep Thought beats excellent chess people is because of its specialized hardware. The program operates by a well-known brute force algorithm. My main point is that Deep Thought would be useless if the program relied on some set of greasy assembler tweaks on some two-bit general purpose CPU. Maybe you operate in just such a niche, where special purpose hardware is what you should be using. In particular, the 34010 has some of the following things in its instruction set. The stuff marked "Check" is in this graphics chip, Herman, all you have to do is buy one & check it out. No floating point on the 010, though, only the 34020 and 34082 combo. >Examples of simple instructions in hardware, much more expensive in software, >and for which I know of "reasonable" applications. > >Check Multiplication of integers with both most and least significant parts > of the product available > >Check Division with quotient and remainder simultaneously > > Division of floating point numbers, with integer quotient and > floating point remainder > >Check In the above two operations, allowing the choice of which quotient > and remainder, depending on the signs of the arguments. > >Check Obtaining the spacing between the ones in a bit sequence. In the > algorithms I would produce, this can be a major operation. > >Check The use of overflow and carry tests. > > Fixed point arithmetic. > > Multiplication of a floating point number by a power of two, not > using the multiply unit > > Better conversion between integer and floating point. And if you're going to rant on (as you always do) about misfeatures in well-known programming languages, why don't you get off your duff and prove all us fools wrong? Show conclusively that modern HLLs stink by designing one that doesn't stink. Do the same for assemblers, too. So quit your bitching already. >Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 -- Chris Shaw University of Alberta cdshaw@cs.UAlberta.ca Now with new, minty Internet flavour! CatchPhrase: Bogus as HELL !