Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!ritcv!cci632!rb From: rb@cci632.UUCP (Rex Ballard) Newsgroups: comp.lang.misc Subject: Re: assembly programming prefereable to HLL programming ? Message-ID: <712@cci632.UUCP> Date: Tue, 9-Dec-86 13:19:14 EST Article-I.D.: cci632.712 Posted: Tue Dec 9 13:19:14 1986 Date-Received: Wed, 10-Dec-86 03:51:41 EST References: <646@instable.UUCP> Reply-To: rb@ccird2.UUCP (Rex B) Organization: CCI, Communications Systems Division, Rochester, NY Lines: 70 Keywords: programming language comparison Summary: Primatives vs. Languages. In article <646@instable.UUCP> orr@instable.UUCP (Orr Michael ) writes: > Have you seen an article in "Computer Language" magazine >of Oct. 86 about "Universal assembly language" ? > This article claims that it is (always/usually) better to >use assembly language rather than HLL. (any). this is based on the >following claims: > > 1. The ONLY siginificant advantage of HLL is a shorter CODING time. I wonder what HLL he was comparing. I don't know of any assemblers that do the error checking to the extent of lint. I would guess that the author also has a "bottom up" style of implementation, which means debugging and testing the primatives before moving to higher levels. > 2. Design, documentation, testing time is (almost) the same in both cases. Again, this depends on the development environment. On a per line basis, given a fully debugged library, it can be possible to keep assembler costs down. Unfortunately, most assembler environments do not provide for unit testing. The end result is that even with good primatives and macros, one is still faced with testing say, 10,000 lines of assembler code on a target machine which may have minimal debugging tools, or unit testing C code on the development machine and than testing the port to the target. > 3. The assembly program will run 2-5 times faster. This seems to be true when assembly routines are not re-entrant and module interconnectivity (which registers are significant...) are not critical issues. Unfortunately, good primatives are difficult to connect if they use frames rather than registers. > 4. So, after enough runs of the program the coding time gap will be > swallowed. From then on, the assembly program gains non-stop. Assuming that there is only one release, and no intent to upgrade the system, this may be true. Unfortunately, because of the "batch mode" environment of assembler, not every path is always tested. > Seems to me that this does not hold water. > 1. No mention of changes/maintenance issues anywhere. Perhaps the author has not been required to work on a product that required frequent enhancements. More importantly, the it would appear that the author has never had to work on someone elses large system, written entirely in assembler. > The author also suggests a "UNIVERSAL ASSEMBLER" to run on many machines. >I think FORTH already fits the bill, & has many other advantages. It sounds more like the old dream of UCSD Pascal P-code. If forth had some "standard entry vectors", it could possibly fit the bill, but the biggest problem there is that portability is strictly at the source code level, lacking intermediate "object code". My observations of most "language/assembler" debates is that programmers often defend the working environment of a language, rather than the merits of the language itself. An interactive environment like FORTH or Prolog is preferable to a batch/target environment. This does not mean I would prefer a "Batch mode FORTH" to an "interactive C" environment. I can't help but think the author is defending a programming style, and environment, rather than the language itself. Finally, there is the issue of the "right tool for the right job". I use several different languages, ranging from assembler and C to Lex, Yacc, and Prolog. I wouldn't want to do a communications driver in Prolog, and I wouldn't want to do an associative data base in assembler. I also don't use a hammer to drive screws, or a wrench to drive nails. Rex B.