Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!markv
From: markv@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Self modifying code
Message-ID: <1991May28.171342.31105@kuhub.cc.ukans.edu>
Date: 28 May 91 17:13:42 CDT
References: <5005@orbit.cts.com> <1991May28.120630.10150@cs.umu.se>
Organization: University of Kansas Academic Computing Services
Lines: 72

In article <1991May28.120630.10150@cs.umu.se>, dvljrt@cs.umu.se (Joakim Rosqvist) writes:
> Ok, I have heard before that you should not use self modifying code.
> Can anybody give a good reason for this, besides it being bad programming
> pratice. 
> I just got the RKM manuals and they only stated "for compatibilty with
> 010/020/030 etc. don't use selfmodifying code"
> Could it be that data written to an address that is also in cachememory
> will update the memory, but not the cache?

Well, sort of.  The Motorola family has *seperate* code and data
spaces, and in fact may have drastically different memory used for
each (if you had a machine that used the FC pins for this purpose).

When you fetch an opcode, it goes in the code cache.  When you write
out self modifying code, it goes in the data cache and memory.  So the
entry in the code cache is still thought of as valid.  You can play
some games by only writing code, but then you could get tripped up on
data caches that don't do an immediate write through to memory (quite
possible on an 040).  The only thing that should be writing code to memory is
the OS loader ;-).

> Consider for instance that I would like to write a fast completely
> unwinded linedrawing routine and wrote code for drawing one pixel.
> Then when the program start, I would allocate memory for 320 such routines
> and putting 320 copies of my routine there. Would this be considered as
> selfmodifying code, and therefore forbidden?

Yes, for two reasons.  In practice on the current Amiga it would
probably work assuming you wrote the code before any was executed.
However, in future OSs, where the MMU has pages flagged as CODE or
DATA, or future hardware that plays cache control games with a large
external cache (using the FCx and CIN lines), you could still barf.
Under 2.0 the legal way to do this is write you routines and then call
CacheFlush(). (Not very friendly to the OS to do it too often, but
okay for a one shot deal).  Future OSes that use the MMU actively will
likely have the calls to play with the attributes of memory, whether
its a code page or data page, whether its cachable or not, etc.

Second, in this case I think your idea is dumb, unless I misunderstand
your plan.  If you have a routine for Each pixel, then you have to
loop and read and write a value for each pixel, with a BSR or JSR and a RET.
This isn't fast.  On the otherhand, if you loop, or special case
things, use are moves, then you only have one write for 16 or 32
pixels a lot of times.  Finally, the blitter is great for fast lines,
and faster than the CPU unless your on a 3000 and optimize you code
just right.

> If so, compare it to when the OS is loading a program that contains
> non-PC relative references to itself which will have to be rewritten
> depending on the address the code was loaded to.

The OS is special.  The "loader" will always have the hooks to make
sure the OS and cache is happy.  With simple stuff you can work around
it, but as I said, with fancy stuff like uncomitted writes and bus
snooping and the use of the FCx lines, you not guarenteed to be safe
for long.  The 040 is here and can do all of these things right now
with the right implementation.

> /$DR.HEX$
> 
> --------------------------------------------
> Email to:  dvljrt@cs.umu.se
> 2 Windows on the screen?  Oh no, not me.  I just Logout & Go.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum			Only...		\    Good Cheer !!!
Academic Computing Services	       ///	  \___________________________
University of Kansas		     ///  /|         __    _
Bix:	  mgooderum	      \\\  ///  /__| |\/| | | _   /_\  makes it
Bitnet:   MARKV@UKANVAX		\/\/  /    | |  | | |__| /   \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~