Xref: utzoo comp.lang.c:11819 comp.arch:6060 Path: utzoo!utgpu!water!watmath!atbowler From: atbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Message-ID: <20349@watmath.waterloo.edu> Date: 14 Aug 88 17:06:44 GMT References: <5262@june.cs.washington.edu> <260@thor.wright.EDU> <479@m3.mfci.UUCP> <482@m3.mfci.UUCP> <61781@sun.uucp> Reply-To: atbowler@watmath.waterloo.edu (Alan T. Bowler [SDG]) Organization: U. of Waterloo, Ontario Lines: 30 In article <61781@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: > >What if they look at the microcode, or directly at the hardware (if the >underlying machine isn't implemented using microcode)? In order for the >environment to be truly airtight, the microcode (or hardware) has to be >airtight. > >It may be that producing a sufficiently airtight compiler that implements the >object-oriented model by producing the "right" code, including checks, is >either impossible or more costly than producing a microcode or hardware >implementation atop a compiler that doesn't have to be so airtight because the >microcode or hardware is. If people's experience points in this direction, >fine. > Perhaps this is the wrong question. There is also the danger that the existence of the manditory checks will increase program complexity as the programmer finds that he has to program arround the environment to accomplish the task. A classic example are those Pascal programs that allocate 1 large static linear array and then run their own memory allocator withing it. Instead of machine pointers they pass arround indexes into the array. This has defeated the purpose of the Pascal tight checking, reintroduced all the old danger of running off the end of your allocated memory (into a chunk logically attached to another pseudo pointer), and increased the notational complexity of the program (and probability of errors). If you examine these programs and what they accomplish, you will usually conclude 1) This was the best choice that could be made given the constraints of the language 2) The programmer must have been persistent to get the thing working at all.