ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/04/90)
Date: 05-31-90 (17:27) Number: 406 (Echo) To: ALL Refer#: NONE From: DAVID BREEDING Read: (N/A) Subj: DYNAMIC ALLOCATION Status: PUBLIC MESSAGE Although I consider dynamic allocation to be one of the highest priorities in the new standard, I have yet to read ANYTHING about it. I keep waiting for someone to bring it up, but somehow no one ever does, so I've finally gotten down to writing myself. All of the so called "modern" languages support some form of dynamic allocation within the language itself. This memory can be called from fast ram, cache, or even disk. All of this is transparent to the user. One of the reasons I heard that colleges don't use Forth for teaching is that it leaves out this very thing. I'm not saying that adding DA will make colleges and universities start teaching Forth, but I bet they'll sit up and notice. Now...how to implement it... First, let's keep it simple. Two words, DALLOT and UNALLOT. All this does is return an address of N items and then returns this address to a pool. Most of the work in DA is easily accomplished using ram past HERE, and then feeding the memory back (keeping a linked list of deallocated memory chunks) to HERE after UNALLOT. Any specialized memory management could be handled by the individual system, only the standard words need to be there for the programers. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (06/04/90)
> Although I consider dynamic allocation to be one of the highest > priorities in the new standard, I have yet to read ANYTHING about it. Many other people also considered it a high priority. I almost resigned from the committee when it appeared that this was not going to make it into the standard, but in the end, it made it in. The following words comprise 2 extension (i.e. optional) wordsets: Memory Allocation and Far Memory. Mitch Bradley -- The following words allocate "data memory", addressable using the normal memory access operators such as @, !, and MOVE ALLOCATE ( u -- a-addr ior ) MEMORY ALLOCATION Allocate u address units of contiguous data memory. The dictionary pointer is unaffected by this operation. The initial content of the allocated memory is undefined. If the allocation succeeds, a-addr is the aligned starting address of the allocated memory and ior is 0. If the operation fails, a-addr does not represent a valid address and ior is the implementation-defined non-zero error code. FREE ( a-addr -- ior ) MEMORY ALLOCATION Return the contiguous region of data memory indicated by a-addr to the system for later allocation. a-addr must indicate a region of data memory that was previously obtained by ALLOCATE or RESIZE . ior is 0 (success) or the implementation-defined non-zero error code. AVAILABLE ( -- u ) MEMORY ALLOCATION Return the number of address units contained in the largest contiguous region of data memory that may be allocated by ALLOCATE or RESIZE . RESIZE ( a-addr1 u -- a-addr2 ior ) MEMORY ALLOCATION Change the memory allocation of the contiguous data memory starting at the address a-addr1 allocate by ALLOCATE or RESIZE to u address units. u may be either larger or smaller than the current size of the memory region. If the operation succeeds, a-addr2 is the aligned starting address of u address units of allocated memory and ior is 0. a-addr2 may or may not be the same as a-addr1. If they are not the same, the values contained in the region at a-addr1 are copied to a-addr2, up to the minimum size of either of the two regions. If they are the same, the values contained in the region are preserved to the minimum of u or the original size. If a-addr2 is not the same as a-addr1, the region of memory at a-addr1 is returned to the system according to the operation of FREE . If the operation fails, a-addr2 does not represent a valid address and ior is the implementation-defined non-zero error code. -- The following words operate on "far memory", which is not necessarily accessible using the normal operators @, !, MOVE. "far memory" might, for instance, be in a different segment, or in a relocatable heap, or it might even be virtual memory of some type. FAR-ALLOC ( ud -- memid ior ) FAR MEMORY Allocate ud address units of far memory. The initial content of the allocated memory is undefined. If the allocation succeeds, memid is the cell pair specifying the start of the allocated memory and ior is 0. If the allocation fails, memid is undefined and ior is the implementation-defined non-zero error code. FAR-FREE ( memid -- ior ) FAR MEMORY Return the region of far memory indicated by memid to the system for later allocation. memid must indicate a region of far memory that was previously obtained by FAR-ALLOC. If the operation succeeds, ior is 0. If the operation fails, ior is the implementation-defined non-zero error code. FAR-IN ( memid ud addr u -- ) FAR MEMORY Copy from far memory into local memory. Copy the contents of u consecutive address units at the far memory starting at offset ud from memid to the local memory starting at addr. An exception exists if either the source region or the destination region is inaccessible or u is larger than the amount of memory available at addr. FAR-OUT ( memid ud addr u -- ) FAR MEMORY Copy from local memory into far memory. Copy the contents of u consecutive address units at the local memory starting at addr to the far memory starting at offset ud from memid. An exception exists if either the source region or the destination region is inaccessible or u is larger than the amount of memory available at memid and ud.
ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/11/90)
Category 10, Topic 36 Message 12 Sun Jun 10, 1990 B.RODRIGUEZ2 at 09:26 EDT (Hope this gets ported back...) Huh. I guess C and Pascal aren't "modern" languages. Certainly there is no dynamic memory allocation "within the language itself" in C; it's part of the function library. A distinction with a difference! And, while it's been years since I dusted off my Jensen & Wirth, I seem to recall static allocation in Pascal, too. Local variables are dynamically allocated in both languages, but this topic is called "Local Variables" in X3J14 circles. Not to say that dynamic allocation is unnecessary. Nick Solntseff and I recently implemented such a system for our Forth work, using the same words with different names: ALLOC and RELEASE. Soon to be published in JFAR, we're told. I agree, these seem to be the essential primitives. (Damfino why C has so many forms of 'alloc'. Enlightenment please?) Let me make one further suggestion: in real-time environments it is beneficial to force compaction/garbage collection at a convenient (idle) time, rather than at the usually-critical moment when an allocation runs out of room. (Assuming here that your system needs compaction or garbage collection, and you're desperate enough to use such in a real-time problem.) Perhaps a third word, COLLECT, should be defined. Easy to make it a no-op when it's not needed. BUT... this should NOT be bound up with the notions of "what is the Forth language" (like LISP). This should be a standardized LIBRARY FUNCTION. More power to the X3J14 TC for moving in this direction! - Brad ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (06/14/90)
Date: 06-12-90 (00:41) Number: 409 (Echo)
To: DAVID BREEDING Refer#: 406
From: DARRYL BIECH Read: NO
Subj: DYNAMIC ALLOCATION Status: PUBLIC MESSAGE
Maybe I'm getting a little technical here, but I'm wondering if you were
implying that the application will take care of shrinking its claim on
system memory (say .com files for example) and moving the stack out of
the way etc. prior to deallocations?
-d.b.
NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduForthNet@willett.UUCP (ForthNet articles from GEnie) (06/16/90)
Date: 06-14-90 (17:15) Number: 412 (Echo) To: DARRYL BIECH Refer#: 409 From: DAVID BREEDING Read: NO Subj: DYNAMIC ALLOCATION Status: PUBLIC MESSAGE That could all be handled on a system level and does not need to be addressed at the "standards" level. There are a lot of ways to implement DA but a lot of it depends on the hardware setup of the system. All I am proposing is a STANDARD way of doing DA. All of the perticulars (like caching and extended memory use) could be handled by the programmers of the compiler. The only thing that makes since to me is the inclusion of the two words DALLOT and UNDALLOT. Which returns an address for use, or returns it to the "heap". It is a truly exciting subject...when I was in college we used DA extensivly (this was about 5 years ago). Using DA and recursion you can do some truly great things that deal with HUGE amounts of data. I have always regreted not having DA as a part of the FORTH language. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu