Path: utzoo!attcan!uunet!husc6!spdcc!ima!haddock!suitti From: suitti@haddock.ISC.COM (Steve Uitti) Newsgroups: comp.arch Subject: Re: using (ugh! yetch!) assembler Message-ID: <5892@haddock.ISC.COM> Date: 8 Aug 88 17:18:20 GMT References: <11701@steinmetz.ge.com> <933@esunix.UUCP> Reply-To: suitti@haddock.ima.isc.com (Steve Uitti) Organization: Interactive Systems, Boston Lines: 93 In article <933@esunix.UUCP> sedwards@esunix.UUCP (Scott Edwards)writes: >...but I think that the problem with the current HLL's [higher >level languages] is that they are not high enough, I would like a HLL >that knows about trees, linked lists, etc. and how to deal with them, >so I don't have to code all of the normal operations (insert, delete, >etc) on them every time I use one. C, like almost every other language ever invented, is also extensible. Old code can be reused in terms of libraries. Libraries can extend the capabilities. For example, "qsort" adds convient internal sorting. I'm a library fan. I try to put anything that remotely looks like a package into a library form, and try to reuse it whenever I can. There are several problems with libraries in the UNIX/C environment within the universe as we know it. 1) Local libraries tend not to get distributed (and worse, they tend not to get distributed with local code). 2) The documentation for code tends to get seperated from the original source (the only copy is often put into /usr/man, which is thrown out on each machine/OS upgrade), and does not get distributed with the source. 3) People are often unwilling to distribute code in source form, and every machine in the universe has a unique object code format and environment. Distributers cannot afford to own or have access to every instance of this mess, and it is expensive to keep porting the code. 4) Some programers think that for a program to be portable, it must use only libraries available on the distribution. Thus the only supported libraries tend to be those distributed commercially in source form (dbVista, for example), and those distributed with operating systems. 5) Libraries lack proper "for internal use" and global semantics. Basically, if you have two source files, which want to access a common (for example, state) variable, the varible must be global. If the library does not actually want to export this varible to the caller's environment, that's tough. This is mainly why "dbm" is all one file. There are, however a couple routines from "dbm" that my programs never use. The linker will not leave this dead code out, because the source is all one file. Back to HLL vs Assemblers "The problem with C is that it has these convenient optimizations always available." It was an interesting quote. It doesn't say that C does not provide high enough level semantics, it says that the lower level semantics tend to get in the way. C provides all the higher levelness (and more) of Fortran. There are poor Fortran compilers (is there a good UNIX Fortran? - maybe DEC's VMS fortran as ported to Ultrix...), just as there are poor C compilers. There are also some pretty good C compilers. I like having those convenient optimizations available. Code is never quick enough (or small enough, or...). Whatever the final result is, it is a compromise with factors such as how often it will be run, how much time is available to beat on it, etc. Generally, a reasonable approach tends to be one that uses the available tools for analysis (a brain, a profiler, etc.), then looks for improvement from the highest level of abstraction to the lowest. Thus, start with the algorythm (if this is changed, this other thing won't have to be called so often), then with the language in use (the compiler will do better with a "do { } while();" here than a "for (;;);" loop here, perhaps due to the number of tests per loop...), then the code produced (see what the compiler did for this routine, take out half of the subroutine call overhead, then remove a few redundant instructions...). Back when people tended to use assembler for the whole project, it was tougher to do the first couple of steps. Also, profilers tended to not exist or were real primitive (you could sample the PC now and again & see where it happened to be on some systems, watch blinking lights on the front panel on others). More recently, profilers can tell you how much time is spent in a routine with how much of that is spent in service to other particular proceedures. Better information is better. On the other hand, when people wrote stuff in assembler, it tended to be real small. Real small means fast startup time, even (especially?) on demand paged systems. I personally can't stand an editor that takes up more than about 100K bytes. Unfortuntely, multi megabyte applications seem to be the current trend. Even my favorite, C, can generate a 7K program for "hello world" on some systems (printf calls in most of stdio...). Lisp, and lots of new languages often start at a megabyte... There are still a few people out there who believed the original idea that libraries can make a language (even assembler) extensible. There are still a few people out there who "do it" with assembler for real applications. The people get real good results, even today. In fact, the only time one can fail is when one gives up. I remember CP/M days when 8080 assembly tended to be more portable than anything else, for various reasons. On the other hand, Mac applications, even written in C, tend not to be very portable to other architectures (or vice versa). There are no absolute truths. Stephen Uitti.