From: lasner@watsun.cc.columbia.edu (Charles Lasner)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner)
Organization: Columbia University
Date: Fri, 21 Aug 1992 01:57:41 GMT

In article <2282@devnull.mpd.tandem.com> rrt@amadeus.UUCP (Robert Teisberg) writes:
>
>>- When I want to test a particular bit in assembly language, I have
>>  several ways of doing it (in the Z80 for example I can rotate if it
>>  was the first or the last bit, I can mask and test, or I can do a bit
>>  test instruction). In some situations, some of these ways may be
>>  better than others. Example: I just read the status register from a
>>  device.  If I don't need the register any longer, I just mask the bit
>>  I want with an AND and check the result for zero/nonzero; this is the
>>  fastest method. If I care about the whole content, but need a quick
>>  look at the top or bottom bit, I rotate the registers so the desired
>>  bit walks into the carry flag and test that. Only if I really need the
>>  whole status register unmodified do I have to do a slow bit-test
>>  operation, or waste another register on saving/testing. How do you
>>  express these minute differences to your C compiler ?
>
>You don't if you're smart.  If your compiler can't tell that a value
>is no longer needed, you need a new compiler.  If you're using a
>processor for which it's hard for the compiler to choose the best
>instruction sequence, you need a new processor (this is what the RISC
>revolution is all about).  What do you do with your assembly language
>program when you discover six revisions later that after all you DO
>need the saved contents of the register 40 lines later?  Better yet,
>if you change a program that once needed to save the value in such a
>way that you can now safely discard it, do you recode the bit-test to
>make it faster, or do you leave it alone to avoid the risk of
>injecting a bug?  What if some future Z80 superset processor can do
>bit-tests faster than ANDs or rotates?  What do you do when you need
>to port your code to a 68000?  These are weighty issues if the program
>is written in assembler, but except for the last no one even thinks
>about them if it is coded in a HLL.

I don't think they are "weighty" any more than you would think that having
to define a few new variables in your hll code is "Weighty".  More like
mundane, routine, etc. is a better description.  To coin a phrase:
"That's why they call it SOFTware"

>
>>- If there is a useful routine (like output a character) which is
>>  provided with a strange calling sequence (the character has to be in
>>  register X and a function code in register Y), I can not use it from
>>  within C, because there is no general way to express all possible
>>  calling conventions. No problem from within assembler. If I even touch
>>  putc or printf I am deep in the mess of a horrible run-time-library,
>>  which is liable to be a lot less efficient.
>
>Let me express this a little differently.  If you are dependent on a
>run-time library which was designed to be used by assembly language
>programs, it is easier to use the library if you code in assembly
>language.  Why am I not surprised by this?  Most tools are easiest to
>use when they are used in the way in which they are designed.  
>
>As I said earlier about compilers, if your run-time library is
>horrible, you need a new run-time library.

That's an admission that hll libraries aren't all-purpose, which gets back
to the matter of suitability of choice of language, etc.

>>So, C is not the answer to all questions. There are LOADS AND LOADS of
>>things which can not be expressed in C; and there are some thing which
>>any HLL compiler will do less efficiently than handcoded assembly.
>
>Well, there are a few things.  There are also those who would argue
>that the problem with C is that it is a LOW-level language.  A
>high-level language would let you say what you mean rather than what
>you want the processor to do, and the compiler could choose the best
>implementation for whatever bizarre combination of hardware you care to
>to put it on.

I agree that there are some contrived problems that this is fine for, and
that C is the wrong tool for such and other kinds of problems as well.  For
certain applications, C is like a "poor man's assembler".

>
>>Note: I am not advocating writing everything in assembler. That's
>>crazy. But good hand-coded assembler still has its place, in
>>particular in the tight spots of device drivers and realtime systems
>>(where every clock cycle counts). Therefore I agree that assembler is
>>RARELY neccessary.
>
>Actually I agree with nearly every word of this paragraph.  However, I
>would point out that real-time programming is coming less-and-less to
>mean squeezing every clock cycle out of the code and more-and-more to
>mean making execution speed predictable (interestingly, the fastest
>systems available today are poorly suited to real-time applications
>because their performance is unpredictable).  What I'd really like is a
>high-level language that lets me express real-time constraints in a
>form that offers hints to the compiler about the appropriateness of
>trading off space for time and allows the compiler to tell me whether
>the constraints can be met.

The performance of computers hasn't changed much, other than raw speed.  The
abusive nature of bizarre O/S designs is what makes performance unpredictable.
This goes under the heading of using the wrong tool, etc. for the job.  There
have been real-time systems written even in hll that were predictable in
performance by excising them out of the more inefficient O/S environments
where they are developed.  Good assembly-language interrupt handling can
improve performance in these situations.

cjl

Newsgroups: alt.folklore.computers