cmcmanis%pepper@Sun.COM (Chuck McManis) (06/16/88)
In article <312@pedro.UUCP> pete_ashdown@pedro.UUCP (Pete Ashdown) writes: > Thanks for your suggestions. I may just turn back to examining 'C'. I > have already done program #1 to some extent in assembly. Should I turn > back to 'C' or should I keep going with assembly? I'd be curious to > find out from other 68000 assembly programmers (like Mark R.) how they > got started. If they went from 'C' to assembly or just started out in > assembly. Well whether to program in C or Assembly or Modula-2 for that matter depends on some of the parameters of the project. Anyone who is serious about systems programming/design should probably learn several languages if only to get through the nuances of "do {statement} while (expr);" and "REPEAT BEGIN statement END UNTIL expr;" And into the concepts of loops that check their parameters at the end of the loop versus loops that check their parameters before executing the loop etc. Once you understand programming at that level, using any given language is simply a vocabulary switch. Then you can decide what language to use based on it's other strengths. These being generally classed into the groups such as readability, efficiency, maintence, and time to completion. Using C, Assembly, and Modula-2 as examples I break them down as follows : C provides a 'minimalist' high level language, interfaces between modules are provided but only loosely enforced, details of actual register usage is abstracted although it can still be influenced, time to completion is fairly short but readability and maintainability sometimes suffer. Assembly provides the maximum utilization of system resources and processing power. When this is a 'drop dead' requirement nothing else will suffice. Assembly language provides no support for maintaining module interfaces and is often abused (push something on the stack and then execute it is a common example). This makes it difficult to share work among undisciplined programmers. Nothing enforces readability and styles vary wildly so this can also be a problem when someone 'new' picks up some existing code. Assembly usually has the highest delivery and maintenence costs of any language except APL. Modula-2's biggest strengh is it's enforcement of routine interfaces. When multiple programmers share a task they can design to an interface and know that when their code links the interface has not changed. It's considered "wordy" by many programmers and often suffers from "moduleitis" where every possible subroutine gets it's own module. Generally, the code does what the program indicates and it is often the most maintainable code of the bunch. Look at your needs and then pick your language. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
lee@uhccux.uhcc.hawaii.edu (Greg Lee) (06/16/88)
From article <56707@sun.uucp>, by cmcmanis%pepper@Sun.COM (Chuck McManis): "... " Well whether to program in C or Assembly or Modula-2 for that matter depends " on some of the parameters of the project. Anyone who is serious about systems " ... " Look at your needs and then pick your language. There are other considerations. Which is the most fun to program in? How much do you enjoy having your decisions about how to use the machine made for you? Assembly language programmers like to talk directly to the cpu. Greg, lee@uhccux.uhcc.hawaii.edu
elg@killer.UUCP (Eric Green) (06/19/88)
in article <56707@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) says: > In article <312@pedro.UUCP> pete_ashdown@pedro.UUCP (Pete Ashdown) writes: >> Thanks for your suggestions. I may just turn back to examining 'C'. I >> have already done program #1 to some extent in assembly. Should I turn >> back to 'C' or should I keep going with assembly? I'd be curious to Having written tens of thousands of lines of assembly for 8-bit machines, I'd be glad if I never had to look at assembly language again. Have you ever tried to maintain a large program written in assembly language? It's no picnic... every time I want to do a revision to add a new feature, for example, I practically have to re-learn the entire program all over again. The only good thing about that, is that each pass through the revision loop, I end up with about 20% more comments (to the point where the comments are threatening to crowd out the instructions :-). One of the things I like about the Amiga is that I only have to use assembler in those limited instances where it makes sense -- when I have a tight loop doing heavy-duty bit-banging, for example. Of course, if I want my program to run in a 512K Amiga.... more might have to end up in assembler. -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 "Is a dream a lie if it don't come true, or is it something worse?"
elg@killer.UUCP (Eric Green) (06/19/88)
in article <1968@uhccux.uhcc.hawaii.edu>, lee@uhccux.uhcc.hawaii.edu (Greg Lee) says: > machine made for you? Assembly language programmers like to talk > directly to the cpu. I always look at the assembly-language output of my programs to make sure that they're operating fairly efficiently, and to make sure that they're doing exactly what I want them to do ("C" "for" loops still drive me crazy :-} ). That's as close as I want to come to assembly... On a related topic, does the Lattice 4.0 compiler do any (useful) optimizations besides common subexpression? In particular, some of the RISC compilers generate code that keep calculated addresses around, and all of the RISC compilers seem to make every attempt to keep most-common-used variables in registers (in fact, the Pyramid 90x compiler totally ignores the "register" declarators, as far as I can tell -- at least, when you have fewer than 16 local variables and 16 parameters). I've been looking at the code generated by the Manx 3.60 compiler, and it looks pretty simplistic. Does Lattice 4.0 manage any better? (& onrelated topic, SDB gurus my machine regularly, sigh). -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 "Is a dream a lie if it don't come true, or is it something worse?"
toebes@sas.UUCP (John Toebes) (06/20/88)
In article <4508@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >On a related topic, does the Lattice 4.0 compiler do any (useful) >optimizations besides common subexpression? In particular, some of the RISC >compilers generate code that keep calculated addresses around, and all of the >RISC compilers seem to make every attempt to keep most-common-used variables >in registers (in fact, the Pyramid 90x compiler totally ignores the "register" >declarators, as far as I can tell -- at least, when you have fewer than 16 >local variables and 16 parameters). > >I've been looking at the code generated by the Manx 3.60 compiler, and it >looks pretty simplistic. Does Lattice 4.0 manage any better? > The Lattice 4.0 compiler has a fairly complex code generation scheme with both a forward and backward look at the code being processed. It performs: a) Common sub-expression elimination (over more than a simple basic block) b) dead code elimination (usually :-) c) Register tracking d) Condition code tracking e) conversion compression (int=>short = short=>int + short=>int as short = short+short) f) Optimized builtin functions g) common string elimination h) constant folding i) branch to branch supression j) indexing subsumption k) [my favorite because I thought it up] forward register merging across if/then/else statements and other nonsense. In addition, there is quite a bit of analysys involved with register tracking and selection making it much more complex than a simplistic pattern matching code generator often found with PCC and its derivatives. (No cut intended) Even with all it does currently, I am not yet satisfied (maybe I will never be) so this list constantly grows. >(& onrelated topic, SDB gurus my machine regularly, sigh). Have you called their tech support? That's what you pay for when you get a language product. >Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/
darin@nova.laic.uucp (Darin Johnson) (06/21/88)
In article <4508@killer.UUCP>, elg@killer.UUCP (Eric Green) writes: > In particular, some of the RISC > compilers generate code that keep calculated addresses around, and all of the > RISC compilers seem to make every attempt to keep most-common-used variables > in registers (in fact, the Pyramid 90x compiler totally ignores the "register" > declarators, as far as I can tell -- at least, when you have fewer than 16 > local variables and 16 parameters). This should be a feature of any compiler that optimizes. I have been a teaching assistant for C and compiler classes, and am amazed at the number of people who swear that 'register' is a direct order to the compiler ("Gee, no wonder it doesn't work, you have 17 register variables..."). I was absolutely flabbergasted when I looked at the output of one of the early Lattice compilers (I can't verify since I no longer have it). It would NEVER place automatic variables into registers UNLESS it was declared as 'register' (it would use registers for temporaries, thank heavens). I would also get error messages if I used an excessive amount of register declarations. For the money I paid, I would have expected the compiler to figure out on its own that something could be put into a register without a 'hint'. (Actually, when I wrote a compiler for the Pyramid, I thoroughly tested out the existing C and Pascal assembly outputs. You have to go to a lot of work just to get a variable that isn't in a register!! If the 16 local registers were allocated, it would use any unused parameter registers, etc. etc.) Darin Johnson (...pyramid.arpa!leadsv!laic!darin) (...ucbvax!sun!sunncal!leadsv!laic!darin) "All aboard the DOOMED express!"