Re: Unsafe Optimizations

leech@homer.cs.unc.edu (Jonathan Leech)
Thu, 21 Jun 90 03:32:41 GMT

          From comp.compilers

Related articles
Unsafe Optimizations vmars!alex@relay.EU.net (Alexander Vrchoticky) (1990-06-20)
Unsafe optimizations worley@compass.com (1990-06-20)
Re: Unsafe Optimizations leech@homer.cs.unc.edu (1990-06-21)
Re: Unsafe optimizations cik@l.cc.purdue.edu (1990-06-21)
Re: Unsafe Optimizations davidh@dent.Berkeley.EDU (David S. Harrison) (1990-06-22)
| List of all articles for this month |

Newsgroups: comp.compilers
From: leech@homer.cs.unc.edu (Jonathan Leech)
References: <1990Jun20.040752.15243@esegue.segue.boston.ma.us>
Date: Thu, 21 Jun 90 03:32:41 GMT
Organization: University Of North Carolina, Chapel Hill
Keywords: optimize, code, design, debug

In article <1990Jun20.040752.15243@esegue.segue.boston.ma.us> henry@zoo.toronto.edu 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
pointers.


        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 (leech@cs.unc.edu) __@/
--


Post a followup to this message

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