|Unsafe Optimizations vmars!alex@relay.EU.net (Alexander Vrchoticky) (1990-06-20)|
|Unsafe optimizations firstname.lastname@example.org (1990-06-20)|
|Re: Unsafe Optimizations email@example.com (1990-06-21)|
|Re: Unsafe optimizations firstname.lastname@example.org (1990-06-21)|
|Re: Unsafe Optimizations davidh@dent.Berkeley.EDU (David S. Harrison) (1990-06-22)|
|From:||email@example.com (Jonathan Leech)|
|Date:||Thu, 21 Jun 90 03:32:41 GMT|
|Organization:||University Of North Carolina, Chapel Hill|
|Keywords:||optimize, code, design, debug|
In article <1990Jun20.firstname.lastname@example.org> email@example.com writes:
>The one thing a fascist language really *can* accomplish is to protect
>you from your own mistakes. That is indeed valuable; the trick is to
>balance protection with utility, so you get a reasonably-safe tool, not
>a completely-safe playpen.
After using the Saber-C interpretive environment for a while, I
find it offers the protection without the loss of utility - and the
code will be compiled later for speed. I'm getting to the point where
my first reaction to almost any problem is to run the code under
Saber, because it's so effective at finding runtime problems like bad
In another context, re unsafe optimizations - right at the moment
I could do without *unwanted* optimizations. We're bootstrapping the
OS on a homegrown i860-based multicomputer, with minimal debugging
tools. It would be handy to turn the damned optimizations off so we
could better understand the assembly language being run.
Unfortunately, the compiler we're using doesn't allow this!
Jon Leech (firstname.lastname@example.org) __@/
Return to the
Search the comp.compilers archives again.