Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!bloom-beacon!eru!hagbard!sunic!cs.umu.se!dvljrt
From: dvljrt@cs.umu.se (Joakim Rosqvist)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Self modifying code
Message-ID: <1991May30.005339.14067@cs.umu.se>
Date: 30 May 91 00:53:39 GMT
References: <5005@orbit.cts.com> <1991May28.120630.10150@cs.umu.se> <1991May28.171342.31105@kuhub.cc.ukans.edu>
Sender: news@cs.umu.se (News Administrator)
Organization: Dep. of Info.Proc, Umea Univ., Sweden
Lines: 44

>
>> 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.

I guess that version of the OS will not work on a 68000 anyway.
On a 040 there would be no reason to have the code duplicated several times
since a dbra loop from will be just as fast (valid even on '020, 30 ?)

On the 68000, I could unwind with no problems, since there is no cache,
right?

>
>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.
>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.

It was intended as an example of code that has to be rewritten once before
it can run, much like if the code was crunched. And of course I would have
320 copies of _the_routine_that_draws_a_pixel_ rather than 320 copies of
a call to that routine.


 /$DR.HEX$
 
 --------------------------------------------
 Email to:  dvljrt@cs.umu.se
 2 Windows on the screen?  Oh no, not me.  I just Logout & Go.