Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Stashing A5 (was Re: Help With VBL Tasks)
Message-ID: <6377@hoptoad.uucp>
Date: 23 Jan 89 20:59:54 GMT
References: <8343@orstcs.CS.ORST.EDU> <27628@ucbvax.BERKELEY.EDU> <451@internal.Apple.COM> <6347@hoptoad.uucp> <27674@ucbvax.BERKELEY.EDU>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 43

In article <27674@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP
(David Phillip Oster) writes:
>Be careful here. What is forbidden is modifying your code resources. There
>is no problem creating a block of exectuable code at run time, that was
>created with a nice constant built -in:

That's not neccessarily true.  A memory manager typically has three kinds
of access checks, read, write, and execute.  In the hypothetical protected
mode OS, it's quite possible that the heap will be turned off for execute
mode access.  This protects against the old "jumping into data space" bug,
just as protecting against writing on executable code prevents against
the obverse "writing into code space" problem.  Still, you're probably
right, since Apple hasn't explicitly warned against putting code into
the heap.

>You might think the above might lead you into trouble on a 68020 because
>of the instruction cache. But, the instruction cache should never be
>holding any address that NewPtr() is going to return, so the 68020 should
>never get confused.  After all, the system reads code in from disk, and if
>that isn't modifying memory that is about to be executed, I don't know
>what is!

True.  I think the reason for this is that instructions aren't cached
until after they have been executed once.  Since this code never
changes except before it's executed the first time, there shouldn't be
a problem.  I believe this is the same reason the OS reads code from
disk without difficulty.

>You might think you  could optimise the dispatcher's JSR, RTS to a JMP
>instruction. Don't try it: you'll screw up the compiler's popping of
>the arguments in socketListener.

Well, except that you can't write a socket listener in anything but
assembler because everything is stored in registers.  I experimented
with a save/restore registers approach and writing a listener in C, but
pushing and popping the registers was too slow given the time
constraints of a listener.  If Apple had put all the information into a
data structure intead of into registers, there wouldn't be a problem.
But since ReadPacket requires the registers to be set up correctly....
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"The time is gone, the song is over.
 Thought I'd something more to say." - Roger Waters, Time