eachus@mbunix.mitre.org (Robert Eachus) (04/06/89)
In article <8904041835.AA01760@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes (edited down of course): >1. The current flags available for requesting memory blocks is MEMF_CHIP, > MEMF_FAST, MEMF_CLEAR and MEMF_PUBLIC. Add three new ones: > MEMF_PHYSICAL: This flag should request a block of memory situated in > physical memory. This will be essential once virtual memory > is implemented. Programs which require to keep their real-time > characteristcs will have to be loaded in physical memory and their data > will usually have to be put in physical memory too. Agreed, sort of. > MEMF_VIRTUAL: This flag (default) requests that a block of virtual > memory be allocated. The default MUST ALWAYS BE MEMF_PHYSICAL!! There is no reason to break large numbers of existing programs when virtual memory support is available and used on SOME machines. Explicit MEMF_VIRTUAL only requests should fail on a non-virtual machine, and MEMF_PHYSICAL + MEMF_VIRTUAL should both be explicitly set if the programmer doesn't care. > MEMF_PRIVATE: When non-MEMF_PUBLIC memory is allocated the memory > block should still be available for read-only access > by other tasks; this new flag will indicate that read access > should not be permitted. This flag is not at all useful in a > single-user OS, but if multi-user features are ever to be added, > it will be essential. First of all AmigaDOS 1.3 already is a multi-user OS, or did you think that the AUX: device was so that you could use two keyboards yourself? The old and fast file systems do not yet support owners, etc. But I currently share several Sun disks using NFS, and they believe my Amiga knows who I am... > Also allocate all MEMF_PUBLIC memory in physical memory by default, unless > requested otherwise. For example messages sent over to a device-driver, > (a real-time program) have to be in physical memory. Agreed since it should always be the default. >2. Modify the linker segments definitions in order to allow programmers to > specify that some segments have to be loaded in physical memory, private > memory, etc... In other words, support the new flags mentioned above. Okay. >3. Use semaphores to enforce mutual exclusion. (Lots deleted...) First of the Amiga is a multiprocessor machine, and the kernel routines all know it. You thought that Forbid() ... Permit() was not a (correctly implemented for the actual machine) semaphore? The reason for using systems calls is so that if the hardware underneath changes, the correct things will still be done. Second if a page fault occurs inside a Forbid() ... Permit() sequence, the appropriate action may be a recoverable alert instead of a guru, but ANY such occurance is really bad news. It must be the responsibility of the caller of Forbid() to insure that any data needed is resident (and of course ALL Forbid() ... Permit() sequences must be made from MEMF_PHYSICAL code). What may be needed for programs which play with the hardware to live in a virtual envirionment is another semaphore, say Hold_Pages(...) ... Release_Pages() which can surround a Forbid() ... Permit(), and says that the data pages named in the Hold_Pages call must be made resident and cannot be released until after the corresponding call to Release_Pages. This would allow a program to keep some large data structures in virtual (chip) memory, and make them resident before calling the blitter. Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...