Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!think!barmar From: barmar@think.COM (Barry Margolin) Newsgroups: comp.misc Subject: Assembly language (was: Re: Another 1.3 wish.) Message-ID: <7197@think.UUCP> Date: Mon, 3-Aug-87 15:45:48 EDT Article-I.D.: think.7197 Posted: Mon Aug 3 15:45:48 1987 Date-Received: Tue, 4-Aug-87 05:22:02 EDT References: <8707190424.AA10158@cogsci.berkeley.edu> <434@sugar.UUCP> <3664@well.UUCP> Sender: news@think.UUCP Reply-To: barmar@godot.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge, MA Lines: 115 In article <3664@well.UUCP> ewhac@well.UUCP (Leo (My glasses have gate arrays) Schwab) writes: > Expressing a new or complicated algorithm in a high-level language >is a useful endeavor. It allows you to clearly formulate and express the >problem/procedure in machine-interpretable form. However, once you have the >basic algorithm down, your next step should logically be to translate that >algorithm into assembly by hand. Compilers can do a good job, but never as >good as a human. The point is not that humans can do a better job, but whether they should bother. The effort involved in converting a large program into assembly code can be enormous. A program that takes more than a second to compile on a computer will probably take days or weeks for a person to translate, plus more time to debug it again to make sure the conversion was done right. Is it worth it to get a tiny improvement in the code? It also takes a pretty good programmer to beat the compiler; wouldn't his time be better spent designing or implementing the NEXT program? There are lots of things humans can do better than machines. Some of the best cars in the world are hand-built in small shops. However, it takes months for them to fill an order. Detroit and Japan can manufacture hundreds of cars on their assembly lines in the time these shops can make one. If you're rich, not in a hurry for a car, and want something to show off, you can get a handmade one; if all you care about is getting from here to there, the factory jobs will do just as well. Another consideration is that programs must be read and understood by other programmers. This is hard enough to do when the code is in a high level language, but highly-tuned assembly is the hardest. Remember, someone later on is going to have to fix a bug in or add a feature to that code. > I point to accomplishments of the past. SpaceWars fit in 4K of core >on the PDP systems (as I understand it). I have a copy of a very powerful >music program for the 8080 that runs in 4K. I have a copy of an 8080 BASIC >interpreter that has multi-line user-defined functions, IF-THEN-ELSE, >automatic structure indenting, error trapping, formatted I/O, and matrix >functions. It's 15K in size, and runs great in 32K. Sonix is all assembly >code, and its core is 29K in size (I think). > > Meanwhile, MicroSlush is proud of the fact that the core of their >AmigaBASIC interpreter runs in "only 80K" of RAM. Truly pathetic. Once upon a time memory was expensive and machines were slow, so it was necessary to bum code in order to make the programs usable. Great accomplishments of the past are easy to come by. Columbus discovered America using ships that used no fuel and created no pollution. The pioneers spread across this country using covered wagons. Now car manufacturers are proud when they can make a car that gets 30 MPG and creates who knows how much carbon monoxide. Is that pathetic? No, it's just different. > I'm not knocking high-level languages. I use them a lot, and would >be very lost without them. In fact, if you know how a particular compiler >behaves, you can get some very efficient code out of it. But it should be >agreed that assembly has its place in the world, and should not be >arbitrarily poo-poohed. And I'm not knocking assembly (it was my favorite when I was in high school playing with PDP-8's and Z80's), but I think its time has mostly passed, and it should be allowed a peaceful retirement. Yes, there are times when it should be called back to active duty, such as when a highly-used routine needs to be super-optimized. They say that 10% of the code is used 90% of the time; there should rarely be any need to bum code in the other 90%. The original poster was pointing out that some system REQUIRES certain operations be done in assembler, presumably because no high-level-language-callable library routine interfaces are provided for them. I don't know what machine was being discussed (I've only seen the excerpts in the message I'm responding to), but I know that the Macintosh is guilty of this in some places. I think you would agree that assembly should never be forced upon someone; if they want to code or recode in assembly to conserve on computrons, fine, but it should be the PROGRAMMER's choice. >>Fear not, you're in good company. Donald E. Knuth (yes, that Knuth) is one >>of the worst offenders. His "Art of computer programming" is almost useless >>for day-to-day use because of "MIX". [ ... ] > > You didn't read his introduction to the book. It's a cookbook of >algorithms, with sample implementation in a hypothetical language. It's up >to you to translate the *algorithm*, not the code, over to what you want. I >suspect he invented a hypothetical language to force his readers to use the >algorithms he presented, not just his code. If he'd written it in Pascal or >something, people would be tempted to drop the code into a machine >unmodified, and they wouldn't learn anything. Anyone can transliterate >code, but can you use the *algorithm*? I agree with the original poster, the programs (but not the algorithms) in Knuth are useless. I forgive him because a) the books are about the best reference works available for the algorithms, and b) they were written fifteen years ago (I think), when most systems programmers still programmed in assembler. I'm sure he would not invent MIX if he were writing those books now. If he wants to force people to use the algorithms and not the code, he should simply LEAVE OUT the code. Before each program he describes the algorithm it implements in detailed English. If he really wants to include programs, but doesn't want people to simply copy them, he could write them in pseudocode or Ada(tm). Also, none of his algorithms are very large, so it doesn't take much effort to understand the programs. I think he was crazy to include the MIXAL assembler written in MIXAL in the book -- do you really think anyone would bother to convert it? Finally, if someone wanted to copy his code, it was pretty easy, as MIX is similar to many machines of the day, so a mere transliteration would not be difficult. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar