Conference noted::hackers_v1

    
    I don't understand what you mean by "aligned" - LIB$GET_VM_PAGE
    returns PAGES, ie: aligned on a 512 byte boundary.  Isn't this what
    you want?
    
    The easiest way to make them 0 is to MOVC5 across them (64K-512
    bytes at a time, of course).  An alternative way is the $CRETVA
    DZRO across the.  This is cheaper if the pages are paged out, but
    more expensive if they're not.
    
    /Bevin                        

    For copy or zeroing memory blocks of ANY length, use either

	OTS$MOVE3 (length, source, dest)
or	OTS$MOVE5 (srclen, source, fillchar, destlen, dest)
    
    matt

	    $EXPREG (or SYS$EXPREG, if you will) is the fastest and
	most straightforward way to do it, but it's what you'd call
	"low-level."  This is no problem, of course, if you're using
	a groovy language like C.
			<_Jym_>

    I want to allocate/reserve segments of memory that are 64Kbyte
    long and aligned such that the first address in the segment has
    its last 16 bits be zero. If something has already done EXPREG
    or CRETVA, then I want to skip past it to allocate the first 64Kbyte
    segment that's free starting at a multiple of 64Kbyte.
    			---Walter

    Sounds like an extension of LIB$GET_VM_PAGE should be contemplated.
    Why don't you QAR it...
    
    /Bevin 

Let me guess that perhaps the reason you want 64k with low 16 bits 0
is that you are emulating some other machine.

If so, perhaps you only need ONE instance of the memory block.  To
this end, it ought to be possible, using PSECTS, to instruct the
linker to start your program space with 64K-512 bytes starting at
page 1.  Many VAX/VMS languages allow this via ARRAYS or VECTORS.

Then, you can use $CRETVA to create page 0, and you've got your
aligned 64K.

If I'm wrong, and you actually need multiple instances, then another
solution could be to allocate a HUGE block of memory with plain old
LIB$GET_VM, and then dish out the aligned segments yourself.  (I assume
you know what I mean, but please write if this isn't clear yet).

Savvie ?

/Eric

    Disable ASTs with $SETAST, get JPI$_FREP0VA from $GETJPI,
    calculate the next acceptable range of addresses, probe
    the pages (check whether they already exist), call $CRETVA
    to create the pages, and re-enable the ASTs.

    If any of the pages already exist, bump the range of acceptable
    addresses by 2^16 (your alignment criterion), and check again.


    An alternative approach is to use a based image.  I heartily
    endorse this method, since it gives you job security -- it
    is something you can fix again and again, as images grow, ...

    Aha, something like .8 is what I was afraid of.
    
    I do indeed want to allocate many of the 64Kbyte segments at
    arbitrary times.
    
    How do I probe the pages for existence--do I need to worry
    about pages without user mode read/write access?
    
    Also, does anyone know how to do this on Ultrix?
    
    Thanks			---Walter
    

    
    You must *NOT* probe the pages for existence.   The existence or
    non-existence of a page is NOT A VALID FORM of claiming a page
    of memory on VMS.
    
    The only two legal forms are LIB$GET_VM (_PAGE) and EXPREG.
    
    All others are liable to lead to multiple subsystems believing they
    own the same pages.
    
    /Bevin

    LIB$FREE_VM_PAGE does indeed permit you to free part of a block
    allocated in one call to LIB$GET_VM_PAGE.   It is even documented
    to permit it.
    
    Indeed, my vote for the best is GET_VM_PAGE 255 pages and free
    the ones you don't need.
    
    	KC

    OK, but where does LIB$GET/FREE_VM[_PAGE] keep its own bookkeeping
    information? If it's right nearby, wouldn't this cause a lot of
    waste, since it would "dirty" that 64Kbyte segment?
    
    Also, how can one do this on Ultrix?
    
    			---Walter

    If I remember correctly, the VM routines keep track of space
    allocated via $EXPREG that is not currently allocated to a user.
    To do this, it uses a few longwords of the free block.  When the
    block get allocated, those longwords become the domain of the
    application.   In most cases, there is no per-block overhead for
    allocated blocks.    The exception is if you ask for boundary
    tags.
    
    As for Ultrix, I think the system routine alloc or malloc 
    works like GET_VM; but it has been too long since I did 
    un*x.
    
    	KC

    How about this scheme:  With AST disabled, do $EXPREG one page.
    This will give you the highest VA that has been allocated.  Then
    do $CRETVA on the first address range above that which meets your
    criteria.  This will waste the VA between the first address that
    you got and the 64K block.
    
    Burns
    

    
    The *only* arbitrators of "who owns what storage" are LIB_VM and
    EXPREG.
    
    For example: What happens if a supervisor-mode AST goes off while
    you have USER-MODE ast's disabled?  Unlikely? ^Y and VAX PCA both
    result in supervisor mode asts.
    
    /Bevin

    I s'pose this means that CRETVA and DELTVA have no use and should
    be yanked?

    If the only arbiters of "who owns what storage" are LIB_VM and EXPREG,
    then there should be no problem using CRETVA when supervisor-mode ASTs
    are considered, assuming that the supervisor-mode code also plays by
    the 'rules' (using only LIB_VM or EXPREG).

    re .16 and super asts:  You're right...I forgot the user mode
    restrictions and assumed they would all be off.  I disagree with
    the literalness of your statement that LIB_VM and EXPREG are the
    sole arbiters..., however.
    
    In fact, EXPREG is the sole arbiter if it comes down to that.  It
    just has some restrictions (like CNTREG having to work in LIFO order)
    which LIB_VM works around.  If someone wanted to implement his/her
    own LIB_VM-like scheme, it would be perfectly acceptable as long
    as no memory was interchanged amoung schemes.  Just have the new
    allocator get its basic hunk of memory via EXPREG and then divide
    it as it chooses.
    
    In addition, (empirically, at least...I don't know the code) CRETVA
    does an implicit EXPREG if the VA which has been created is beyond
    the current region.
    
    Burns
    
    
    

    Thats true, at the VERY bottom, $EXPREG is the single source...
    
    RE: Yanking $CRETVA/$DELTVA;
    
    Apart from upward compatibility issues this has a LOT to recommend it!
    
    Give people the rope and
    they WILL hang themselves, as the replies to this note have
    illustrated.  Of course the fundamental operations are still needed
    for the $IMGACT support, and very occassionally you find routines
    doing $CRETVA's and $DELTVA's on storage which they definitely own
    (for example: having obtained it by calling $EXPREG in the first
    place)...
    
    Unusual things do $EXPREG's behind your back.  For example RMS places
    buffer's there, and $GETMSG loads message files there!  Most people
    are not aware of the numerous such subtle pitfalls that await those
    who believe that they know when memory is being allocated.
    
    I know this is the hackers notes file, but some of this gory garbage
    gets put into products that break years after the original mistake
    was made, for "totally unrelated" changes.
    
    /Bevin

    Demand paging would be easier but I guess VMS does not have that
    feature....
    
    Mike

    Of course VMS has demand paging, that is the automatic movement
    of pages from disk to main memory without user-level intervention.
    
    What is being debated here is how to control the allocation of the
    VIRTUAL address space, not the physical (main memory) address space.
    
    /Bevin
    

    By demand paging, I meant if you want a page of memory, all you
    have to do is reference it and you have it. If I want to use a
    particular page of memory, I just touch a location on that page
    and I am given that page (in my virtual address space).
    
    Mike

    RE: .22
    
    	I'm really glad it doesn't.   I watched a friend debug some
    code before memory management was running.   His problem was simply
    that he lost his pointer to some memory.   When memory management
    is running, you get an accvio.   Without it (or with demand paging)
    memory materializes.  Yuck!
    
    	KC
    

    .22's demand paging would be really n.g. for a lot of reasons. 
    The most important function of the memory allocation routines is
    arbitration.  Yes, VMS happens to  also use the routines to map
    virtual addresses, but the central problem is deciding what virtual
    addresses a particular piece of code is to use.  "Demand paging"
    would not solve that problem.
    
    Burns

    I think I disagree with the statement that $CRETVA does an implicit
    $EXPREG if the requested addresses are beyond those already existent.
    In fact, if you ask $CRETVA for a page at 0000F000, and the last
    (highest) page used at the moment is at 0000A000, $CRETVA will create
    the requested page and fill the intervening process PTEs with 'null
    page' pointers.  So you'll have your page, but nothing between it and
    last one you had before.  At least, I *think* that's what happens..
    
    I also have a bicker with the statement that $EXPREG and LIB$VM
    are the `sole' arbiters.  Actually, if you decide to use one, then
    you must use it throughout your application, and ensure that neither
    your code nor any code you call (such as RTL routines) use any other
    method than the one you have selected.  If your program uses $CRETVA,
    $DELTVA, and some magic, then never call LIB$VM or any *other* RTL
    or LSR (Language Support Routines, like FOR$OPEN) routines AT ALL.
    If you can't keep this commitment, don't do it.
    
    RMS buffers, by the way, live in P1 space, as do all message file
    maps, unless you've used LINK /P0IMAGE.  So, if you're working with
    addresses below 40000000, those should not present a problem.
    
    #ken	:-)}
    
    #ken	:-)}

RE: .25

Last time I looked, message file maps lived in P0 space.  The PL/I compiler
used to use $CRETVA to allocate memory and it fell afoul of the allocation
of message sections in P0 space.

--PSW

    Message sections that are part of the image live in P0, and those
    that get mapped because of a message file using the /FILE qualifier,
    but the one I was thinking of is that defined by SET MESSAGE filespec,
    which gets mapped into P1 space.
    
    #ken	:-)}

>    Message sections that are part of the image live in P0, and those
>    that get mapped because of a message file using the /FILE qualifier,
>    but the one I was thinking of is that defined by SET MESSAGE filespec,
>    which gets mapped into P1 space.
    
    Then why is SETP0 the image that does the deed?
    
    /pjh_who_is_just_curious
    
    

re .28:

>    Then why is SETP0 the image that does the deed?

SETP0 is a SET image that lives exclusively in P0 space (including the stack)
so it can play with P1 space without clobbering its own data structures.

-Mike

    Because, in order to map the process-permanent section, P1 space
    may need to expand downwards, which would mung the stack.  SETP0
    is linked /P0IMAGE, which means that the stack and RMS buffers are
    allocated in P0 space, leaving P1 space free to expand.
    
    #ken	:-)}

    Sorry, I just realised the question may be different than I first
    interpreted.  SETP0 means `version of SET that lives exclusively
    in P0 space so it can frobnicate P1 space.'  Better answer?
    
    #ken	:-)}

    
    re: .29, .30, .31
    
    Sounds more reasonable than any other explanation I've heard. Thanx.