Xref: utzoo comp.arch:17060 comp.lang.misc:5143 Path: utzoo!attcan!uunet!snorkelwacker!usc!ucsd!network.ucsd.edu!celit!dave From: dave@fps.com (Dave Smith) Newsgroups: comp.arch,comp.lang.misc Subject: Re: It looks like he's at it again! Message-ID: <9911@celit.fps.com> Date: 11 Jul 90 21:37:11 GMT References: <2328@l.cc.purdue.edu> <1990Jul10.072443.4844@cs.UAlberta.CA> <9896@celit.fps.com> <2338@l.cc.purdue.edu> Sender: daemon@fps.com Reply-To: dave@fps.com (Dave Smith) Followup-To: comp.arch Organization: FPS Computing Inc., San Diego CA Lines: 86 In article <2338@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >In article <9896@celit.fps.com>, dave@fps.com (Dave Smith) writes: >> For 90% of programmers assembly is more trouble than it's worth. (Though I >> do remember that on the Apple II I prefered assembly to Applesoft because >> it was easier to make the machine do what I wanted :-) ) Computer >> manufacturers market to the 90% and will build machines suited to the 90%. > >I would certainly agree that for 90% of the programming assembly is more >trouble than it is worth, maybe a lot more. I disagree for 90% of the >programmers. And even these programmers use library tools, which should >not be in that fraction. Those programmers, and users of their programs, >benefit from efficient software produced by the few others. I would not >want my automobile designed by those who know as little automotive engineering >as I know. I would hope that there are "unorthodox" people on the design team, >who can think of how to improve things by doing the "unheard of." Don't get me wrong. Assembler is fine for some tasks, however, when it comes down to a tradeoff between making it easier for the compiler to do something or easier for the programmer to do something (in assembly) the compiler wins because the compiler is what's going to be used most of the time. In order to be successful in the processor game you have to sell lots of CPU's and this means running fast on compiled code. The number of users who are going to look at your assembler and go "Ick, that's really grody" and have that be a major point with them are few. The number who want to see how fast your code goes out of the compiler with no hand-tweaking are much larger. I've been working at FPS (then Celerity) for almost three years doing systems programming day in and day out. I still haven't gotten around to really learning the assembly code for the Accel processor. About twice a year I have to go find someone who does know the assembly code well to help me figure out why something is happening. The rest of the year I do my work in C and it all works fine. Now, we're moving a lot of our stuff over to the SPARC and Accel knowledge will not be very helpful. The time I've spent honing my knowledge of C and Unix internals instead, however, is still very valuable. Would learning Accel have been a waste of my time? I think so, since the effort versus value, for me, would have been quite high. >How many of the 90% do not even know of the existence of these possibilities? >Are we making it difficult for them to understand them by teaching the present >HLLs? I've been of the opinion for a long time that assembler should be taught first so that a student does have an idea of what the machine does when it comes time to learn what a pointer is, or dynamic memory, or data alignment. Programming in an unstructured environment where you have to manage the stack and all your memory by hand also gives you a much greater appreciation of all the things an HLL does for you when you move on to one. Besides tweaking for speed and messing with things the language is trying to do for you (like stack management) I don't know of too many things that assembler is really good for. Any other applications? >I have advocated that the HLLs remove their limitations in such a way as >to enable easier inclusion of machine features into the program. Also, that >the assembler syntax be changed to make the use of these features much easier, >so that Dave Smith's observations about the Apple II can be readily used. In >addition, that computer manufacturers include the hardware; computing chips >are a small part of the cost of computers, and even a VCISC coprocessor would >be relatively cheap. Place an order for 5 machines and tell us you want a VCISC coprocessor and you'll fund the development and we'll be happy (I think, I don't work in management (pun not intended)) to build you one. Until the marketplace tells us that is what it wants, though, we're not going to do it. Marrying your code too tightly to the hardware will probably come back to bite you anyhow. Are you using today's hardware to run your code on, Herman, or is it running on an older machine because that's what it's all been hand-tuned to run on? If it will run faster (without tweaking) on a newer machine then you've already lost. High level languages are what allows the kind of competition that's going on today between computer manufacturers. If customers were unable to jump ship when someone else's box ran faster there would be no incentive to provide a better box. Assembler's good for when you want to get down and dirty, but the percentage of your programming that should be done in assembler is so small that there's no real point in making assembly easier at the expense of speed or ease in the rest of the code. -- David L. Smith FPS Computing, San Diego | ucsd!celerity!dave or dave@fps.com All opinions disowned by me and FPS unless financially lucrative (to me, not the litigator)