Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU - Hewlett Packard

This is a discussion on Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU - Hewlett Packard ; Hello, for my hardkey-interfering lib I need some fast memory access, so I kindly ask someone who knows ML better than I do to assure that the way Im planing to use/abuse memory is safe in terms of Garbage Collection, ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU

  1. Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU

    Hello,

    for my hardkey-interfering lib I need some fast memory access, so I
    kindly ask someone who knows ML better than I do to assure that the
    way Im planing to use/abuse memory is safe in terms of Garbage
    Collection, especially if run from a covered port.

    Previous I stored PTRs that lead to RAM in SAUV_REGISTR. Since
    SAUV_REGISTR is only used while debuging ML applications on the calc I
    assume that storing in this area is save. Of course my program should
    not run during debuging.

    Of course everybody could use SAUV_REGISTR, but if one does it should
    be stated explicit and impossible to read over in the docs so that the
    user is aware that problems will arise if he installes two or more
    programs that might use the same memory area. I havent read any
    program documentation so far which claims to use SAUV_REGISTR.

    Now for not interfering with the RAM reserved by the RPL operating
    system one can (if I understood this correctly) move the whole area of
    TEMPOB and the RSTK up and open up a hole between the end of the
    Graphics Grob GDISP and the lower end of TEMPOB, aka TEMPBOT.

    This code sniplet might illustrate what Im planning to do:

    D0=(5) TEMPOB => Pointer for TEMPBOT
    A=DAT0 A
    LC(5) #3
    * Move Return Stack Up
    GOSBVL =MOVERSU
    *D0= ? D1= new value in RAM where TEMPBOT start, SystemPointers
    are updated

    * now write some informationen in the reserved RAM area (example data
    only)
    D1=D1- 3
    LC(3) #717
    DAT1=C X

    Can I always count on the fact, that my reserved memory lies between
    GDISP and TEMPBOT or is there a chance that my information stored
    there will be overwritten by the system ?

    Cleary this also only true, if no other application uses the same RAM
    area and the above said about the documentation is also true. But I
    guess there arent many applications using this technique so far.

    GC has no effect on it, since it is outside of TEMPOB and resizing of
    GDISP left my information intact. Do I miss something ?

    Does this work from any port ?

    To recover the memory I must either use MOVERSD or warmstart.

    Thanks for any suggestions
    Andreas
    http://www.software49g.gmxhome.de


  2. Re: Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU

    On Mar 17, 12:45 pm, "Andreas Mller"
    wrote:
    > Hello,
    >
    > for my hardkey-interfering lib I need some fast memory access, so I
    > kindly ask someone who knows ML better than I do to assure that the
    > way Im planing to use/abuse memory is safe in terms of Garbage
    > Collection, especially if run from a covered port.
    >
    > Previous I stored PTRs that lead to RAM in SAUV_REGISTR. Since
    > SAUV_REGISTR is only used while debuging ML applications on the calc I
    > assume that storing in this area is save. Of course my program should
    > not run during debuging.
    >
    > Of course everybody could use SAUV_REGISTR, but if one does it should
    > be stated explicit and impossible to read over in the docs so that the
    > user is aware that problems will arise if he installes two or more
    > programs that might use the same memory area. I havent read any
    > program documentation so far which claims to use SAUV_REGISTR.


    I would say using SAUV_REGIST is not a good idea.


    >
    > Now for not interfering with the RAM reserved by the RPL operating
    > system one can (if I understood this correctly) move the whole area of
    > TEMPOB and the RSTK up and open up a hole between the end of the
    > Graphics Grob GDISP and the lower end of TEMPOB, aka TEMPBOT.


    This is a much better idea.


    >
    > This code sniplet might illustrate what Im planning to do:
    >
    > D0=(5) TEMPOB => Pointer for TEMPBOT
    > A=DAT0 A
    > LC(5) #3
    > * Move Return Stack Up
    > GOSBVL =MOVERSU
    > *D0= ? D1= new value in RAM where TEMPBOT start, SystemPointers
    > are updated
    >
    > * now write some informationen in the reserved RAM area (example data
    > only)
    > D1=D1- 3
    > LC(3) #717
    > DAT1=C X
    >
    > Can I always count on the fact, that my reserved memory lies between
    > GDISP and TEMPBOT or is there a chance that my information stored
    > there will be overwritten by the system ?


    There's a well documented function called GETBOTTEMP that allocates an
    object at the bottom of TEMPOB. Then all you need to do is to "cut"
    the TEMPOB chain and change the value of the TEMPOB system variable
    and the memory block will be 'hidden'.



    >
    > Cleary this also only true, if no other application uses the same RAM
    > area and the above said about the documentation is also true. But I
    > guess there arent many applications using this technique so far.
    >
    > GC has no effect on it, since it is outside of TEMPOB and resizing of
    > GDISP left my information intact. Do I miss something ?


    I think it may work, but you should come up with a system, document it
    and use it consistently to allow other applications use your technique
    (provided it works well, of course).
    For example, the 6 nibbles at TEMPOB are 000000 to indicate the end of
    the tempob chain. You could establish that any block allocated with
    your technique should have immediately below TEMPOB:
    (higher addresses here)
    TEMPOB --> (6) 000000
    (5) Any arbitrary constant to indicate this is a valid hidden tempob
    block. Used to check whether the following fields exist or not.
    (6) offset to the next (next=below in TEMPOB chains) object in the
    'hidden' tempob area
    (5) Application ID of the block: Your application will check this ID
    before using the block, to make sue the block wasn't moved/overwritten
    by anybody. Also, if your application can't find the block, you can
    scan all 'hidden' blocks for your application ID.
    (nnn) your memory block
    (6) 000000 (the original end-of-TEMPOB marker, or the next hidden
    object)
    (lower addresses here)

    So, you should allocate a standard memory block with GETBOTTEMP, with
    size = (nnn)+16. Then store the proper offset and application ID at
    the end of the block, Truncate the TEMPOB chain poking a (6) 000000
    after the block, and change the value of TEMPOB itself.

    An application scanning through this hidden chain should always check
    that the fist block is valid, because the chain won't exist until an
    application allocates the first block this way. That's what the
    constant is for.

    >
    > Does this work from any port ?


    I don't see how port memory could have any effect on this method.

    >
    > To recover the memory I must either use MOVERSD or warmstart.


    If you create a chain like above, you could free() the last block in
    the chain. You can't free any blocks in the middle without moving the
    ones above, so that shouldn't be allowed. But since your application
    will most likely be the only one there...

    Claudio


  3. Re: Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU

    Hello Claudio,

    thanks for your answer.

    > There's a well documented function called GETBOTTEMP that allocates an
    > object at the bottom of TEMPOB. Then all you need to do is to "cut"
    > the TEMPOB chain and change the value of the TEMPOB system variable
    > and the memory block will be 'hidden'.

    I used GETBOTTEMP, but it probably didnt work because just laying
    around there as a not valid object in TEMPOB (no GC-Flag, no six
    nibble size at the end) at the bottom leads to a crash with the next
    GC. To camouflage at the bottom might be a way to make it work.

    Now Im using =MOVERSU and squeezing my memory between GDISP and
    TEMPBOT:
    lower memory -> higher memory
    Graphics Grob GDISP my raw data TEMPOB aka TEMPBOT

    This has the advantage that all system pointers are updated, no need
    to do it by myself and probably forget one. Speed is not so much
    important while initializing my personal temporary area.

    > I think it may work, but you should come up with a system, document it
    > and use it consistently to allow other applications use your technique
    > (provided it works well, of course).
    > For example, the 6 nibbles at TEMPOB are 000000 to indicate the end of
    > the tempob chain. You could establish that any block allocated with
    > your technique should have immediately below TEMPOB:
    > (higher addresses here)
    > TEMPOB --> (6) 000000
    > (5) Any arbitrary constant to indicate this is a valid hidden tempob
    > block. Used to check whether the following fields exist or not.
    > (6) offset to the next (next=below in TEMPOB chains) object in the
    > 'hidden' tempob area
    > (5) Application ID of the block: Your application will check this ID
    > before using the block, to make sue the block wasn't moved/overwritten
    > by anybody. Also, if your application can't find the block, you can
    > scan all 'hidden' blocks for your application ID.
    > (nnn) your memory block
    > (6) 000000 (the original end-of-TEMPOB marker, or the next hidden
    > object)
    > (lower addresses here)
    >
    > So, you should allocate a standard memory block with GETBOTTEMP, with
    > size = (nnn)+16. Then store the proper offset and application ID at
    > the end of the block, Truncate the TEMPOB chain poking a (6) 000000
    > after the block, and change the value of TEMPOB itself.

    Do I understand correctly, that this way my temporary area is a valid
    TEMPOB slot ?
    But it surly has to move outside of TEMPOB because the lowest TEMPOB
    slot is reserved for the virtual stack. Allocationg the extra nibbels
    for identification of my personal temporary area can be done with
    =MOVERSU including the mentioned advantages above.

    > An application scanning through this hidden chain should always check
    > that the fist block is valid, because the chain won't exist until an
    > application allocates the first block this way. That's what the
    > constant is for.

    These are very well thought suggestions. I keep them in mind. I almost
    have a prototype up and running, allowing interfering all unshifted
    keys. If it works out the way I want it, Ill see how I can consider
    your suggestions.

    > If you create a chain like above, you could free() the last block in
    > the chain. You can't free any blocks in the middle without moving the
    > ones above, so that shouldn't be allowed. But since your application
    > will most likely be the only one there...

    There is no need for this at the moment, the memory I need is fix. The
    needed amount is calculated for =MOVERSU at the beginning.

    Thanks a lot and greetings
    Andreas



  4. Re: Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU

    Just in case so that this might not lead to a musinderstanding:

    > There is no need for this at the moment, the memory I need is fix. The
    > needed amount is calculated for =MOVERSU at the beginning.

    This was only meant for the following part of your paragraph:
    > > If you create a chain like above, you could free() the last block in
    > > the chain. You can't free any blocks in the middle without moving the
    > > ones above, so that shouldn't be allowed.


    Greetings
    Andreas



  5. Re: Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU

    Well, there is something I dont get.

    Im able to allocate my memory and I build a table as a replacment for
    the hash table of the unshifted key lib. This is stored in a ROMPTR
    inside my lib.

    Before the program start, I can find the Adress Pointer to the ROMPTR
    simply with a ROMPTR@.

    Now, if I replace the pointer in the ROMPTAB with the found Adress
    Pointer + 10 for prolog and the size everything works fine, I can
    redefine the keys.

    But, if I copy the content of the ROMPTR (the whole table, including
    prolog and size) to my reserved memory area and replace the pointer in
    the ROMPTAB with the Adress Pointer (+ 10 for prolog and size) to my
    table in reserved memory the calc warmstarts!

    Any suggestions *why* this is happening and/or an explantion of this
    behavior would be most welcome. If stored in a port > 0 it is also
    unclear to me at the moment how I have to handle the delivered Access
    Pointer/Extended Pointer aka ACPTR.

    Lots of TIA,
    Andreas


  6. Re: Question about memory and Garbage Collection, usage ofSAUV_REGISTR and MOVERSU

    Le dim 18 mar 2007 20:00 -0700, Andreas Mller a crit :
    > But, if I copy the content of the ROMPTR (the whole table, including
    > prolog and size) to my reserved memory area and replace the pointer in
    > the ROMPTAB with the Adress Pointer (+ 10 for prolog and size) to my
    > table in reserved memory the calc warmstarts!


    What you could do to find why the calc warmstarts is to use the
    debugger of Emu48. In the debugger window, you can add a "memory
    brakpoint": Emu48 can stop the processor when it reads data at a
    specified memory address. For example, just add a memory breakpoint
    at the area you modified in the ROMPTAB; when the breakpoint is reached,
    step the instructions to see what happens.

  7. Re: Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU

    Hello Khanh-Dang,

    > What you could do to find why the calc warmstarts is to use the
    > debugger of Emu48. In the debugger window, you can add a "memory
    > brakpoint": Emu48 can stop the processor when it reads data at a
    > specified memory address. For example, just add a memory breakpoint
    > at the area you modified in the ROMPTAB; when the breakpoint is reached,
    > step the instructions to see what happens.


    Thanks for the the info. I do use the debugger a lot, but the table is
    build realtive
    (using
    ASSEMBLE
    CON(5) =DOHSTR
    REL(5) EnD_hashtable_No_Shift
    my stuff

  8. Re: Question about memory and Garbage Collection, usage of SAUV_REGISTR and MOVERSU

    Hello to those who might be interested in this ;-)

    The prototype is up and running, the technique Im using allows
    interfering any keypress, regardless of the key-settings.

    Basically it works this way: All keys are redirected to another
    ROMPTR. When a key is pressed Ill instantly switch to the original
    key. Since my program is still in the return stack controll will be
    handled back to my program after the key pressed finished

    So this is kind of a fix for the infamous STO-Bug, which I believe is
    caused by PTR 26440 aka as UNDO_TOP?_. PTR 26440 aka as UNDO_TOP?_ is
    run everytime something is stored in a port and cause the misbehavior
    I described.

    I still dont get, why it is not working directly. If Ill jump behind
    prolog and size of my replacement hash table while it is stored in my
    hidden area or in variable the calc crashes. If Ill jump into the
    ROMPTR/ACPTR, also behind prolog and size everything works fine. Maybe
    its because of direct vs indirect excution and Im missing
    something...

    Greetings
    Andreas



  9. Getting around the sto bug by using reserved RAM

    Hello to those interested in catching the keystrokes of the calc.

    Ill have a system up and running, storing (almost all, question of
    time and effort) all necessary information in a hidden ram area so
    that the o.s. is unaware of it.

    It is not protected at the moment, meaning that any other application
    using the same technique may overwrite data stored in this area.

    On the other hand, the only application that uses a simliar technique
    to store information is the MK for the HP48 (as pointed out by JYA)
    so ...

    Im using this to get around the infamous Sto-Bug which appears if one
    translates his 49G(and all models based on this machine) into another
    language.
    I will gladly give away the engine to anybody who translates the
    machine to another language cause Id like to see more nativ speaking
    49G (of course in the desired language).

    Also ACO shoudnt have much problems to create ROMs in other language
    but it is a question of priority and resources I guess.

    By the way, anyone has an idea how to intercept user key assignments?
    They dont take the walk thru the key-handling libs.

    Greetings
    Andreas
    http://www.software49g.gmxhome.de



+ Reply to Thread