Path: utzoo!attcan!uunet!zephyr.ens.tek.com!uw-beaver!mit-eddie!bloom-beacon!eru!hagbard!sunic!cs.umu.se!dvlmfs
From: dvlmfs@cs.umu.se (Michael Forselius)
Newsgroups: comp.sys.mac.programmer
Subject: Re: More Mac Wierdness (Memory Mangler)
Keywords: VBL, memory
Message-ID: <1990Oct26.095921.24118@cs.umu.se>
Date: 26 Oct 90 09:59:21 GMT
References: <1990Oct25.025224.23414@cpsc.ucalgary.ca>
Sender: news@cs.umu.se (News Administrator)
Organization: Dep. of Info.Proc, Umea Univ., Sweden
Lines: 102

In article <1990Oct25.025224.23414@cpsc.ucalgary.ca> wieser@cs-sun-fsd.cpsc.ucalgary.ca (Bernhard Wieser) writes:
>
>Greetings;
>
>I am in the process of writing a 'background' task.  Really, I am writing
>a VBL task.  I wondering what problems could occur if I do what IM
>says not to, and use routines which use the memory manager.

	[... stuff deleted]

    This question makes me  think of a 'trick'  that I've thought
    of but  never had the time or need to  implement!  If this is
    OK  then you could move memory as you wish at interrupt (VBL)
    time. To explain this technique I'll use some pseudo language
    to clarify what I am thinking about. I suppose  that the main
    use of this, IF it works of course, would be in an INIT/cdev.

    First of all we need to allocate a block of memory that`s 
    resident. We could do this by:
        1.  Expanding the system heap (TMON).
        2.  Allocate a block in the system heap,
            as almost all INIT's/cdev`s do.
        3.  Subtract the amount of memory required from BufPtr,
            i.e.  moving BufPtr downwards (also TMON).

    Then we would use InitApplZone(ourMemoryBlock,...,...,...) to
    initialize this block as an application heap zone.

    When we are  called  during some  autovectored interrupt then
    we would  save the  current application zone, set the current
    zone to the one that we've made. Then we should (theoretical)
    be able to call almost any  trap even if they could cause the
    zone to be purged/moved/compacted.  This due to the fact that
    NewPtr,NewHandle,... MUST work  WITHIN the current zone (this
    is a  truth with modification since you  could call NewPtrSys
    but this is no problem  since YOU are  supposed to  know what
    you are doing).

    Then  when we are  finished  with whatever we  were  doing we
    simply restores the zone and execution can continue.


    Some code to describe this could be:

        At INIT time:
            
            ...

            BufPtr = BufPtr - reqAmount
            ourMemoryBlock = BufPtr

            ...

            zone = InitApplZone(ourMemoryBlock,masters,...)
            ...

        At interrupt time:

            ...

            saveZone = TheZone ;this is the current heap zone
            TheZone = ourZone

            ...

            TheZone = saveZone

            ....

    This should  work,  shouldn't it?  If not - please let me know
    and explain the reason why you think this approach might fail.
    Oh,  remember  that you'll have  to  finish  your code  before 
    the next interrupt occurs otherwise the'll have the wrong zone
    to play with!... but seriously  do you really want your VBL to
    take >1 Ticks!

Thanx for reading this far - Have a Nice Day!



>
>Please e-mail me, wieser@cpsc.ucalgary.ca or BSWieser@uncamult.bitnet,
>with any help/hints.  Even just to say hi (so I know news is working).

    Hi Bernie!
>
>Bernie
>(No signature, no pain)

+---------------------------------------------------------+
| Michael Forselius    Internet: dvlmfs@cs.umu.se         | 
|---------------------------------------------------------|
| Ever heard of 'Pirate Purgatory' !?! - tough one though |
+---------------------------------------------------------+

    No pain, no gain...

-- 
+---------------------------------------------------------+
| Michael Forselius    Internet: dvlmfs@cs.umu.se         |	
|---------------------------------------------------------|
| Ever heard of 'Pirate Purgatory' !?! - tough one though |