Re: RISC

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Back when I was doing engine controls, we'd get started talking about how
the DEC compilers could generate different code depending on available
memory & what else was running, etc. Our Configuration Management person
would plug her ears and go "I can't hear you YAYAYAYAYAYAYAYA!!!!!!" :-) It
was a real worry for Formal CM that we couldn't absolutely GUARANTEE that
given the same source code, the same compiler, the same machine and two
different days of the week, that we couldn't get the same set of bits out
the back end.

However, I'd consider your statement about "not *ever*" to be a bit strong.
Remember that we were originally talking about doing an overlay by forcing
two things to reside at the same spot in memory. If I could get my compiler
to do this at all reliably for one structure, it would be a reasonably safe
assumption that on two different days of the week, that same structure is
going to reside at that same location in memory. (Otherwise, how do I deal
with memory mapped devices?) It also seems reasonable that if I got one "for
use at" to put something in memory at a specific location and another "for
use at" to put a different thing at the same location, and I don't switch
compilers, that on a different day of the week, I'll still have those two
things residing at the same spot in memory. (This sort of thing is done all
the time at low levels of code - getting access to the same physical memory
locations from two different perspectives/locations in the code.)

Granted, if I pull some sort of trick with access types and start counting
on an optimization to fool the compiler into dealing with an overlay, I may
have different problems. But I'm talking about a plain vanilla overlay.

At some point you have to have *some* level of trust (based on conversations
with your vendor, knowledge of the compiler, evidence in the documentation,
etc.) that even "erroneous" things will work properly within some known
parameters. Otherwise we're down to discussing what might happen to the code
if the sun expands to 10 times its current size and the Earth is totally
engulfed in fire. (I guess the program crashes and your rocket/payload
augers in - tough noogies! :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/



"Ted Dennison" <dennison@telepath.com> wrote in message
news:lW4u6.325$fy.827@www.newsranger.com...
> In article <99ae0k$g0j$1@nh.pace.co.uk>, Marin David Condic says...
> >
> >Very true. This is why lots of mission critical systems *freeze* a
version
> >of the compiler at some juncture in the project. Better the bugs you know
> >than to have something totally unexpected show up in a new release.
>
> But that isn't even sufficient to keep you safe from erronious code.
Assuming
> that the generated code might be affected by how the compiler decides to
> optimize (a quite reasonable assumption), then your code could cease to
work if
> any of the following happen:
>
> o  You recompile with a different set of options.
> o  You change a line of code somewhere in the entire system and recompile.
>
> and in some cases (notably the old DEC Ada compiler)...
> o  You compile on a different machine.
> o  You compile on the same machine, but with a different amount of free
RAM
> (different set of background processes running at the time).
>
> You really should not *ever* use erronious code unless you have some kind
of
> good assurance from your vendor that it will behave predictably (often the
> vendor docs will mention some such instances). I suppose having access to
the
> sources of your compiler and checking it over yourself might count, but
that
> would probably be more work than finding a better way.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>           home email - mailto:dennison@telepath.com