Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!husc6!cs.utexas.edu!ut-sally!nather
From: nather@ut-sally.UUCP (Ed Nather)
Newsgroups: comp.lang.c
Subject: Re: Self-modifying code
Message-ID: <12382@ut-sally.UUCP>
Date: 14 Jul 88 15:36:11 GMT
References: <225800044@uxe.cso.uiuc.edu> <1100@nusdhub.UUCP>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 27

In article <1100@nusdhub.UUCP>, rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
> "self modifying code" are things (in IBMPC assem) like:
> 
[ code omitted]
> 
> Where an entry condition changes the body of the code to reflect
> the data, instead of writing the code to handle every inline
> possibility as inline options.  This is bad practice, and nearly
> impossible to follow when the substitave code sections are larger.
  
Large programs written in assembler are hard to follow under any
conditions.  If the code is carefully documented, with the *intent*
of the code clearly spelled out, I don't think this is harder to
follow than any other technique, and I don't agree that it is "bad
practice."  If it keeps a volatile display from blinking, which it
can because it can be much faster that branch-and-test-condition code,
then I would label it as *good* practice.

It would be even better if it could be done in a HLL like, say, C --
with dangerous and confusing possibilities sharply restricted by the
language itself so the resulting code can be readily understood.  That 
was the idea behind "structured programming," back when it was a religion.

-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin
{backbones}!{noao,ut-sally}!utastro!nather
nather@astro.as.utexas.edu