Re: run-time libraries

gorton@blorf.ltn.dec.com (Richard Gorton)
Thu, 8 Oct 1992 14:20:27 GMT

          From comp.compilers

Related articles
Re: Compiler Libraries and/or built-in routines johnm@cory.berkeley.edu (1992-10-07)
Re: run-time libraries gorton@blorf.ltn.dec.com (1992-10-08)
| List of all articles for this month |

Newsgroups: comp.compilers
From: gorton@blorf.ltn.dec.com (Richard Gorton)
Organization: Compilers Central
Date: Thu, 8 Oct 1992 14:20:27 GMT
Keywords: library, comment
References: 92-10-028

johnm@cory.berkeley.edu (John D. Mitchell) writes:
>I would suspect that anybody who doesn't implement a reasonable math
>library was just lazy. :-? ...> Depending on the hardware/software/OS/etc.
>it can be trivial to reasonably difficult to efficiently support both
>hardware based floating point and software emulation.


Case in point being the writing of math routines to support Extended
precision floating point (96 bit) for the first time. How DOES one
represent those things in an implementation language which doesn't
inherently handle it? A structure of 3-32 bit integers and fiddle the bits
accordingly? Seems straightforward, but remember, the resulting routines
_have_ to be correct, and fast. A bit of chicken & egg problem. Does the
compiler understand the datatype first or do the appropriate routines get
written first?


Things like extended precision COMPLEX operations for FORTRAN are fairly
complicated to do, as well as adding a lot more complexity to the datatype
conversion area. Additionally, the compiler itself has to emit the
correct operators/datatype information about built-ins, and understand the
appropriate syntax.


If one isn't very careful about the runtime issues, innocuous looking
code can be performance bottlenecks. For example (this is an actual excerpt
from GCC's strstr() routine)
------------------------------


  1: register int len = strlen (s2);
  2:
  3: for (; (p = strchr (p, *s2)) != 0; p++)
  4: {
  5: if (strncmp (p, s2, len) == 0)
  6: {
  7: return (p);
  8: }
  9: }
10: return (0);


Seems innocuous enough, right? However, the strlen on line 1 causes the
entire string s2 to be traversed an additional (unnecessary) time. The
point is not to do GCC bashing, but rather that carefully crafted
run-times are also critical to achieve maximal performance.


------------------------------------
Richard Gorton Alpha Migration Tools - Digital Equipment Corp.
Reply-to: gorton@tallis.enet.dec.com
[In fairness, though, many CISC machines such as the 80x86 and Vax have
instructions that implement strlen(), strchr(), and strncmp() very
efficiently so this code could be faster than looking at each character
once in a loop. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.