RE: List API's, Memory Management, and Pointer Math

["Richard Jackson" <richardjackson@xxxxxxxxxxxxxxxxxx>]

This is both easier and harder than you think that it is. 

 

1. virtual memory on AS/400 is virtual.  Virtual storage is allocated in contiguous addresses.  In virtual space, byte 4095 is adjacent to byte 4096.  Every time.  The machine protects you from the unpleasant physical implementation.

 

2. There is a mapping between virtual and physical memory that is maintained by the hardware and the storage management code.  When physical pages are loaded into main storage, their virtual and physical addresses are stored into a physical area called the primary directory.  This space is organized as a hash table.  Each row in the table contains virtual address, physical address, a referenced bit, a dirty bit, the pointer tags, and perhaps some authority information.  [There is also a high-speed cache called the "translation lookaside buffer" or TLB.  This device has no effect on function, only on performance, so I will ignore it.]  If your program refers to an address, the hardware looks in the primary directory to see if that virtual address is currently present in memory.  It looks not for the entire byte address, just the 4k page.  I will call this the "virtual page".  If the virtual page address is present in physical memory, the byte offset into the 4k page is appended to the physical address and the combined value is used for the operation.  If the virtual address is not present in the table, a page fault is signaled and the current program is suspended while VLIC storage management code is invoked to bring the virtual page into main storage.  When the page fault operation has completed, the hardware instruction that previously failed with the page fault is executed again.  In the process of moving the page into memory, an entry is made in the primary directory indicating that virtual page such-and-such is currently located in physical-memory-frame thus-and-so; its reference and dirty bits are off and pointer tags are set. 

 

3. Pointers always contains virtual addresses.  Since the translation to physical addresses occurs in the hardware using a translation table maintained by the hardware, the physical non-contiguity of the addresses is not material.  When your program adds 1 to the pointer, you are incrementing the virtual address stored in there.  The physical address cannot be known without examining the hardware tables that perform address translation. 

 

This is a combination of conventional virtual memory management and AS/400 single-level storage concepts.  I hope that this is helpful. 

Richard Jackson
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On Behalf Of David Keck
Sent: Friday, July 07, 2000 2:06 AM
To: RPG400-L@midrange.com
Subject: List API's, Memory Management, and Pointer Math

List API's can dynamically extend the size of their associated user spaces.  I think it unlikely that that such extensions would always yield a user space consisting of a contiguous block of bytes in memory.  I think it more likely that extensions would reside in non-contiguous blocks of memory allocated as extensions become necessary.  If my assumption is correct (though I'm starting to guess that it's not), how then does pointer math work on the list structures contained in user spaces which are populated by the list API's ? 

For Example ...

1. Create a *USRSPC 100 bytes in length
2. Call a List API which requires a much larger user space for its results.  This should result in an automatic extension of the size of the user space.
3. Call the QUSPTRUS API to get a pointer to the start of the *USRSPC
4. Now for simple pointer math to always work, you should be able to have the driving RPGIV program work its way through the entire *USRSPC one byte at a time incrementing the address (pointer) by 1 until the end of the structure is reached.  But if this always works doesn't that mean that the user space extensions always yield a *USRSPC which resides in a contiguous block of memory?