HP3000-L Archives

January 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jerry Fochtman <[log in to unmask]>
Reply To:
Jerry Fochtman <[log in to unmask]>
Date:
Thu, 14 Jan 1999 07:09:05 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
At 04:12 PM 1/13/99 -0700, Simonsen, Larry wrote:
>In compatibility mode a program could use some of the unused memory
>address between 0 and -20 for a global type data pointer.  As we move
>further into the NM code the need of something like the Fortran logical
>unit table is needed in our application.  The difference is that there
>is a need of knowing this pointer from both the XL library and the
>application.  Is there a type of address which could be used for this
>type of pointer.  there is only a need of one pointer into the heap
>memory space.

If only the routines in the XL need to know about the space, or provide
an interface to the data in this object, you could define a 'STATIC VARIABLE'
in the XL module.  In this manner only the routines in the specific XL
module have access to this storage space and you could then have a simply
'get' and 'put' routines to interact with this space from the program....

You could also pass tha address of a program-defined pointer to an
XL routine which could then take the address of this 'GLOBAL STATIC'
space and stick it in the pointer address from the calling program.
Upon return, the program's pointer will point to the same space
defined by the XL module.  This assumes, of course, that the language
used by the program supports pointers. But if you did this, then why
not simply define the space object in the program and pass it as an
argument to all the necessary XL routines....!

If, on the other hand, the structure needs to be defines in the program
and shared by the XL routines, you could still define a GLOBAL STATIC
pointer in the XL module.  Then, from the program call an XL routine
passing the address of the program-based structure and this routine
simply stores the address into the STATIC pointer.  Now, all routines
in that XL module will have access to this pointer and can access the
program's defined structure without having to pass it as an argument.

And if a large object space is needed, there's always mapped files as
a method of storing a structure and passing the file pointer to the XL
routines or doing similar types of pointer setting using short/long
file pointers.

Unless you're writing a tool which needs its own internal space (like
V/PLUS) without concern of the application program (inadvertantly) accessing
the data, this all this begs the question as to why it would be necessary
to do all of this and make debugging/maintenance more difficult for the
next person?



/jf
                              _\\///_
                             (' o-o ')
___________________________ooOo_( )_OOoo____________________________________

                        Thursday, January 14th

          Today in 1784 - The Continental Congress ratified the treaty
                          with Great Britain that ended the
                          Revolutionary War.

___________________________________Oooo_____________________________________
                            oooO  (    )
                           (    )  )  /
                            \  (   (_/
                             \_)

ATOM RSS1 RSS2