Self-modifying code

[Alan T. Bowler [SDG]]

In article <61781 at sun.uucp> guy at 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.