Interactive Programming - Self-modifying code

Forwarded message:

> From: Brandon Crosby <bcrosby@mncs.k12.mn.us>
> Subject: Re: [LONG, off-topic]] Interactive Programming
> Date: Mon, 20 Oct 1997 10:22:23 -0500 (CDT)

> > As are some perl programmers.  As both a perl programmer and a lisp
> > programer I have never had the need to use self modifing code.  In fact I
> > would consider haveing to use s-m code as a sine that I have made a
> > mistate in my desinge.

Come on, tell us how you really feel...

What if your design specificaly includes self-modifying code for reasons of
execution speed or some recursive efficiency? Glad to know I don't have to
compete with you on those sorts of jobs...thanks.

> PERL is a pretty high-level language... how do you add sub's after
> running the code?

Well I would include all the possible functions I would need and then keep
some sort of array. Each branch point would depend upon the contents of that
array. When the program starts it would use either some default
configuration or perhaps the 'last-state' of the engine on the previous run.
Then as the contents of the array changed the dynamic configuration of the
sub-routines would change.

Another good mechanism is to store addresses in immediate mode, which means
the address is hard-coded. Then dynamicaly change the contents of the address
of that address. I once wrote a machine code utility that cleared large
blocks of RAM 256 byte pages at a time. Each time the code ran it would go
through and incriment the address stored in that address a fixed amount, the
page size, and then jumped back to the beginning of this single loop. Ran
very quickly. I used it to clear video ram faster than the os functions
could.


    ____________________________________________________________________
   |                                                                    |
   |    The financial policy of the welfare state requires that there   |
   |    be no way for the owners of wealth to protect themselves.       |
   |                                                                    |
   |                                       -Alan Greenspan-             |
   |                                                                    | 
   |            _____                             The Armadillo Group   |
   |         ,::////;::-.                           Austin, Tx. USA     |
   |        /:'///// ``::>/|/                     http://www.ssz.com/   |
   |      .',  ||||    `/( e\                                           |
   |  -====~~mm-'`-```-mm --'-                         Jim Choate       |
   |                                                 ravage@ssz.com     |
   |                                                  512-451-7087      |
   |____________________________________________________________________|

On 20 Oct 1997 18:43:14 -0500, Jim Choate <ravage@ssz.com> wrote:

>
>Forwarded message:
>
>> From: Brandon Crosby <bcrosby@mncs.k12.mn.us>
>> Subject: Re: [LONG, off-topic]] Interactive Programming
>> Date: Mon, 20 Oct 1997 10:22:23 -0500 (CDT)
>
>> > As are some perl programmers.  As both a perl programmer and a lisp
>> > programer I have never had the need to use self modifing code.  In fact I
>> > would consider haveing to use s-m code as a sine that I have made a
>> > mistate in my desinge.
>
>Come on, tell us how you really feel...
>
>What if your design specificaly includes self-modifying code for reasons of
>execution speed or some recursive efficiency? Glad to know I don't have to
>compete with you on those sorts of jobs...thanks.
>

I would think that self modifying code would play havoc with today's
pipelined and superscalar processors (if s&m code would even work on such
beasts).  Then they're those OS's that won't allow you to muck with code
space.  However, I guess it will always have a place in the embedded world.

-- Phelix

At 5:24 PM -0700 10/20/97, phelix@vallnet.com wrote:
>I would think that self modifying code would play havoc with today's
>pipelined and superscalar processors (if s&m code would even work on such
>beasts).  Then they're those OS's that won't allow you to muck with code
>space.  However, I guess it will always have a place in the embedded world.

All OSes have a form of self modifying code which fetches programs (as
data) from disk and then executes them (as programs) in memory.  They need
a way to flush the data cache so the instruction cache can read it.

The place where it becomes expensive in modern processors is when the
processor has seen a word as an instruction, and then you want to change it
and have the new value again interpreted as an instruction.  The way to
"legitimately" do this varies by processor.  IBM mainframes detect it
automagically and "do the right thing".  SPARCs require a special "flush"
instruction to clean out the processor I-cache/pipeline.


-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA