aj0@sage.cc.purdue.edu (Eric Mulholland) (03/27/90)
>Article <7509@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: >> It seems to me that most programmers ought to be write better code than a >>compiler; ... Article <12435@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) replies: >involved, compiled code can run anywhere from somewhat faster (yes!) to >several times slower. Compilers translate statements into machine code while assembliers practicly directly convert to machine code. The only way compiled code can run faster is a sloppy programmer. A compiler is able to clean up some of the mess and thus make faster code, but with a good programmer, the compiler would have to be enormesly complex (and slow) to compete. >However, keep in mind that time spent in making non-bottleneck sections >of code run faster is time wasted. Even if you're after speed, assembler >should be used for only a small fraction of an application. Just because code is written in assembly doesn't mean long hours are spent in optimizing every routine. As mentioned before, macro libraries come into play here. Like with high level languages, they contain common routines programmers use. Something else about assembly that I feel important hasn't been mentioned. Assembly code is more compacted! The shorter the program, the more evident this becomes. See if a compiler can create the "hello world" program in about two dozen bytes! Not two dozen Ks, but bytes. One of the reasons for this comes from numbers that only need one byte often use two or four! There are a number of programs out there cross compiled to the Apple // that I feel sorry for the people who's names are listed in the credits. Grantted, not all programs written in high level languages are bad, but the ratio between bad and good is much higher than is with assembly. -- ____ Y_,_|[]| Eric Mulholland {|_|_|__| aj0@sage.cc.purdue.edu //oo--OO ...!pur-ee!sage.cc!aj0
stadler@Apple.COM (Andy Stadler) (03/27/90)
In article <3880@sage.cc.purdue.edu> aj0@sage.cc.purdue.edu (Eric Mulholland) writes: > >>Article <7509@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: >>> It seems to me that most programmers ought to be write better code than a >>>compiler; ... > >Article <12435@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) replies: >>involved, compiled code can run anywhere from somewhat faster (yes!) to >>several times slower. > > Compilers translate statements into machine code while assembliers >practicly directly convert to machine code. The only way compiled code >can run faster is a sloppy programmer. A compiler is able to clean up >some of the mess and thus make faster code, but with a good programmer, >the compiler would have to be enormesly complex (and slow) to compete. > Someone said in an earlier posting that "compilers look at the entire program and optimize it". You're all missing the main reason to use compilers: A compiled program is easier for the PROGRAMMER to look at and understand. Everyone keeps talking about cycle-by-cycle style optimizations. But that's only half the game. It is equally important to optimize your algorithms, data structures, and program execution. Suppose I have a program, and I determine that it's spending 50% of it's time in a single routine. Now, I spend some time, rewrite in assembly, tighten up the loop, whatever. Even if I double the speed of the routine, the program is only 33% faster. However, if I can redesign my program to not ever use that routine, I've DOUBLED (100% faster) the speed of the program. No matter how well structured, an assembly program is longer (to the programmer - more lines of code) and thus harder to read and "internalize". You are forced to look at more details, and therefore less high-level structure. Let's face it, we're not perfect, we have limited attention spans, and we need all the help we can get. >>However, keep in mind that time spent in making non-bottleneck sections >>of code run faster is time wasted. Even if you're after speed, assembler >>should be used for only a small fraction of an application. > > Just because code is written in assembly doesn't mean long hours are >spent in optimizing every routine. As mentioned before, macro libraries >come into play here. Like with high level languages, they contain common >routines programmers use. > I agree, but only to a point. Macro libraries or no, I can write code MUCH faster in Pascal than I can in assembly. And the less time it takes me to write the program, the more time I have to debug, measure, and THEN optimize. This last point is important. Non-bottleneck sections should be written for programmer convenience, ease of modification, reliability, etc. Bottleneck sections should be written for speed. However, it is very hard to predict just where your program will spend lots of time. The ideal development cycle is: (1) Write your program. Get it running as soon as possible. Investigate the features. Change the design. Rework it some more. (2) When you are satisfied with the design and implementation, now, and only now, MEASURE. Discover by test, not by prediction, where the bottlenecks are. I promise you'll see both expected behaviors, and at least a few surprises. (3) Finally, optimize. Get in to those bottlenecks, and either rework the program to eliminate them, or do the bare-hardware thing and crunch them into the world's tightest assembly language. #1, and the first part of #3 are the domain of high-level languages. The compiler can be your friend - let it work for you. The second half of #3 is where assemblers and excellent knowledge of your CPU (quick! how many cycles for an indirect indexed 24 bit addressing load when DP isn't page aligned?) are your main strengths. > Something else about assembly that I feel important hasn't been >mentioned. Assembly code is more compacted! The shorter the program, >the more evident this becomes. See if a compiler can create the "hello >world" program in about two dozen bytes! Not two dozen Ks, but bytes. >One of the reasons for this comes from numbers that only need one byte >often use two or four! Please understand that when you compile a program, you don't just get the compiler output, you also get a whole bunch of library code to go with it. Problem is, the library code is large and generalized. It probably contains enough code to open, read and write disk files, or the console, or whatever. Some linkers are better than others at discarding unused code; and some libraries are constructed better than others. Try this experiment: Rewrite "hello, world" as a desktop program - use NO language-io calls (WriteLN, etc for you Pascal folks, or printf's for you C types) and NO language-memory calls (New, Dispose, malloc() ). If all the work is done by the compiled program, and the libraries aren't linked in, you'll find much less disparity. --andy stadler@apple.com
dcw@lcs.mit.edu (David C. Whitney) (03/27/90)
In article <3880@sage.cc.purdue.edu> aj0@sage.cc.purdue.edu (Eric Mulholland) writes: >>Article <7509@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: >>> It seems to me that most programmers ought to be write better code than a >>>compiler; ... > >Article <12435@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) replies: >>involved, compiled code can run anywhere from somewhat faster (yes!) to >>several times slower. > > Compilers translate statements into machine code while assembliers >practicly directly convert to machine code. The only way compiled code >can run faster is a sloppy programmer. A compiler is able to clean up >some of the mess and thus make faster code, but with a good programmer, >the compiler would have to be enormesly complex (and slow) to compete. > Something else about assembly that I feel important hasn't been >mentioned. Assembly code is more compacted! The shorter the program, >the more evident this becomes. See if a compiler can create the "hello >world" program in about two dozen bytes! Not two dozen Ks, but bytes. >One of the reasons for this comes from numbers that only need one byte >often use two or four! > Y_,_|[]| Eric Mulholland >{|_|_|__| aj0@sage.cc.purdue.edu >//oo--OO ...!pur-ee!sage.cc!aj0 Please remember that there are GOOD compilers out there. The 65816 is pretty crippled, and it's just TOO HARD to write a whiz-bang compiler for it. Let me tell you, you DON't want to write programs on a RISC (say, a Sun SPARC) or any other pipelined CPU in assembler. You'll pull all your hair out. In this instance, a compiler WILL ALWAYS produce MUCH better code than a person could. In general, optimizers are pretty good IF the hardware they compile to has enough resources (ie, registers). With today's CPUs, compilers will outperform direct assembly coding nearly all of the time. Optimizers exist (although I don't know of one for the //). They're complicated in overall design, but each optimization technique is pretty simple. The thing to do of course is to build a 65816 output generator into gcc; compile gcc into 65816; move it to the apple //gs. Gcc has some pretty good optimization stuff built in. It would run gawd-awful slow (it's already sorta slow on my SPARC). The better idea is to make the 65832 have several registers (16 or 32). The A, X, Y, SP, etc would be mapped onto the first n registers so that older stuff will work properly. THEN, compilers would be much happier. -- Dave Whitney dcw@sun-bear.lcs.mit.edu ...!mit-eddie!sun-bear!dcw dcw@athena.mit.edu My employer pays me well. This, however, does not mean he agrees with me. I wrote Z-Link & BinSCII. Send me bug reports. I use a //GS. Send me Tech Info.
nagendra@bucsf.bu.edu (nagendra mishr) (03/28/90)
speaking of compilers, try this with Micol Basic, put all your code on one line. the size of your output code is decreased by about 20 bytes per line not used. And instead of calling the toolbox routines everytime, make a procedure that you call. you'll reduce about 40 bytes per indirect call. The point is, if you have a crappy compiler because it works against you, what're you supposed to do? Anybody try weird stuff like this with Orcac yet? nagendra
stephens@latcs1.oz.au (Philip J Stephens) (03/28/90)
In article <39854@apple.Apple.COM>, stadler@Apple.COM (Andy Stadler) writes: > > A compiled program is easier for the PROGRAMMER to look at and understand. Correction: A _well_written_ program in a high-level language is easier to understand. :-) The object code would also be "easier" to read, but it would never be optimised to the greatest degree possible. Now, before I continue, remember I am talking about an Apple ][ computer, not a Unix box or some other such machine. Everyone knows you don't bother using assembly on a mini-computer. > Everyone keeps talking about cycle-by-cycle style optimizations. But that's > only half the game. It is equally important to optimize your algorithms, > data structures, and program execution. Aha! Remember, though, that most compilers only _do_ cycle-by-cycle style optimizations! The rest is up to the programmer. Whether you are writing in a high- or low-level language, you're going to have to write good algorithms in the first place. Depending on the problem you are trying to solve, you may end up with code that is more difficult to understand once you've optimised the solution. > No matter how well structured, an assembly program is longer (to the > programmer - more lines of code) and thus harder to read and "internalize". > You are forced to look at more details, and therefore less high-level > structure. Let's face it, we're not perfect, we have limited attention > spans, and we need all the help we can get. If you are claiming that assembly programs are always going to be longer than the equivalent C source, then you've not used assembly much. On a statement-by-statement basis, this is always going to be true, and since compilers operate on such a basis, they can't produce the best code. However, write an algorithm directly in assembly, and you can optimise to such an extent that often the resulting code will be far shorter than the ASCII text in the C source itself! It will certainly be shorter than the compiled object code. You may think that it takes too much effort to write an algorithm efficiently in assembly due to the lack of high-level structures. Bollocks! You've just got to approach the problem in different directions, that is all. The truth is, high-level structures tend to be far more restrictive in the ways they let you express the solution; in assembly, you're got complete freedom in how you are going to write the algorithm. Why do you think people prefer C over Pascal? Answer: because C is less structured! As a result, it is more difficult to program in C, but you can do a hell of a lot more in it compared to Pascal. The same applies to assembly language over any high-level language. A bit harder to program, certainly requiring a different approach, but the results may be worth the trouble. > I agree, but only to a point. Macro libraries or no, I can write code MUCH > faster in Pascal than I can in assembly. And the less time it takes me to > write the program, the more time I have to debug, measure, and THEN optimize. But again, not applicable if you're writing a program on an Apple ][ that has lousy speed and an inapproapiate microprocessor that isn't designed to run code from a high-level language compiler. Pascal may be easy to write code in, but you'll never get the speed you want (if speed is an issue, of course). > Please understand that when you compile a program, you don't just get the > compiler output, you also get a whole bunch of library code to go with it. > Problem is, the library code is large and generalized. There's never been any doubt that library code takes up the most space. Look at any Unix executable and you'll be bowled over by the number of blocks taken up. I agree that compiled code can be quite compact - just look at the output from Turbo Pascal, and you'll see this. But it is never as compact as assembly code written directly by the programmer. Then again, why are we arguing about this? Each has it's own place, assembly language more so on an Apple ][. That's just the way it is. > --andy stadler@apple.com </\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\> < Philip J. Stephens >< "Many views yield the truth." > < Hons. student, Computer Science >< "Therefore, be not alone." > < La Trobe University, Melbourne >< - Prime Song of the viggies > <\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>
tm@polari.UUCP (Toshi Morita) (06/08/90)
There seems to be interest in other languages for the Apple II series... I have an implementation of William Gale's TINCMP for ProDOS 8, by yours truly. I also have the macro set for compiling Pidgin programs. It was originally mentioned in Doctor Dobb's Journal #57 (Volume 6, Issue 7 - July 1981) and was sold as part of the Bootstrap Toolkit. I've written to Mr. Gale; he no longer sells the package and he stated it was okay to make the compiler public domain. Source is pretty small (about 30k, I think). Have I piqued anyone's curiosity? Toshi Morita tm@polari.UUCP
GRAY@ADMIN.HumberC.ON.CA (Kelly Gray) (06/09/90)
Toshi Morita writes: >Have I piqued anyone's curiosity? Yes. What is TINCMP? I take it that it is a compiler of some sort. <o_o> Kelly Gray (GRAY@ADMIN.HUMBERC.ON.CA)
jm7e+@andrew.cmu.edu (Jeremy G. Mereness) (06/11/90)
> Excerpts from netnews.comp.sys.apple2: 8-Jun-90 Languages Toshi > Morita@polari.UUCP (576) > I have an implementation of William Gale's TINCMP for ProDOS 8, by yours > truly. > I also have the macro set for compiling Pidgin programs. It was > originally > mentioned in Doctor Dobb's Journal #57 (Volume 6, Issue 7 - July 1981) > and was sold as part of the Bootstrap Toolkit. I've written to Mr. Gale; > he no longer > sells the package and he stated it was okay to make the compiler public > domain. > Source is pretty small (about 30k, I think). Sounds like fun. Can you upload it to comp.binaries.apple2 or apple2-l? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^ |Jeremy Mereness | Support | Ye Olde Disclaimer: | |jm7e+@andrew.cmu.edu (internet) | Free | The above represent my| |a700jm7e@cmccvb (Vax... bitnet) | Software | opinions, alone. | |staff/student@Carnegie Mellon U. | | Ya Gotta Love It. | ------------------------------------------------------------------------- --
awg0971@ritvax.isc.rit.edu (King Lerch) (02/25/91)
I wanted to start some programming in either assembly or C. Does anyone know of
a really good book or programming utility or compiler to help me get started on
any on these?
-King Lerch unknown@ucscb.UCSC.EDU (The Unknown User) (02/28/91)
In article <1991Feb24.222818.13962@isc.rit.edu> awg0971@ritvax.isc.rit.edu writes: >I wanted to start some programming in either assembly or C. Does anyone know of >a really good book or programming utility or compiler to help me get started on >any on these? > -King Lerch The best reference book for C is "The C Programming Language" by Brian W. Kernighan and Dennis M. Ritchie. These are the guys who invented the language, and the Second Edition is on Ansi C. This is a reference though. It does have little tutorials as you go along though so if you think you're disciplined enough, you could teach yourself C only with this. I DEFINITELY suggest you buy this book sooner or later. For a while ByteWorks (publishers of Orca/C, the best GS C compiler) had a special on where they sold Orca/C and a special "Learn to Program C" book/'tutorial set' (I don't know what's all included in it) for about $95. That is a VERY good deal since the best price for the Orca/C compiler ITSELF is $80 mail order. And if you get all you need to learn C for $15, it's a GREAT deal. And PLEASE PLEASE PLEASE buy this program. If you pirate this program, then further versions will not be made... (Orca/C is only the fourth program I've bought so far but I'm slightly moving away from the piracy mentality. Not as a moral or legal issue either, simply that I try out everything and pay for what's worth paying for) -- /Apple II(GS) Forever! unknown@ucscb.ucsc.edu MAIL ME FOR INFO ABOUT CHEAP CDs\ \WRITE TO ORIGIN ABOUT ULTIMA VI //e and IIGS! Mail me for addresses, & info. /