🚀 go-pugleaf

In article <3237@amiga.UUCP> jimm@cloyd.UUCP (Jim Mackraz) writes:
>In article <10262@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>)In article <5632@cbmvax.UUCP> steveb@cbmvax.UUCP (Steve Beats) writes:
>)>In article <10227@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>)>>	I occasionally put RastPorts on my stack; does that count?
>)>Yes that certainly does count.
>)	AARRGGHHH!  What a bloody nuisance.
>
>I think this is going a little far.  I think we have to divide the problems
>up into what will break with what.  Most of the things Carolyn suggested are
>things that will cause you problems real soon now, for sure.  There were things
>that will break with any non-68000 processor, there were things that will
>screw up with the data cache on an 030 or the instruction cache on an 020 or 030,
>there were things that will break with new ROM revisions. 

Ahem.

The discussion so far seems to revolve around a very
simple view of memory protection. (No insult intended)

Why can't we have MEMF_USER, MEMF_SUPERVISOR, MEMF_EXECUTIVE,
and MEMF_KERNAL?

Seems like intuition running in SUPERVISOR or EXECUTIVE mode
could ask the o.s. to page in the user's rastport and away
you go. 

I don't know about the 68851, but even the venerable vax
has this. I've even written a couple of programs to play
with OTHER users stacks on the vax, so if a 68k analog
exists, this sounds like the solution.

(It's obvious that all user programs would be MEMF_USER
 unless specified otherwise, thus protecting seperate
 tasks from each other, right?)


Just slap me around and pack me off to comp.arch if my 
brain-aid batteries have run down again.


David Neal
nuchat!abbadon@killer