Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uwm.edu!ogicse!pdxgate!eecs!bairds From: bairds@eecs.cs.pdx.edu (Shawn L. Baird) Newsgroups: comp.sys.amiga.programmer Subject: Re: Good programmers and assembly language (very long) Message-ID: <2220@pdxgate.UUCP> Date: 4 Apr 91 09:33:37 GMT References: <7214@harrier.ukc.ac.uk> Sender: news@pdxgate.UUCP Lines: 388 mr3@ukc.ac.uk (M.Rizzo) writes: [ lots of stuff of interest deleted for brevity (yeah, right) ] >If you're questioning my second point i.e. the difference between >good programming and good understanding of hardware, then I'm sorry >but your understanding of what programming is all about is a bit fuzzy. >Programming deals with abstract concepts - algorithms, appropriate >organization of code etc Some programmers have to hit the hardware >e.g. to write device drivers, but in doing so they are combining >programming expertise with knowledge of hardware which is a >separate issue. 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. Every piece of hardware has them, and the target hardware for your program should be a valid consideration. For example, anyone can code a ray tracer in C on just about anything. But a 64k C-64 really isn't the appropriate hardware to carry it out on. Not only do you have to know the limitations of the hardware, but for a succesful piece of software (that is, profitable) you also have to consider the typical hardware of your end user. For a program like The Art Department, your program will require a lot of memory. This is something that, I'm sure, the developers considered in advance. Their target market would be professionals in the video field, and so would be expected to have more memory (and more money to spend on products). They can expect to sell fewer copies than a game, for instance, and adjust the price accordingly. I diverge from my original point, however, that some knowledge of the hardware capability 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. If you are designing programs for device (hardware) independancy, you still need to know the target hardware of the end user. I admit, this isn't directly focusing on your original point, again. 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. Anyone can pop of piece of portable C code onto the Amiga, hack on it and make it work. Sure, it may require 4 megabytes of memory and take 8 years to finish one run, but it works. To improve the efficiency of your program you're probably going to need to use assembly in critical sections to speed it up. Maybe you'll optimize the rest of the assembler output. Well, you say, no problem? Wait! Doesn't knowing assembly language imply some knowledge of the hardware? Ick! Most of the languages you mention above are nice on larger systems, but on an Amiga you're wasting your time. Shall we look for statistics on what two languages are used most for developement now? I would guess the answers would be C and assembly. Just how many commercial PC applications are developed in Prolog? In Pascal? In FP? In Lisp? We're not talking about developing for Unix here. We're talking about a machine where the average user has 512k of memory. 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. I strongly feel that all programmers should spend the extra effort to learn about the machines they program for. That way, instead of getting lousy ports of games like SimCity, we'll get games like Populous. (Why play a mayor when you can be a god?) 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. >>>Some of the essential qualities of a good programmer: >>> o Using the appropriate language for the task at hand - >>> this need not be the whole program, but just a small >>> part of it (as is often in the case with the need for >>> assembler) >>> o Writing well-expressed, concise, readable programs >>> o Understanding and using software engineering concepts >>> such as abstraction, modularity and re-usability >>> o Writing portable routines where possible >>> >>>I do not consider the ability to program in assembly language a required >>>quality of a good programmer: I know people who don't know assembler >>>and are excellent programmers. A lot of UNIX programmers don't know >>>anything but C and they've worked on far more complex projects than >>>any Amiga game. In UNIX its a big sin to program in assembly language >>>because you lose portability across different platforms. So >>>Mr. Schwartz, go tell the UNIX community that their opinions carry >>>little weight! The Unix community's opinion (of which most of us are part) bears very little relevance to programming an Amiga. 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. Mr. Schwartz is a game programmer, and from what I've seen of his postings he's probably pretty good at it. 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? Writing in assembler in Unix is a sin? Gee boss, parts of the OS are written in assembler, guess we'd better junk it! 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. >>Again, the only thing I am suggesting assembler language for is >>games. And rightfully so. Games, however, are not the only place that assembly language is used. 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. >assembler. But I agree that where neccessary, assembler should be used >if time-critical requirements cannot be satisfied in any other way >(such as a faster algorithm), and this is often the case with >sophisticated arcade games. Although games may be written without assembler, I would state that those that use it for critical sections (if they have any) are more efficient. I doubt that any decent arcade style game can be written without assembler. Even the best optimizing compiler can only do so much, and the operating system routines hold you back too far when you have specific requirements. I suppose you could mimic assembly with custom = 0xdff000, etc., but this kind of defeats the point and takes even longer than assembly. >>But anything that can be written in any language can be >>implemented in assembler, too. The resulting programs are smaller >>on disk and faster to execute (I'm talking about Amigas, PCs, Macs, >>STs, C64s, Z80s, etc.). If you sell software to a customer, they >>might care about these things and it and then makes sense to use it. >If I was a customer I'd also care about support and I'd expect enhanced >versions of the software to come out regularly. This would take ages >if all was coded in assembler - just look at how long WordPerfect are >taking to come out with a decent update for the Amiga. With games you >don't have such problems because they only come out once. I believe Sculpt-3D and series were all coded directly in assembly. 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. >>The AMiga OS is not portable ... >You never know - in the future Commodore may develop an Amiga based >on a RISC processor, just like SUN moved from 680x0 to the SPARC. >Software written in C would just have to be recompiled. Assembler >programs would have to be re-written from scratch. 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. Or for that matter, a lot of other software. As for the assembler being re-written from scratch, it's more likely it would have to be modified extremely. The framework of the program would probably be intact. If you insist that programmers maintain hardware compatibility buy using nothing but system calls you force programmers to go through very slow routines like DrawPixel(), and thereby degrade the overall quality of the game. (For games that need the performance) 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? >>... and neither is anything written to use it. What >>other machine has Intuition? You are going to have to do a lot of >>rewriting to port a program that uses it. 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 probably aren't going to see a lot of porting to Unix or OS/2. >>Games are not what we are talking about. We are talking about what >>makes a good programmer. We are talking about whether "Assembler >>separates the men from the boys" or not. Not to mention whether or not AT&T has licensed my message yet. Assembler sure as hell doesn't hurt a programmer, and remaining ignorant of other methods or writing applications is never a good thing. 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. Assembler seperates the knowledgable 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. >>Game programmers that take over the machine are certainly devising >>new ways of writing programs. >No they are not - they are using an established way of writing programs, >namely assembler, to merely re-invent the wheel, refusing to accept and >use what others have written. You have absolutely no idea of what I'm >talking about when I say "new ways of writing programs" because you've >only used IMPERATIVE programming languages. 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. Tell me, did you start math at the Calculus level (or above), or did you develop from earlier tools such as Algebra? >>Ever try assembler? >Yes. 8086 and 6809 on non-trivial projects plus a bit of 68000 to use >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. >>If not, get a clue. You can abuse any language, including assembler. >Abuse? What do you mean? Anyone who can write in assembly and who is proficient in C or some mid to high level language can write clear and accurate assembly. Abuse of assembly can occur just like abuse of a higher level language. It can also be damn near as elegant. >>>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? 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'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. You aren't a REAL programmer until you've learned it. Assembler is a critical language. If you don't learn assembler, you're missing out on the only way to do some programs. (Such as OS programming) >In Miranda all you need is three lines: >qsort :: [*] -> [*] >qsort [] = [] >qsort (a:X) = qsort [b|b<-x; b<=a] ++ [a] ++ qsort [b|b<-x; b>a] >The first line says that qsort is a function which maps a list >of items of arbitrary type to another list of the same type. >Thus, this SAME qsort routine will also work for strings as well >as for numbers. >The second line says that applying qsort to an empty list returns >an empty list. This is important to stop the recursion employed in >the third line. >The third line is just about one of the best examples of conciseness >I've ever seen. It is also very readable when you get used to the >notation of Miranda (which resembles that of Mathematics). It >simply states, that given a list whose first element is a, and >whose tail (remaining elements in the list) is X, return the >list formed by concatenating the following three lists: > qsort [b|b<-x; b<=a] The sorted list of elements in X which are > less than or equal to a > [a] The list containing a itself > qsort [b|b<-x; b>a] The sorted list of elements in X which are > greater than a You go on mooning over Miranda through this entire article. Great, it 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. Hell, at least I cn do a quicksort in assembly. >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 most programs that use quicksorts probably don't need the speed as much as an Amiga arcade game. >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 write the C version of quicksort on a single line (provided enough characters. ;) >>>Michael Rizzo >Michael Rizzo >>-- >>******************************************************** >>* Appendix A of the Amiga Hardware Manual tells you * >>* everything you need to know to take full advantage * >>* of the power of the Amiga. And it is only 10 pages! * >>******************************************************** >-- >********************************************************* >* There's a good book called "Software Engineering" by * >* Brian Ratcliff. Unfortunately its a few hundred pages * >* long, but it's well worth reading if you want to talk * >* about programming without saying rubbish :-) * >********************************************************* -- ********************************************************** * 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 * * Engineering", when assembler is just a tool. It is * * the programmer, who, in the end, either violates or * * doesn't violate valid principles of "Software * * Engineering". * ********************************************************** * Knowledge seperates the men from the boys! * ********************************************************** --- 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.