Self-modifying code

[Robert C. White Jr.]

in article <225800044 at uxe.cso.uiuc.edu>, mcdonald at uxe.cso.uiuc.edu says:
> Nf-ID: #R:ut-sally.UUCP:12330:uxe.cso.uiuc.edu:225800044:000:2699
> Nf-From: uxe.cso.uiuc.edu!mcdonald    Jul 10 10:13:00 1988
>     Yes, it is and yes it is, but only by those who don't need it. There
> are good uses for self-modifying code: I have used it recently in
> two places (one on an IBMPC and the second on a PDP-11.
>      The first is the use of self-modifying code in 
> interrupt handlers. It is necessary sometimes to change data segment
> in such a handler. The only place to put the value for the data segment
> is in the code segment, because when the interrupt occurs, only
> the CS register is valid. You could quibble about whether this would
> be self-modifying code if you put the value out-of-line and got it
> through a pointer. This example was in assembler of course. 

Point 1)  This is _not_ "self modifying" code as I learned it...
"self modifying code" are things (in IBMPC assem) like:

tests:	jbne	27
	je	27
	ja	27

proc	aaa	far
	movsw	tests[SI],ordin
	test	AX,BX
ordin:	je	27
	...
	endp

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.

	

Point 2)  you should place all your data and code for an interrupt
on an IBMPC in one segment and reach it through CS anyway.  Once
there you may juggle registers to your hearts content.  To find
"local" data, you make load-address, or CS-segment-data-spaces to
store the relative information which you set up durring init, or even
as EXEC loader directives; to whit: dw CSEG; dw OFFSET init. (etc.)