Path: utzoo!attcan!uunet!husc6!think!ames!pasteur!ucbvax!NSWC-OAS.ARPA!dsill From: dsill@NSWC-OAS.ARPA (Dave Sill) Newsgroups: comp.lang.c Subject: Re: using (ugh! yetch!) assembler Message-ID: <8808160906.aa05339@SMOKE.BRL.MIL> Date: 16 Aug 88 13:06:24 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: Naval Surface Warfare Center, Dahlgren, VA Lines: 26 l.cc.purdue.edu!cik@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.