radford@calgary.UUCP (Radford Neal) (05/20/86)
In article <3700003@uiucdcsp>, johnson@uiucdcsp.CS.UIUC.EDU writes: > > I consider designing assembler code using a high-level language to be > "motherhood". I have always done it that way (since I wrote my first > big assembly program in 1976), I thought most "modern" programmers did > it that way, and I teach all my students to do it that way. Am I > hopelessly naive? Yes. The modern programmer only writes in assembly language if he needs to utilize machine features not possible from a high level language or he needs to get that last bit of speed. In neither case is writing the program in C first especially helpful. Note that nobody writes "big" assembly language programs anymore. For example, the last chunk of assembler (VAX) I wrote was for catching a Unix signal, forking, letting the parent continue, and doing a core dump (via setting the trace trap bit in the PSL) in the child after fiddling the stack frames to reflect the situation before the signal in the parent, so the debugger will print out the right stack trace, etc. Part of this was in C, but the part that wasn't was completely unexpressible in C. The last (relatively) large piece of assembler (68000) I wrote was a set of bit-map manipulation routines. This was in assembler for efficiency. It used techniques such as completely unrolling a single-instruction loop (executed at most about 50 times) and branching into it at the right place, based on the instructions all being two bytes in size. Not the sort of this one does in C, or that one does in assembler if you start from a C program. It's fast though. All this may not be true if you're stuck writing assembler on a machine without an adequate high level language, but I presume that this is no longer common. It also doesn't directly apply when you're writing a large assembler program because you're learning about assembly language. Starting from C might be good in that case. Then again, maybe it would just lead to the student not leaning anything about machine architecture that isn't expressible in in C. Radford Neal
jbuck@epimass.UUCP (Joe Buck) (05/23/86)
In article <132@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes: >> >> I consider designing assembler code using a high-level language to be >> "motherhood". I have always done it that way (since I wrote my first >> big assembly program in 1976), I thought most "modern" programmers did >> it that way, and I teach all my students to do it that way. Am I >> hopelessly naive? > >In article <3700003@uiucdcsp>, johnson@uiucdcsp.CS.UIUC.EDU replies: >Yes. The modern programmer only writes in assembly language if he needs >to utilize machine features not possible from a high level language or >he needs to get that last bit of speed. In neither case is writing the >program in C first especially helpful. Note that nobody writes "big" >assembly language programs anymore. >... >All this may not be true if you're stuck writing assembler on a machine >without an adequate high level language, but I presume that this is no >longer common. Those of us who do real-time digital signal processing write lots of assembler, and for heavily pipelined, irregular architectures. The kinds of things we program can be done in high-level languages, only orders of magnitude slower. Compilers are few and far between. I personally follow the "human compiler" approach, translating C to DSP code and letting the C routine serve as part of the documentation. I find C to be the most natural language to do this with because of its "close-to-the-machine" style. Obviously we need net.dsp to discuss such things. -- - Joe Buck {ihnp4!pesnta,oliveb,csi}!epimass!jbuck Entropic Processing, Inc., Cupertino, California Better living through entropy!
kjm@ut-ngp.UUCP (05/24/86)
> [...] Note that nobody writes "big" > assembly language programs anymore. [Radford Neal] I have written many, many lines of assembler in the past 5+ years. (I don't know the exact number of lines, but it has to be in the tens of thousands.) I'm currently finishing off a project which will be close to 10,000 lines, all in assembler. BTW, I have never used an HLL as a "precursor"; I think that is a truly preposterous idea. I have, however, used various sorts of assembler-like "pseudo-codes", on occasion. -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cat and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ngp.{ARPA,UTEXAS.EDU} [Old/New Internet; depends on nameserver operation] kjm@ngp.CC.UTEXAS.EDU [Very New Internet; may require nameserver operation]
greg@utcsri.UUCP (Gregory Smith) (05/25/86)
In article <132@vaxb.calgary.UUCP> radford@calgary.UUCP (Radford Neal) writes: > >Yes. The modern programmer only writes in assembly language if he needs >to utilize machine features not possible from a high level language or >he needs to get that last bit of speed. In neither case is writing the >program in C first especially helpful. Note that nobody writes "big" >assembly language programs anymore. >... >All this may not be true if you're stuck writing assembler on a machine >without an adequate high level language, but I presume that this is no >longer common. It also doesn't directly apply when you're writing a ... > > Radford Neal It's still pretty common, and probably will be for some time. Consider the ratio Quality of hand-written code ------------------------------------ Quality of code from a good compiler I would expect around 1.2 for a 68000 (the only 68K C compiler I've seen was about a 1.7 but it wasn't *good*). However, I imagine a *good* 6502 compiler would do well to score a 10 ( There's still a *lot* of those little beasties out there...). More importantly, there are those great little single-chip computers ( 8048, 6805 etc ) which would probably also come up in the 10-15 range on the above ratio. Since you have limited ROM ( meaning that every byte counts and you can't write a *really* long program, anyway ), I doubt that anyone has tried to write a compiler for these guys. You program them in assembler, that's all. If you don't think these things are common, take a good look at auto electronics. Someday, auto computers may be programmed in C ( or D or E..), but they will probably still be hand-coding digital watch controllers. When *those* are compiled, they will be hand-coding automatic electronic pencil controllers... The world isn't all 68K's and vaxen and stuff like that... -- "We demand rigidly defined areas of doubt and uncertainty!" - Vroomfondel ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
shepherd@euroies.UUCP (Roger Shepherd INMOS) (06/07/86)
In article <438@ccird1.UUCP> Rex Ballard writes: > All High level languages do is attempt to organize the > macros and subroutines that might otherwise be written in > assembler. They also provide some convenient and well > standardized procedures and parameter passing conventions. I disagree with view. A high level language should be more than a glorified macro assembler. It is possible to design a high level language so that it actually has a clean, coherent and useful semantics. It can then be used as a way of describing algorithms mathematically. Such langauges can even be compiled! Of course, very few existing HLLs have such a semantics. However, I have been useing one that does and one which compiles effeciently onto a processor. Furthermore, its mathematical semantics is useful and COST-EFFECTIVE. One of the projects which I have been involved with is the production of a HLL coded version of the IEEE Floating Point standard. Out initial efforts at writing and testing said package were very labourious and insecure. We tried testing the package by comparing it with what were believed to be correct implementations. This lead us to find an error in a currently available floating point chip! The adoption of formal mathematical methods (to which our HLL is suseptable) means that a correct version was produced in a few weeks. -- Roger Shepherd, INMOS Ltd, WHITEFRIARS, LEWINS MEAD, BRISTOL, UK USENET: ...!euroies!shepherd PHONE: +44 272 290861
rb@ccird1.UUCP (Rex Ballard) (06/12/86)
In article <316@euroies.UUCP> shepherd@euroies.UUCP (Roger Shepherd INMOS) writes: >In article <438@ccird1.UUCP> Rex Ballard writes: >> All High level languages do is attempt to organize the >> macros and subroutines that might otherwise be written in >> assembler. They also provide some convenient and well >> standardized procedures and parameter passing conventions. > >I disagree with view. A high level language should be more than a glorified >macro assembler. It is possible to design a high level language so that >it actually has a clean, coherent and useful semantics. It can then be used >as a way of describing algorithms mathematically. Such langauges can even >be compiled! In a sense, I agree with you. What you're describing is the human->compiler side of what a language should be. I am describing what the compiler->machine side should be. How good the interface between the two view is, is a good definition of the quality of a compiler. If restricitions are loose enough reguarding the nature of the variables, definitions, and operators, one could express algorythms in "structured english" (as opposed to the hodge-podge we normally atribute to the language), and have it compiled into a sequence of subroutines, macro expansions, and instructions which could be executed by a computer. On the other hand, "structured english" is a little tedious to type. Perhaps a "Decompiler" could translate 'C' code tokens into structured english :-). Not only could it be compiled into instructions, it could also be compiled into useful data bases, flow charts, structure charts, and even "design completers" which could find common primitives in complex systems, and express them in the same structured language. These 'design completers' are more commonly referred to as optimization, but often the input, as well as the assembler could be optimized by machine, leaving only the most commonly executed parts of the code to be "super-optimized" by hand, or even hardware. >Of course, very few existing HLLs have such a semantics. However, I have been >useing one that does and one which compiles effeciently onto a processor. Which language is this? >Roger Shepherd, INMOS Ltd, WHITEFRIARS, LEWINS MEAD, BRISTOL, UK Nice company, looking forward to seeing more info on your products.
de@comp.lancs.ac.uk (David England) (06/17/86)
In article <473@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >In article <316@euroies.UUCP> shepherd@euroies.UUCP (Roger Shepherd INMOS) writes: >>In article <438@ccird1.UUCP> Rex Ballard writes: >>> All High level languages do is attempt to organize the >>> etc >> >>I disagree with view. A high level language should be more than a glorified >>macro assembler. >>etc > >In a sense, I agree with you. What you're describing is the human->compiler >side of what a language should be. I am describing what the compiler->machine >side should be. > ... and as far as the human->compiler side of things is concerned the days of languages are numbered. Visual programming and spatial data management are the "languages" of the future. In five years time there should be no net.lang* :-). If this was a bit mapped screen I would draw this article as a vt100 icon being thrown into a trash can icon :-). -- Dave uucp: ...!mcvax!ukc!dcl-cs!de arpa: de%lancs.comp@ucl-cs "I like to go where the action is. Move in, move out. And no paper work."
henry@utzoo.UUCP (Henry Spencer) (06/17/86)
> > All High level languages do is attempt to organize the > > macros and subroutines that might otherwise be written in > > assembler... > > ...A high level language should be more than a glorified macro assembler... In particular, a high-level language should do its best to check the programmer's code for errors -- something no macro assembler will ever be able to do very well. Features like type checking are not mere frills; they catch many errors. Decent high-level languages give the translator a much better grasp of what the programmer is doing, so it can point out inconsistencies. (It can also optimize the code better -- most hand-written assembler is not highly optimized, because it's too much work for a human.) -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
ggs@ulysses.UUCP (Griff Smith) (06/19/86)
[deleted fine, clear comments about the importance of type checking] > Decent high-level languages ... > ... can also optimize the code better -- most hand-written > assembler is not highly optimized, because it's too much work for a human. Most UNIX system hand-written assembly language is suboptimal because the programmers haven't learned the coding idioms and/or don't give a damn. Humans can do a fine job of optimizing assembly language; they are much better at recognizing special case optimizations that are too expensive/unlikely to put in an optimizer. My code, when it worked, was tight and more optimized than I have seen in most compilers. What usually made my assembly code sub-optimal was the need for parameterization: I had to MOV a parameterized zero into a register instead of CLRing it, etc. I will completely support a paraphrase of Henry's quote: most hand-written assembler code is incorrect; finding all the inconsistencies is too much work for a human. I once spent three days finding a "character with a 3 in it" when I intended to declare an "array of 3 characters". Lint would have found it in 30 seconds. > -- > Usenet(n): AT&T scheme to earn > revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology > late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry Keep that revenue coming, folks. Thank you for using AT&T. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 UUCP: {allegra|ihnp4}!ulysses!ggs Internet: ggs@ulysses.uucp
henry@utzoo.UUCP (Henry Spencer) (06/20/86)
> > Decent high-level languages ... > > ... can also optimize the code better -- most hand-written > > assembler is not highly optimized, because it's too much work for a human. > > Most UNIX system hand-written assembly language is suboptimal because > the programmers haven't learned the coding idioms and/or don't give a > damn. Humans can do a fine job of optimizing assembly language; they > are much better at recognizing special case optimizations that are too > expensive/unlikely to put in an optimizer. My code, when it worked, > was tight and more optimized than I have seen in most compilers... Note that I said "highly" optimized. When I say that, I mean the sort of code where one spends long periods of time re-writing the code to make the code a few words shorter or a few microseconds faster. Note also that I was not talking about "most" compilers -- I was talking about what the language could do, i.e. what a really hot optimizing compiler could do. The very best optimizing compilers are just as good at recognizing special cases and exploiting them as humans, and they are much better at doing the bookkeeping necessary to do this without error. Building such a compiler is a tremendous amount of work, of course, not least because one must teach it about all those obscure special cases. (The Bliss-11 compiler actually looked to see if it could save a word of "immediate" data by using the next instruction's opcode as the data. Few humans go that far!) It also tends to be huge and slow. But once you've got it, it's a much better way of producing really hot code than doing it yourself. I fully agree that human assembler programmers can easily produce rather better code than the mediocre results from many compilers. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry