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