using (ugh! yetch!) assembler

[Dave Sill]

l.cc.purdue.edu!cik at k.cc.purdue.edu  (Herman Rubin) writes:
>Another problem is the fact that what one can do with a single instruction
>on one machine takes many on another.  An example is to round a double 
>precision number to the nearest integer.  If you think this is unimportant,
>every trigonometric and exponential subroutine, or a subroutine computing
>elliptic functions, etc., uses this or something similar.

It's not that "we" think it's unimportant.  It's kinda like saying
"This hammer is inadequate.  I can't even drive screws with it."

>I wonder how difficult it would be to use an overloaded operator
>weakly typed assembler.  Some think that C is this; maybe it was
>intended as a replacement for such an object, but it fails badly.
 
Yes and no.  As we all know, C was designed for systems programming.
It provides the system programmer with an easier to use interface to
the machine than assembler, is far more portable than assembler, and
in most cases obviates the need to use assembler for system
programming.  If you expect C to do more, i.e., be a portable
assembler for all machines, of course it will have some problems.
 
As Kernighan and Ritchie say in their recent article in Byte (I'm
paraphrasing), it's a tribute to C that there is so little assembler
programming being done by systems programmers today.  If you've ever
had the "honor" of doing systems programming on a system that didn't
have C, you can really appreciate this.