Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!agate!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!harrier.ukc.ac.uk!mr3 From: mr3@ukc.ac.uk (M.Rizzo) Newsgroups: comp.sys.amiga.programmer Subject: Re: Good programmers and assembly language (very long) Message-ID: <7227@harrier.ukc.ac.uk> Date: 5 Apr 91 13:44:42 GMT References: <7214@harrier.ukc.ac.uk> <2220@pdxgate.UUCP> Reply-To: mr3@ukc.ac.uk (M.Rizzo) Organization: Computing Lab, University of Kent at Canterbury, UK. Lines: 450 I think in his reply to my post Mr. Baird twisted a few of the things I said and put them in a different context. Here goes - In article <2220@pdxgate.UUCP> bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: >mr3@ukc.ac.uk (M.Rizzo) writes: > >I don't think knowledge of the hardware is as seperable from computer >programming as you might like to think. When designing an efficient >program, it pays to take heed of the hardware's capabilities and >limitations. When designing an efficient program, the first important thing to do is choose/devise efficient algorithms. A person who can get the required efficiency from a better algorithm is better than one who uses an inferior algorithm in assembler. >is essential. Designing a filled polygon three dimensional game with a >frame rate of 60 frames per second requires the programmer to know the >hardware. In fact, it has to be determined if the hardware is even >capable of a frame rate that fast. Yes, agreed, but there the programmer is delving into hardware. It is not a requirement of a general programmer to know the hardware in any detail. An arcade games programmer might have to go into it - but its not programming - its knowledge of machine architecture, and many people can do perfectly good jobs without it. >... Let me say >that designing a program for an operating system such as Unix and >designing a program for a machine such as the Amiga is vastly >different. On most Unix systems you won't have to worry about your >application running out of memory and/or resources. Instead you worry >about the allocation/deallocation of resources and the efficiency of >the program. Designing a program on the Amiga, however, requires more >intimate hardware knowledge. I think the Amiga OS knows how to handle resources just fine - so I'd say it requires knowledge of the OS not the hardware. How is an "intimate knowledge of the hardware" supposed to help you with checking if you've got enough memory to proceed, or whether a particular resource is available or not. >Doesn't knowing >assembly language imply some knowledge of the hardware? Ick! It implies knowledge of the processor not ALL the hardware. What I was talking about with Mr. Schwartz was whether programming things such as the blitter, copper, disk controller etc directly had anything to do with assembly language programming or not. It is NOT related to assembly language programming but to knowledge of the Amiga's hardware. > Most of >the languages you mention above are nice on larger systems, but on an >Amiga you're wasting your time. I note that you most conveniently did not include my original text here. Did I say anything about the Amiga ? I was just listing the languages I've had experience with because Mr. Schwartz was asking me whether what I was saying was my own opinion or whether some teacher brainwashed me. DON'T CHANGE THE CONTEXT OF WHAT I SAY PLEASE ! > [Chunk of irrelevant stuff about languages used on Amiga deleted] >Now don't get me wrong. I'm not an advocate for take over the machine >and trash the OS. I figure if you have to do it, then do it, otherwise >leave it alone. Again totally irrelevant to the discussion. >As for your knowledge or assembly language, I can only feel remorse for >the person who knows 8086 assembly and 6809 assembly. If that's where >you developed your opinion on assembly language, no wonder it's so >horrible. Anything with less than 4 32-bit GENERAL PURPOSE registers >ought to be junked. Your use of the word "junked" only makes you sound immature. There are a lot of things you can learn using any processor - the basic principles of assembly language are the same. Admittedly, there may be some tricks that you can do with one processor and can't do on another - but calling the 8086 and 6809 (great chip back in the days of the good old Dragon 32 :-) junk only shows your ignorance. Have you ever even used them ? >The Unix community's opinion (of which most of us are part) bears very >little relevance to programming an Amiga. Again I am not talking about the Amiga specifically - I am talking about programming in general. In any case I can't agree with the above statement. Do you think that the only thing people do with Amiga's is write games for them ? Look at Matt Dillon's excellent programs for the Amiga - don't tell me he wasn't influenced by UNIX ! >Let me ask you, how many of these Unix hackers could actually program >an Amiga game, if their complexity is so inferior to that of their Unix >projects. First of all I was talking about programming in general NOT only games. Secondly, let me ask you how many Amiga game programmers would be capable of working on a really large-scale project involving very complex algorithms, thousands and thousands of lines of code, working with dozens and dozens of people, and a highly complex problem domain. Mr. Schwartz mentioned use of "source-code libraries" which is absolutely ridiculous! What happens if two modules both include the same library then eh ? Or maybe he doesn't organize his code into modules but just has one massive listing which he assembles every time, implying that he probably doesn't know how to use such tools as MAKE. >Mr. Schwartz is a game programmer, and from what I've seen >of his postings he's probably pretty good at it. I don't doubt that and never did. But that does not make him a pretty good programmer in general. Some of the things he said in his reply to my original post were very confused, like saying the benefits of high-level languages over assembler decrease with larger projects (see below). >As for his .sig, I >suppose you'll be calling AT&T next to see if they've licensed the BS >I'm writing now? You haven't supported Mr. Schwartz' statement "Assembler separates ..." one bit. Try and give support for it instead of saying silly things. >Writing in assembler in Unix is a sin? Gee boss, parts of the OS are >written in assembler, guess we'd better junk it! Very funny. There are obviously parts of the OS written in assembler but I'm equally obviously talking about applications. >Just how did a >seperate convention for 68000 assembly come about, if nobody ever uses >assembly with Unix? Assembly is used in commerical Unix products that >need the extra speed it offers. About the only reason public domain >products don't use it is it's inherent unportability. Why does Sun >try to remain binary compatible through most of their line? Because, >some of the stuff can't just be ported and recompiled on a new machine. OK I admit that my statement was a bit too strong. Nevertheless, most UNIX programs are written in C. Assembler is rarely used. Many UNIX programmers (probably the majority) do not use assembler. >I think Mr. Rizzo is biased against >assembly language programmers, and is somewhat stereotypical in his >judgement that if you use assembly you are less than a real programmer. I think you need to attend a course in logic. I said that being able to use assembler does not _neccessarily_ make you a better programmer than one who doesn't. This DOES NOT IMPLY that if you use assembly you are less than a real programmer. I NEVER said or implied such a stupid thing. >Why people persist in claiming that assembler code is unmaintainable I >just can't figure out. If your assembler code is unmaintainable then >it's your own coding techniques that are at fault. Assembly provides >macros, definitions, etc. that give it support facilities that rival >most higher level languages. If a programmer uses equates for constants, >macros when needed, etc., that programmer is writing efficient and >maintainable code. I wouldn't say unmaintainable, but definitely much less maintainable than high-level programming languages. For a start, code is longer and therefore less concise - the more split up into low-level instructions, the less concise a program is - you can't get away with that. There is inadequate support for abstraction, data hiding, re-usability (e.g. polymorphism in some more recent high-level languages - I'll bet you that half the game programmers on the Amiga haven't even heard of such a thing) Do macros and equates make programs maintainable ? Readable maybe, but not exactly maintainable. For maintainability you need to to be able to change parts of a program without affecting the rest of it. You need local environments at the least and parameter passing mechanisms to hide the implementation of a routine and reveal only its interface. >I believe that there is some capability in the Sparc Stations to run >older Sun executables. Regardless, it is nice to use the OS when it >is effective, but chastising someone who has no choice as to what >language to use because of changes that _may_ happen borders on the >ridiculous. I don't think anyone would reasonably expect most games >to survive a processor transition like that. I don't either but then again I never said so. >Here's a small list of things that I can come up with that require >knowledge of assembly: writing an OS, writing device drivers, writing >_fast_ programs (for instance, Sculpt-3D had to be fast. They didn't >use the best algorithms in the world, however, so it should have been >faster), writing compilers (yeah, those things you use in preference >to assembly). Inherently, anthing that needs to be either low level, >or fast. Did you notice how most colleges require some sort of >course like Computer Organization? (a class dedicated to familiarizing >computer science majors with what makes the hardware tick) Do you >suppose they have this class just to irk you? Any self-respecting Computer Science graduate knows about Computer Architecture and programming in assembly language (no need for any large-scale project mind you - just an appreciataion). But we are talking about what makes a good programmer. >Well, if it is an application written for X, OS/2, or other windowing >system, there is probably an event driven setup, which, although not >providing a straight port, would provide a somewhat easier port. > >However, given the context of the argument (that is, games) you The context of the argument is NOT games. I made that very clear in my last post. >Assembler sure as hell doesn't hurt a programmer, Never said it did >and remaining ignorant of other methods or writing applications is >never a good thing. Never said it was. But it isn't neccessarily a bad thing not to learn assembler. >I, myself, have exposed myself to a variety of languages. >None of them have made me into a "good" programmer, but I feel that >all of them have made me a "better" programmer. Agreed. >Assembler seperates the knowledgable from the ignorant. Rubbish. This slightly contradicts what you said above. You can't use one property to distinguish the knowledgeable from the ignorant. A language like Prolog demands more intelligence than does assembler but it still doesn't distinguish the knowledgeable from the ignorant. >If that means >the men from the boys, then yes. Anyone who intends to never learn >assembly is just perpetuating his/her own ignorance. Sorry but this is is a load of BS. >Re-inventing the wheel is an important concept in learning anything. I >would say that one of the things that makes a good programmer is >education, and refusing to learn is certainly a sign of a lack of >education. I know programmers who don't want to sulley themselves with >the dirt of programming in assembly language. These are the same >people who have no desire to learn anything about the hardware they use, >and no desire to try new (or old but as yet unlearned) ways of doing >things. No human can learn everything. If you argue that people who use high-level languages should know low-level languages, then I tell you that every assembler programmer should have knowledge of the inner workings of the microchip ... all the way down to its molecules and all. You know programmers who don't want to sulley themsleves with the dirt of programming in assembler - well I know programmers who are afraid to even try to learn a bit about Prolog. So what ? People learn the things they NEED to learn. If you want to write fast games and feel you NEED to know assembler fine. But not everybody needs it - the majority of people don't, and that doesn't neccessarily make you any better than they are. >Tell me, did you start math at the Calculus level (or above), or did >you develop from earlier tools such as Algebra? Did you start maths with a proof of why 0 + 0 = 0. No because it involved ideas which were too hard to understand at that age. But math students see the proof for 0 + 0 = 0 in the first year of their BSc, even though they've been using the result all their lives. Also some people can use 0 + 0 = 0 without ever needing to know why. >>the blitter as part of a larger AMIGA project written mostly in C. > >I guess that one experience wasn't enough to show you that 8086 & 6809 >assembly is hardly worth considering as assembly. For a real laugh, >try assembly on a PDP-11. The PDP-11 holds an important place in the history of computing. Laugh as much as you want - I won't and many others won't either. >>>>The people with the REAL programming skills are those with a >>>>good understanding of software engineering skills. Assembler >>>>cannot teach you these skills - it is totally hopeless as far >>>>as conciseness, readability, portability and abstraction are >>>>concerned. So for those people who ONLY know assembler and think >>>>they are top programmers, sorry, but as far as I'm concerned >>>>you've still got a long way to go. > >So, having REAL programming skills denies any ability in programming >assembly? I really HATE it when people misquote me. I never said that. I said that it can't teach you certain concepts. People who do understand these concepts are no less competent if they can program in assembler. Sheesh ! >Of course assembly isn't the only language worth learning, >as Mr. Schwartz points out himself. I feel sorry for people who >think they're REAL programmers with REAL skills who can't even >acknowledge the use of a REAL programming language. I think that any decent programmer should at least be conscious of other types of programming languages other than imperative ones. I think that is just one of many more important things that make a complete programmer than being able to program in assembly language. There are programmers who don't even know that totally different approaches to programming exist. All they know about is purely IMPERATIVE languages like assembler, C, PASCAL etc and know nothing about declarative, functional or object-oriented approaches. >>>I've programmed in lots of other languages besides assembler. >>>I've used Forth, Pascal, PL/I, 'C', Fortran, Basic, TAL, and >>>a few others. I've written compilers, assemblers, operating >>>systems, and applications (like music programs). No matter >>>what language I use, the knowledge of assembler language has >>>always helped me make better programs. The knowledge of good >>>algorithms helps me make better programs, too, even in assembler >>>language. >Exactly my feelings on the matter. Assembly language is worth knowing, >without a doubt. Agreed. > You aren't a REAL programmer until you've learned it. Rubbish ! >Assembler is a critical language. More rubbish ! >If you don't learn assembler, >you're missing out on the only way to do some programs. (Such as OS >programming) Not all programmers HAVE to know how to do (low-level) OS programming. >... Miranda ... >lets you do a quick sort in 3 lines. Let's see you write a program >that renders a 60 frame per second arcade game on the Amiga, with it. >In fact, let's see you do the above with anything but assembler. You missed the point and are again twisting my intentions. I was simply demonstrating to Mr. Schwartz that the benefits of high-level languages INCREASE not decrease (as he said) as the project gets larger. Read carefully ! >Hell, at least I cn do a quicksort in assembly. Hell I can spell "can" properly :-) Well I can too coz' I did it in Pascal and it shouldn't be much different from that because its imperative. I didn't because my Amiga and PC are a few thousand miles away from where I am now. At the moment I only have SUN's and DEC's at my disposal and I don't have the time to get into assembly on them. >>In assembler, the same quicksort routine would require several lines, >>definitely more than 40, and then again for numbers only not for an >>arbitrary type. I'd liked to have included an assembler version of >>quicksort here but I didn't have the time - it would take much >>longer. If anybody has done this I'd like a copy please. > >>At a glance, a Miranda programmer would know what the function qsort >>did (even if it was called foo instead of qsort). Given the assembler >>equivalent, an expert assembler programmer would take time to figure >>out what the list of instructions was doing. > >Yes, but sometimes you pay for readability with performance, and True but out of point yet again. >most programs that use quicksorts probably don't need the speed as >much as an Amiga arcade game. Er - I think there a lot of games that could make use of quicksort actually, or would you prefer to use bubble sort instead, simply because its easier to write in assembly. >>As programs get more complicated, assembler loses conciseness and >>readability more quickly than high-level languages. Also it takes >>longer to express algorithms in machine code than it does in >>high-level languages and this gets worse as one tackles more and >>more complex and larger problems. > >This isn't necessarily true. Yes, you program gets longer (and >therefor occupies more physical space), but if you've written a >general purpose quicksort routine in assembly, there isn't much >reason to code it several times. I suspect that when you use it, >you'll by using a macro that looks remarkably similar to calling >quicksort in a higher level language. Of course, I can always A macro ? I hope you wouldn't be putting ALL the quicksort routine in a macro 'coz if you used quicksort 10 times in your program you'd get the code duplicated 10 times. And even if you just used the macro to load registers followed by a jump to a subroutine, it would be pretty messy and still involve code duplication. >-- >********************************************************** >* Of course, I doubt "Software Engineering" tells you * >* everything you need to know to take full advantage of * >* the power of the Amiga, even considering it's great * >* length. :P "Software Engineering" principles are * >* valid in any project, but you assume that programming * >* in assembler violates the rules of "Software * I did not assume it violated anything. I said that it did not support certain concepts adequately, as well as (some) high-level languages do. >********************************************************** >* Knowledge seperates the men from the boys! * >********************************************************** Agreed - knowledge not assembler. >--- > Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD > The above message is not licensed by AT&T, or at least, not yet. Conclusion: For the umpteenth time, I am talking about programming in general not games programming ! Again I remind you that Mr. Schwartz's old sig used to say "Assembler separates the men from the boys" which does NOT mention games. Secondly I have nothing against assembly language: I use it myself where appropriate, and I explicitly said that it should be used where appropriate, though I really can't see why a WHOLE program should have to be written in assembly langauage. Finally, the whole point of me opening my big mouth in the first place was to point out that there are a lot of issues which people who claim to be great programmers don't even know about, let alone know how to use. Some of these issues are much more important to make a complete programmer than the ability to program in assembler. Assembly language is a good thing to know and can make a programmer wiser. But it is NOT as essential or important as many other issues are. Michael Rizzo