mce@tc.fluke.COM (Brian McElhinney) (12/02/88)
In article <390@cvbnet2.UUCP> pcolby@robbie.UUCP (Peter Colby) writes: > 1) OS 360 was written in assembly language. Even today there are not a > whole lot of programs equivalent in either size or complexity. > Remember, we're talking somewhere around 1965-1968. Read > "The Mythical Man Month" by ?? Brooks. The issue isn't complexity, > it's lines of code. You read a different "Mythical Man Month" than I. The issue was the complexity of: * Understanding what they were supposed to be producing. * Understanding how they should go about designing it. * Understanding how they go about implementing that design. One *part* of the solution to the implentation is HOLs. There are presently many, many, systems with more complexity that OS 360 -- they are just organized in a manner that reduces the complexity of individual parts to something that is more understandable. OS theory, compiler theory, software engineering practices were all in their infancies when Brooks managed the OS 360 project. See Brooks' more recent paper "No More Silver Bullets" (IEEE Computer in 1987). > The only reason HOLs are considered an advantage is because most > programmers are really coders Assembly language is inherently more complex, leading to less real work done, and more time wasted on complexities that are not a part of the real problem (the real problem is getting the job done, correctly, not organizing register usage for every line of code you write, etc.). Thus HOLs are an advantage because they help reduce complexity. The lines-of-code stat is a side effect (and should be taken with a grain of salt, as should any software metric). > Automate coding from design specs and you lose all advantage of > HOLs. There is a great deal of difference between specifications and a design that implements them. Because of this, automated coding for specifications is, in Brooks' words, a "silver bullet"; a potential part of any real gain in productivity, but not a general answer in and of itself. Since it is only a partial solution, the need for HOLs remains (and indeed, given the difficulty of creating such a program, it would likely be a lot more efficient *in development time* to have the automated code generator emit HOL). > 2) One of the major savings in using assembly language IS due to > "tricks of the chip". I remember doing assembly programming on a CDC > 6600 (1975). Two techniques in particular were used to speed up > programs; First, we coded inner loops to keep the entire intruction > stream in the instruction cache - no memory access (for > instructions) - major gain; second, we interleaved instructions to > take advantage of mutually independant asynchronous functional units > - the units only synchronized to access common registers - depending > upon the task, this could gain little to a lot. But this is 1988. You are simple describing what people are doing with with modern compilers (MIPS is a good example). And what others are doing inside the CPU (the 80960 transparently does the interleave you describe; SPARC *requires* the compiler to do be doing it). > 3) The other major saving in using assembly language is "optimization". > Yes, having to include support code and other general library > routines from the compiler cuts down on code efficiency, but the > major problem is that most commercial compilers generate horrible > code. Hand coding in assembly makes up for the stupidity of > compilers. Of course, good compilers can be written but I suspect > that the R&D effort involved would push the potential selling price > out of the reach of most buyers. However, take a look at the IBM > FORTRAN H (optimizing) compiler or the original PASCAL compiler > written specifically for the CDC 6600. By this same logic, we should all be riding horses. Yes, poor compilers have been written. But just as cars improved, so will compilers. The need for extensive R&D decreases as the knowledge base increases, so you can expect compilers to get better. Look at the GNU C compiler. It's a very good compiler, yet it is free. Also FORTRAN H and the original PASCAL are very different from "modern" HOLs, which solve very different, much more difficult problems. > 4) It's still a truism that appropriate algorithms buy you far more > than hand optimization. However, once you have a working program you > can substantially improve it's speed by analyzing the bottlenecks > and recoding the critical procedures (or loops) in assembly > language. As I said, assemble language is useful in its place. This, and a very few others, are the useful places. Assembly language will never disappear, but it has already faded away considerably, and will continue to do so. Brian McElhinney mce@tc.fluke.com
bob@accuvax.nwu.edu (Bob Hablutzel) (12/02/88)
>> The only reason HOLs are considered an advantage is because most >> programmers are really coders > >Assembly language is inherently more complex, leading to less real work done, >and more time wasted on complexities that are not a part of the real problem >(the real problem is getting the job done, correctly, not organizing register >usage for every line of code you write, etc.). Thus HOLs are an advantage >because they help reduce complexity. The lines-of-code stat is a side effect >(and should be taken with a grain of salt, as should any software metric). Assembly language is _not_ inherently more complex. I program in assembler as my language of choice for two reasons: (1) I tend toward projects which either have to be very small, very fast, or very intimate with the operating system, and (2) I can understand better what is happening in a program I write in Assembler. The problem is not inherent complexity, it's familiarity. I will admit that one has to track register usage, and that this can sometimes be snarled. However, I cannot think of any other disadvantage of assembler, provided you have a decent Macro based assembler. (MACRO on VMS and MPW Assembler both fit this bill). The final difference here is that I am most comfortable with assembler, and therefore work fastest in it. Whenever I try to switch to Pascal, or any other high level language, I envision my code in assembler, and translate it to the high level language. I do not advocate assembler for everyone, but for me it is the language of choice; I am highly productive in it; and I wish people would stop maligning it. I started this whole discussion ( I think :-)) when I said that compilers do not produce as efficient code as hand written assembly. To my mind, _every_ piece of code should be as efficient as possible; anything else is simply wasting the users time. (Granted, a microsecond wasted is not a loss. But these things add up). If compilers truly did generate code as efficiently as assemblers, why, tell me why, nearly everyone agrees that "For time critical or tight loops assembler should be used to optimize" Tell me: What code is non-critical? Bob Hablutzel BOB@NUACC.ACNS.NWU.EDU Disclaimer: These opinions are obviously mine - no one else wants them.
jkjl@munnari.oz (John Lim) (12/04/88)
In article <10330090@accuvax.nwu.edu>, bob@accuvax.nwu.edu (Bob Hablutzel) writes: > > Assembly language is _not_ inherently more complex. I program in assembler > as my language of choice for two reasons: (1) I tend toward projects which > either have to be very small, very fast, or very intimate with the operating > system, and (2) I can understand better what is happening in a program I > write in Assembler. The problem is not inherent complexity, it's familiarity. > > I will admit that one has to track register usage, and that this can sometimes > be snarled. However, I cannot think of any other disadvantage of assembler, > provided you have a decent Macro based assembler. (MACRO on VMS and MPW > Assembler both fit this bill). > Here are some other advantages of *NOT* using assembler : 1. Team management is easier. It's harder for another person to understand what is going on. 2. Portability. You don't think the Mac is the ultimate computer, do you ? :-) 3. Goto-less programming. Less spaghetti-loops and more comprehensibility. Yes, with MACROs you can avoid the spaghetti, but i find formating such a pain in assembler. Try keeping track of begin-loop end-loop code without indentation. Code-size tends to be so much bigger that you cant keep a whole procedure on one page/screen, making comprehension more difficult (Try reading a procedure that is 20 pages long, with while loops nested 3-4 deep in assembler !). etc. Other reasons given below... > The final difference here is that I am most comfortable with assembler, and > therefore work fastest in it. Whenever I try to switch to Pascal, or any other > high level language, I envision my code in assembler, and translate it to > the high level language. I do not advocate assembler for everyone, but for > me it is the language of choice; I am highly productive in it; and I wish > people would stop maligning it. > > I started this whole discussion ( I think :-)) when I said that compilers > do not produce as efficient code as hand written assembly. To my mind, _every_ > piece of code should be as efficient as possible; anything else is simply > wasting the users time. (Granted, a microsecond wasted is not a loss. But > these things add up). If compilers truly did generate code as efficiently as I think this is fallacious reasoning. I have programmed both in Assembler and HLL Languages. Anything that slows the code by less than 1 tick (or 0.5 MIPs/60 = 8 333 instructions a tick) per second is unimportant. The user won't even notice the difference. And count the number of GetNextEvents are called per second. Then you'll realize how much time is spent idling, waiting for activity. A few microseconds adding up here and there make virtually no difference when we are talking about the 'granularity' of a sixtieth of a second. I think you are making too many assumptions about how people program. Most programmers are interested in getting the job done, just like you and me. But their projects are not small, o/s utility programs. How about Canvas, PageMaker, etc. Can you write a 500-700K program in assembler in that time schedule. I strongly object to your use of the word *_every_*. MF is extremely fast. Yet see how inefficient it is (disassemble it - i've had to to work out how Moire interacted with it). It wastes 10-20 cycles per GetNextEvent setting up and restoring A5 using a procedure when it could use INLINEs. Think it makes a difference making it that much faster when you are worried how to implement time-slicing using the PMMU without breaking Excel ? Huh ! > assemblers, why, tell me why, nearly everyone agrees that "For time critical > or tight loops assembler should be used to optimize" You said it : "_every_ piece of code". What the people here are on about is speeding up that 1-5% of code that makes the user wait more than 1 tick between GetNextEvents. > > Tell me: What code is non-critical? > 95-99% of all code as I said above. True code-optimization is important. But if you spend more than 5% of your time trying to optimize, you're wasting your time unless the program is small. I agree that for your programming, assembler may be ideal. But it aint always the best, which seems to be the implications of your message. Code-size is another critereon we could use. But I dont want to bring that in as what i'm complaining about is your sweeping ideas about optimization. john lim
bob@accuvax.nwu.edu (Bob Hablutzel) (12/05/88)
I never said that assembler is the language of the future (at least, I don't think I did...) I think you and I agree, but have different slants on the question. I work in assembler because I want to, because I am most productive in it, and I wanted to defend a much maligned language. However, there are some points in your note I have to comment on. Note - my positions, which follow, are _Bizarre_ according to modern computer science. Students - don't do this at home! 1) Assembler is not portable. Fine. Who cares? No seriously, think about this: when you start to worry about portability, you start shooting for the lowest common denominator. Programs should _not_ be portable for machines like the Macintosh - you will be putting blinders on yourself, and forcing yourself to ignore features of the machine. (Data files, on the other hand, do not depend on the machine as heavily, and should be portable). 2) Assembler does not immediately lead to the dreaded spaghetti code. Assembler can be (almost) as structured as Pascal, but doesn't get in your way when structured programming is a pain. 3) I also disagree that assembler is inappropriate for large projects, but I've had enough flaming for today. Look - enough. 99.9% of the world doesn't like assembler, finds it about kin to toggling in programs by hand. My GOD! Assembler! That's older than Fortran, even, and must be worse. I just don't find this to be the case. I don't think assembler is for everyone. Frankly, a language is just a tool, and whatever tool you want to use is fine. Bob Hablutzel BOB@NUACC.ACNS.NWU.EDU Disclaimer: If this keeps up, I'm switching to BASIC :-)
mce@tc.fluke.COM (Brian McElhinney) (12/06/88)
In article <10330090@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) writes: >Assembly language is _not_ inherently more complex. How can that be when in assembly language: You have to track register usage yourself. You have to check calling sequences yourself. You have to check parameter types yourself. You have to allocate and manage local stack space yourself. You have to do pointer arithmetic yourself. That's a lot of additional complexity. >I program in assembler as my language of choice for two reasons: (1) I tend >toward projects which either have to be very small, very fast, or very >intimate with the operating system, and (2) I can understand better what is >happening in a program I write in Assembler. The problem is not inherent >complexity, it's familiarity. The complexity is still there, even if you're familiar with it. Try working on a large project (half dozen of more people all working on the same code) and then think about complexity due to the tools used versus complexity due to the problem being solved. At some point you have to pick the "best" tools and make sure everyone knows how to use them. For your domain there may not be an appreciable difference. That does not mean that there is no difference. >To my mind, _every_ piece of code should be as efficient as possible; >anything else is simply wasting the users time. (Granted, a microsecond >wasted is not a loss. But these things add up). You assume the users time is more valuable than development time. In an ideal world that would be true, but in the real world you also have to worry about getting the job done. A program that does not exist is infinitely slow! >If compilers truly did generate code as efficiently as assemblers, why, tell >me why, nearly everyone agrees that "For time critical or tight loops >assembler should be used to optimize" Because compilers do not generate code as efficient as humans do. They can come very close though (they may never be able to, but I wouldn't bet on it). More advanced architectures practically require that you use only high-level languages (SPARC and MIPS, for example). >Tell me: What code is non-critical? That depends on your criteria. You mean time critical to the user, and the answer is hardly any at all. Check out the response time in MacApp; plenty fast and definitely high-level. If there is a problem with response time you can almost always fix it by designing a faster algorithm. An interesting example might be FullWrite. I have zero inside knowledge, but I'll go out on a limb and say that it's slowness is due it's design, not the implementation language. An assembly language version would not be appreciably faster. Brian McElhinney mce@tc.fluke.com
tim@hoptoad.uucp (Tim Maroney) (12/06/88)
(Gee, I wonder if anyone has brought this discussion to Fred's attention....) In article <10330092@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) has been writing: >1) Assembler is not portable. Fine. Who cares? No seriously, think about this: >when you start to worry about portability, you start shooting for the lowest >common denominator. Programs should _not_ be portable for machines like the >Macintosh - you will be putting blinders on yourself, and forcing yourself >to ignore features of the machine. (Data files, on the other hand, do not >depend on the machine as heavily, and should be portable). Um, have you written much software? An awful lot of software is in the form of distinct modules which could theoretically be used in lots of different programs with no changes. For instance, encryption or database-file packages, or network protocol implementations. There's every reason for this kind of software to be as portable as possible across OS and processor lines. >2) Assembler does not immediately lead to the dreaded spaghetti code. >Assembler can be (almost) as structured as Pascal, but doesn't get in your >way when structured programming is a pain. Baloney. Even VAX assembler isn't as well-structured as Pascal or C. If you have to simulate structured constructs using GOTOs, it isn't structured. If you have to write arithmetic expressions using two or three operand arithmetic, it isn't structured. The constant necessary use of GOTOs makes spaghetti code almost impossible to resist -- "This almost works -- all I have to do is put in a conditional branch bavck to instruction 32!" >3) I also disagree that assembler is inappropriate for large projects, but >I've had enough flaming for today. On this point, I think I agree, more or less. There really isn't any reason assembler can't be just as modular and well-defined as high-level languages. It's less self-defining, at least as usually written, but large projects require external module specifications anyway. >Look - enough. 99.9% of the world doesn't like assembler, finds it about kin >to toggling in programs by hand. My GOD! Assembler! That's older than Fortran, >even, and must be worse. I just don't find this to be the case. Read this paragraph again before flaming me for putting down your breadth of expertise in my first paragraph, Bob.... -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I was brought up in the other service; but I knew from the first that the Devil was my natural master and captain and friend. I saw that he was in the right, and that the world cringed to his conqueror only from fear." - Shaw, "The Devil's Disciple"
jurjen@cwi.nl (Jurjen N.E. Bos) (12/06/88)
In article <6211@fluke.COM> mce@tc.fluke.COM (Brian McElhinney) writes: >In article <10330090@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) writes: >An interesting example might be FullWrite. I have zero inside knowledge, but >I'll go out on a limb and say that it's slowness is due it's design, not the >implementation language. An assembly language version would not be >appreciably faster. > Ever seen WriteNow? It's really fun to see this program using a debugger. I watched the spelling checker in action... It's impressive. I think that one of the main reasons that WriteNow is so fast (and true WYSIWYG) and small (only 70K) is that it's written in assembly language. -- -- Jurjen N.E. Bos (jurjen@cwi.nl)
bob@accuvax.nwu.edu (Bob Hablutzel) (12/06/88)
Hi. It's me again. >>Assembly language is _not_ inherently more complex. >How can that be when in assembly language: > You have to track register usage yourself. > You have to check calling sequences yourself. > You have to check parameter types yourself. > You have to allocate and manage local stack space yourself. > You have to do pointer arithmetic yourself. >That's a lot of additional complexity. I don't have to check calling sequences. I don't have to allocate local stack space. Macros do this for me. I have to check parameter types? Flip side: I never have to bother with typecasting. Register usage I've already admitted to, but it isn't a real problem. Most of the rest I can't disagree with. I have no problem with HLLs, I just want to point out that assembler is not so bad, and the, as you admit, the myth that compilers generate code as efficiently as assemblers is a falacy. Bob "Really getting sick of this whole thread" Hablutzel BOB@NUACC.ACNS.NWU.EDU Disclaimer: I never said anything. This is all just a bad dream
bob@accuvax.nwu.edu (Bob Hablutzel) (12/06/88)
Responding to flame #512... >>1) Assembler is not portable. Fine. Who cares? No seriously, think about this: >>when you start to worry about portability, you start shooting for the lowest >>common denominator. Programs should _not_ be portable for machines like the >>Macintosh - you will be putting blinders on yourself, and forcing yourself >>to ignore features of the machine. (Data files, on the other hand, do not >>depend on the machine as heavily, and should be portable). >Um, have you written much software? An awful lot of software is in the >form of distinct modules which could theoretically be used in lots of >different programs with no changes. For instance, encryption or >database-file packages, or network protocol implementations. There's >every reason for this kind of software to be as portable as possible >across OS and processor lines. Let me back off from this one a little - I didn't state it very well. (Yes, I have written a lot of software - for almost 12 years now). I think the above statements have more to do with cold-killers than reality. I will agree that purely mathematical, or "semi-numeric" type problems, are good candidates for high level languages (assuming decent compilers are available, and these routines are not critical ones). What I really meant to attack is the use of portability for things like user interface code, file system interaction, etc. There seems to be an ugly trend toward "totally" portable code - this can only lead to lowest common denominator code. >>2) Assembler does not immediately lead to the dreaded spaghetti code. >>Assembler can be (almost) as structured as Pascal, but doesn't get in your >>way when structured programming is a pain. >Baloney. Even VAX assembler isn't as well-structured as Pascal or C. >If you have to simulate structured constructs using GOTOs, it isn't >structured. If you have to write arithmetic expressions using two or >three operand arithmetic, it isn't structured. The constant necessary >use of GOTOs makes spaghetti code almost impossible to resist -- "This >almost works -- all I have to do is put in a conditional branch bavck >to instruction 32!" I didn't say that assemblers were structured, I said that you could write "almost" structured code in assembler. What this means is (a) not giving in to temptation like the instruction 32 problem, and (b) hand writing code similar to what the compiler is going to generate anyhow (for the placement of GOTOs to simulate loop constructs). I am considering structured programming as a style, not as a formal definition, here. I am curious, however, as to why multiple arithmetic instructions makes a program non-structured. Can you clarify this? I understood structured programming as a flow control disciple, but maybe I should go review... >>3) I also disagree that assembler is inappropriate for large projects, but >>I've had enough flaming for today. >On this point, I think I agree, more or less. There really isn't any reason >assembler can't be just as modular and well-defined as high-level languages. >It's less self-defining, at least as usually written, but large projects >require external module specifications anyway. You mean someone agrees with me?? On anything? Oh, my heart... :-) Bob Hablutzel BOB@NUACC.ACNS.NWU.EDU
sbb@esquire.UUCP (Stephen B. Baumgarten) (12/08/88)
In article <10330096@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) writes: [ Responding to the problem of assembly not being portable ] >Let me back off from this one a little - I didn't state it very well. (Yes, >I have written a lot of software - for almost 12 years now). I think the above >statements have more to do with cold-killers than reality. I will agree that >purely mathematical, or "semi-numeric" type problems, are good candidates for >high level languages (assuming decent compilers are available, and these >routines are not critical ones). What I really meant to attack is the use of >portability for things like user interface code, file system interaction, etc. >There seems to be an ugly trend toward "totally" portable code - this can >only lead to lowest common denominator code. According to Microsoft, 90% of the code for Excel is the same across Mac and DOS/Windows platforms. General code for file-system management is *precisely* what you want; then your application can just make calls to the general routines "get_file_name_from_user", "open_data_file", "write_record", etc. When porting to a different platform, only these low-level interface routines need be rewritten. Of course user-interface code should not be ported to inappropriate platforms, but an additional "user-interface manager" layer can be written to interface the application to the particular windowing environment. Use of high-level languages allow you to maintain a single (large) body of code that can be used regardless of the specific operating system, window manager, CPU, etc. Wouldn't this be difficult (or even impossible) to do if the majority of your code was written in assembly? -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
tim@hoptoad.uucp (Tim Maroney) (12/08/88)
In article <10330096@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) wrote: >Responding to flame #512... If you don't want to be flamed in return, don't express your views as flames in the first place. >>>1) Assembler is not portable. Fine. Who cares? >>>When you start to worry about portability, you start shooting for the lowest >>>common denominator. > >>An awful lot of software is in the >>form of distinct modules which could theoretically be used in lots of >>different programs with no changes. For instance, encryption or >>database-file packages, or network protocol implementations. There's >>every reason for this kind of software to be as portable as possible >>across OS and processor lines. > >I think the above >statements have more to do with cold-killers than reality. I will agree that >purely mathematical, or "semi-numeric" type problems, are good candidates for >high level languages (assuming decent compilers are available, and these >routines are not critical ones). What I really meant to attack is the use of >portability for things like user interface code, file system interaction, etc. Encryption may be a mathematical problem, but network protocols and database file access packages are not. Care to respond to my point? Most software which is not directly interfaced to the user benefits from portability, not just mathematical packages. >I didn't say that assemblers were structured, I said that you could write >"almost" structured code in assembler. What this means is (a) not giving >in to temptation like the instruction 32 problem, and (b) hand writing >code similar to what the compiler is going to generate anyhow (for the >placement of GOTOs to simulate loop constructs). I am considering structured >programming as a style, not as a formal definition, here. The temptation to write spaghetti code will, in this universe of flawed humans, lead to spaghetti code. Maybe in Heaven everyone uses assembler and simulates compiled constructs, but not down here in Heck. Giving people tools that encourage them to shoot themselves in the foot and then blaming them for their lack of toes is silly. >I am curious, however, as to why multiple arithmetic instructions makes a >program non-structured. Can you clarify this? I understood structured >programming as a flow control disciple, but maybe I should go review... The superiority of writing infix expresions instead of two-operand or three-operand opcodes in a linear sequence is sufficiently obvious that it wasn't even mentioned by Dijkstra, to my knowledge. Readability, modifiability, reduction in complexity (no register management), etc., all pertain to writing infix arithmetic expressions, and all are motivations of structured programming as well. Frankly, Bob, I think it's obvious to everyone reading your messages that you're making up bogus rationales for a personal, subjective preference. Why not just admit that you like assembler for personal reasons and that it doesn't really have any general superiority over high-level languages? -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I've got troubles of my own, and you can't help me out. So take your meditations and your preparations and ram it up yer snout!" - Frank Zappa, "Kozmik Debris"
bob@accuvax.nwu.edu (Bob Hablutzel) (12/08/88)
>>Responding to flame #512... >If you don't want to be flamed in return, don't express your views as flames >in the first place. If I flamed, I'm sorry. Really. I didn't intend this to be an ongoing thread, and I frankly don't even remember what started this whole thing. I've been a bit more dogmatic about this subject than I should be, and I apologize. However, I still stand behind my original premise - for people who are sufficiently familiar with assembler, there is no reason not to use it freely, and that hand written assembler code will be more efficient than code output from a compiler, simply because of the nature of compilers. These statements I still stand behind. >>I will agree that >>purely mathematical, or "semi-numeric" type problems, are good candidates for >>high level languages (assuming decent compilers are available, and these >>routines are not critical ones). What I really meant to attack is the use of >>portability for things like user interface code, file system interaction, etc. >Encryption may be a mathematical problem, but network protocols and database >file access packages are not. Care to respond to my point? Most software >which is not directly interfaced to the user benefits from portability, >not just mathematical packages. I guess it depends on the level of code you are talking about. With no standardized methods of talking to hardware, at some point the code will not be portable. _This_ code is what I'm singling out for a good assembly candidate - the code will be executed often, the user will benefit from the speed, etc. I'm not talking about drivers, which are obvious, but about the code which talks directly to the drivers. (On the Mac, it's the difference between calling glue routines (PBRead) instead of the ultimate call to the (Read)). With a modularized program, and development system that permits it, these routines could be localized, and optimized. >>I didn't say that assemblers were structured, I said that you could write >>"almost" structured code in assembler. What this means is (a) not giving >>in to temptation like the instruction 32 problem, and (b) hand writing >>code similar to what the compiler is going to generate anyhow (for the >>placement of GOTOs to simulate loop constructs). I am considering structured >>programming as a style, not as a formal definition, here. >The temptation to write spaghetti code will, in this universe of flawed >humans, lead to spaghetti code. Maybe in Heaven everyone uses >assembler and simulates compiled constructs, but not down here in >Heck. Giving people tools that encourage them to shoot themselves in >the foot and then blaming them for their lack of toes is silly. You can write lousy code in a structured language, as well. My point is this: don't blame the _tool_ for the lack of discipline in the programmer. >>I am curious, however, as to why multiple arithmetic instructions makes a >>program non-structured. Can you clarify this? I understood structured >>programming as a flow control disciple, but maybe I should go review... >The superiority of writing infix expresions instead of two-operand or >three-operand opcodes in a linear sequence is sufficiently obvious that >it wasn't even mentioned by Dijkstra, to my knowledge. Readability, >modifiability, reduction in complexity (no register management), etc., >all pertain to writing infix arithmetic expressions, and all are >motivations of structured programming as well. That's fine, and I agree - Infix is more readable than assembler. No problem there. I was just wondering about the structured programming aspect - I didn't remember infixing being a part of it. Even _I_ would rather use Pascal (Fortran, etc) for heavy math than assembler. >Frankly, Bob, I think it's obvious to everyone reading your messages >that you're making up bogus rationales for a personal, subjective >preference. Why not just admit that you like assembler for personal >reasons and that it doesn't really have any general superiority over >high-level languages? Well, if this is the impression I've given, I'm sorry. I don't think assembler is generally superior to high-level languages, and if I said that, I hereby retract that. What I do think, however, is that when you choose high- level language as your tool, you are gaining some things (automatic register tracking, loop constructs, etc), and losing others (speed and size). It's up to individual programmer. You're right - assembler is a personal preference. What I wish is that people would admit that assembler does have some advantages (as well as drawbacks) against high level languages. It's a different, but still a viable, world. I say this from experience - it's the reason I switched to assembler. In every non-trivial case, coded written in assembler will take longer, run faster, produce a smaller executable, and be less readable than high level languages. > Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim Bob Habluztel BOB@NUACC.ACNS.NWU.EDU Disclaimer: I'm getting less cranky - wanna talk politics?
bob@accuvax.nwu.edu (Bob Hablutzel) (12/08/88)
>>[ Responding to the problem of assembly not being portable ] >>Let me back off from this one a little - I didn't state it very well. (Yes, >>I have written a lot of software - for almost 12 years now). I think the above >>statements have more to do with cold-killers than reality. I will agree that >>purely mathematical, or "semi-numeric" type problems, are good candidates for >>high level languages (assuming decent compilers are available, and these >>routines are not critical ones). What I really meant to attack is the use of >>portability for things like user interface code, file system interaction, etc. >>There seems to be an ugly trend toward "totally" portable code - this can >>only lead to lowest common denominator code. >According to Microsoft, 90% of the code for Excel is the same across >Mac and DOS/Windows platforms. >General code for file-system management is *precisely* what you want; >then your application can just make calls to the general routines >"get_file_name_from_user", "open_data_file", "write_record", etc. When >porting to a different platform, only these low-level interface >routines need be rewritten. Exactly my point, I think. What I'm saying is that these low level routines are good candiates for assembler. >Of course user-interface code should not be ported to inappropriate >platforms, but an additional "user-interface manager" layer can be >written to interface the application to the particular windowing >environment. >Use of high-level languages allow you to maintain a single (large) body >of code that can be used regardless of the specific operating system, >window manager, CPU, etc. Wouldn't this be difficult (or even >impossible) to do if the majority of your code was written in assembly? Yes, indeed. The "portability" quote is something I wish I hadn't said. Let me put it this way: For something like Excel, high level languages make sense, mainly because MicroSoft makes it's money by spreading itself to as many platforms as possible. If they had no intent to move onto multiple machines, then assembler would be something to consider. Some types of code can't be moved to another machine and make sense; for code that can't be ported, assembler would be viable option. > Steve Baumgarten | "New York... when civilization falls apart, > Davis Polk & Wardwell | remember, we were way ahead of you." > cmcl2!esquire!sbb | > esquire!sbb@cmcl2.nyu.edu | - David Letterman Bob Hablutzel BOB@NUACC.ACNS.NWU.EDU
w-colinp@microsoft.UUCP (Colin Plumb) (12/14/88)
In article <874@esquire.UUCP> sbb@esquire.UUCP (Stephen B. Baumgarten) writes: >According to Microsoft, 90% of the code for Excel is the same across >Mac and DOS/Windows platforms. Right. And 5% of the lines of *that* 90% are one of: #ifdef #else #endif Really, are you pleased that, to achieve this end, they ported 64K segments? I feel inspired to create an aphorism: "At Microsoft, it doesn't matter which file you're compiling, only which flags you #define" -- -Colin (uunet!microsof!w-colinp)