Path: utzoo!utgpu!news-server.csri.toronto.edu!qucdn!leek Organization: Queen's University at Kingston Date: Thursday, 30 May 1991 13:46:43 EDT From: Message-ID: <91150.134643LEEK@QUCDN.QueensU.CA> Newsgroups: comp.sys.amiga.programmer Subject: Re: Self modifying code References: <5005@orbit.cts.com> <1991May28.120630.10150@cs.umu.se> In article <1991May28.120630.10150@cs.umu.se>, dvljrt@cs.umu.se (Joakim Rosqvist) says: > >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. It is because these processors have separate data & instruction caches. Question: So like if I turned off the cache, would it work then ? Answer: Sure... but turning off the cache means large drop in performance. Much greater than you would get for just saving a few instruction cycles. Flushing the cache is a big speed penality (worst if it is big) if you do it often enough. (Motorola does not support use of self-modifying code. Look at what Intel have to do (an unified cache for code & instruction vs Motorola's separate caches that allows parallel fetch (reads FASTER) to I&D). Among other things, the use of bad programming practices might cause limits on future hardware designs due to compatiblity issues. (as witnessed in PC.)) >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? > >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? It might fly on a 68000, but barely move on 020/030/040 etc if the user have to turn off their caches to make this thing run at all or worst have to fall back on 68000 mode (if one exists and most likely without 16-bit ram) because someone used some illegal move sr instructions to save an OS call. > >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. Yes, but the OS should be the only place where this should be happening. There might be some OS routine that your program can call to load in these routines for you and make sure everything works. > >/$DR.HEX$ > >-------------------------------------------- >Email to: dvljrt@cs.umu.se >2 Windows on the screen? Oh no, not me. I just Logout & Go. K. C. Lee "Be careful of what you wish for. You might get it."-Master Splinter. T.M.N.T