Article View: comp.sys.amiga.tech
Article #12767Re: MEMF_PHYSICAL?
From: Blair MacIntyre
Date: Fri, 19 May 1989 15:31
Date: Fri, 19 May 1989 15:31
46 lines
2555 bytes
2555 bytes
In article <DEVEN.89May19053755@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes:
>In article <6914@cbmvax.UUCP> thomas@cbmvax.UUCP (Dave Thomas QA) writes:
>
> MEMF_PUBLIC involves memory protection if/when it is ever
> implemented. Memory which is MEMF_PUBLIC is accessible to multiple
> tasks. Non MEMF_PUBLIC memory is accessible only to your own task.
> Of course, currently, MEMF_PUBLIC is not meaningful; all memory is
> MEMF_PUBLIC. This has nothing to do with virtual memory.
> MEMF_PHYSICAL would specify memory which must not be swapped out, but
> this says nothing about accessibility to other tasks.
>
>... This argues that
>MEMF_PUBLIC memory, beyond being publicly accessible, must also be
>locked in memory, in the event that an interrupt might access it. If
>you're saying that there would be an MEMF_PUBLIC flag and an
>MEMF_PHYSICAL flag, totally unrelated, then how do you define the case
>of interrupt code in or accessing virtual memory?
Well, much like the rest of the MEMF flags, what is the matter
with
MEMF_PUBLIC | MEMF_PHYSICAL
Why do you want to mix the semantics? Keep it simple, etc etc bla bla bal
I support the notion put forward by Valentin ... if you are going to add
virtual memory to the Amiga, why not do it right the first time? Have
it break current stuff ... doesn't bother me!
Of course, that's just my preference. I realize from the marketing point
of view that's BAD.
*sigh*
I want a memory protected, virtual memory Amiga. It would be sooooo nice.
Blair,
waiting patiently for that sort of machine!
( it's not like I'll have money till the end of the summer
anyway!! ) :-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-///-=
= Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca} \\\/// =
= now appearing at the Computer Graphics Lab, U of Waterloo! \XX/ =
= "Don't be mean ... remember, no matter where you go, there you are." BBanzai=
Technical Details
Message-ID:
<9807@watcgl.waterloo.edu>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!bloom-beacon!gatech!unmvax!deimos.cis.ksu.edu!uxc!iuvax!watmath!watcgl!bmacintyreReferences:
<DEVEN.89May18024329@daniel.rpi.edu> <6914@cbmvax.UUCP> <DEVEN.89May19053755@daniel.rpi.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!bloom-beacon!gatech!unmvax!deimos.cis.ksu.edu!uxc!iuvax!watmath!watcgl!bmacintyre From: bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) Newsgroups: comp.sys.amiga.tech Subject: Re: MEMF_PHYSICAL? Message-ID: <9807@watcgl.waterloo.edu> Date: 19 May 89 15:31:52 GMT References: <DEVEN.89May18024329@daniel.rpi.edu> <6914@cbmvax.UUCP> <DEVEN.89May19053755@daniel.rpi.edu> Reply-To: bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) Organization: UofW Computer Graphics Lab Lines: 46