Xref: utzoo comp.lang.c:11472 comp.arch:5657
Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!husc6!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Message-ID: <477@m3.mfci.UUCP>
Date: 24 Jul 88 14:38:02 GMT
References: <5262@june.cs.washington.edu> <260@thor.wright.EDU> <759@cernvax.UUCP> <472@m3.mfci.UUCP> <60782@sun.uucp> <473@m3.mfci.UUCP> <1988Jul23.221743.22169@utzoo.uucp>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 58

In article <1988Jul23.221743.22169@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <473@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes:
>>... The capability people argue that the same
>>thing extends into all areas of computer systems.  Recall the classic
>>arguments about turning off runtime bounds checking to reclaim that
>>lost performance -- why should a programmer, in the best of all
>>possible worlds, have to worry about things like that?  ...
>
>My counterargument is that it is almost as much of an imposition on the
>programmer to have such checks done at runtime as it is to have them not
>done at all.  Given the impossibility of complete testing, there is no
>way to guarantee such tests will catch a bug during development.  This
>means that the programmer has to go through the same complicated exercise
>of trying to assure himself that the problem will never happen.  What is
>really wanted is a way to check these properties at COMPILE TIME... in
>which case the runtime checks become largely superfluous anyway.

We probably agree that the compiler should check as much as it
possibly can; the earlier an error is detected, the less the
ambiguity about what is wrong and the cheaper the cure.  But there is
an awful lot the compiler can't know about -- programs that use input
data, generate pointers, or do just about anything else that's
interesting, are going to do many operations that are difficult for
the compiler to validate at compile time.

I'm not sure I catch your drift on the imposition of runtime checks.
To me, the best human debuggers have the ability to figure out the
fastest which assumptions are being made that are wrong, thus getting
to the heart of some problem the quickest.  If I have a program bug,
I want the machine to express as directly as possible the intent of
my program so that I can narrow the bug-space down to my code alone.
If the machine allows a change to one variable (an array, say) to
affect some other unrelated variable, then it is not conforming to
the intent of my program.  In fact, it is not conforming to anything
useful at all, since nobody would argue that it is useful programming
practice to ever do such a thing on purpose (I hope?).  Given that,
the fact that the machine can do such a thing, let alone do it as a
default, is what I'd label a shortcoming in the basic architecture.
One we've all long ago learned to live with, to be sure, but it's not
something to be proud of, at very least.

>Can it be done?  Well, in one sense the answer is clearly yes, because a
>proof of program correctness has to include it, and we know that automating
>such proofs is possible (although seldom practical at the moment).  The
>question is whether it can be done with practical, affordable machinery
>without crippling the language.  My own long-held conjecture is that the
>answer is "yes", but I don't have proof of that yet.

I sure hope you're right.  In fact, if progress towards this goal
becomes evident, I'd propose we start discussing ways of turning
architecture towards better ways of supporting this instead of
throughput or programming environments.


Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090