dougp@sbphy.ucsb.edu (03/13/89)
I posted a wish for a realloc in comp.sys.amiga, but got no indication of whether it was actually going to be implemented in 1.4. This looks like an interesting routine to write so if I get no responce I may try to write a realoc routine myself. I would prefer it to be included in 1.4 however. Will there be a realoc function in 1.4???
jms@antares.UUCP (Joe Smith) (04/01/89)
In article <DEVEN.89Mar31025148@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >... Now, if C-A will add a ReallocMem to Exec V1.4+, it won't be a problem. I don't understand how ReallocMem could ever work under AmigaDOS unless the caller always does a Forbid before the FreeMem and a Permit after the ReallocMem. As soon as you free memory on the Amiga, some other task may get a chance to run and get the block you just freed. (Memory blocks are either in use, or completely free - available to anyone. There are no other possiblilities.) With Unix, each process gets its own private virtual address space so that the other guy's alloc won't interfere with your alloc. And sbrk provides contiguous blocks of virtual memory, something which cannot be done with AmigaDOS. You keep saying that it is trivial to add ReallocMem to the OS. Given the fact that all tasks on the Amiga share the same virtual=physical address space (currently), I believe it is very difficult. I would venture to say that it is impossible in version 1.x - you will have to wait for 2.0 or 3.0. -- Joe Smith (408)922-6220 | jms@antares.Tymnet.COM or jms@opus.Tymnet.COM McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!antares!jms PO Box 49019, MS-D21 | PDP-10:JMS@F74.Tymnet.COM CA license plate:"POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
brant@uf.msc.umn.edu (Gary Brant) (04/02/89)
In article <432@antares.UUCP> jms@antares.UUCP (Joe Smith) writes: >In article <DEVEN.89Mar31025148@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >>... Now, if C-A will add a ReallocMem to Exec V1.4+, it won't be a problem. > >I don't understand how ReallocMem could ever work under AmigaDOS unless the >caller always does a Forbid before the FreeMem and a Permit after the >ReallocMem. As soon as you free memory on the Amiga, some other task may get You're missing the point; if you FreeMem first, you don't even need ReAllocMem. ReAllocMem should take a pointer to a block and a new size and return a block of the requested size. If a new block is needed, ReAllocMem copies the contents of the old block to the new one before releasing the old block to the free storage pool. I don't see why any Forbid/Permit's would be needed here. [ rest of atticle deleted ] >-- >Joe Smith (408)922-6220 | jms@antares.Tymnet.COM or jms@opus.Tymnet.COM >McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!antares!jms >PO Box 49019, MS-D21 | PDP-10:JMS@F74.Tymnet.COM CA license plate:"POPJ P," >San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!" -Gary Brant ARPA: brant@uf.msc.umn.edu My employer has no knowledge of my ravings.
dougp@sbphy.ucsb.edu (04/02/89)
In article <11848@umn-cs.CS.UMN.EDU>, brant@uf.msc.umn.edu (Gary Brant) writes... >of the requested size. If a new block is needed, ReAllocMem copies the >contents of the old block to the new one before releasing the old block to >the free storage pool. I don't see why any Forbid/Permit's would be needed You might also include the ability to change the type of memory by specifing a new set of memory type flags. Of course this would REQUIRE copying the memory if you changed from FAST to CHIP, but it might require only messing with some registers in the MMU of future amigas if you changed from PUBLIC to private ram. Douglas Peale
deven@pawl.rpi.edu (Deven Corzine) (04/03/89)
In article <432@antares.UUCP> jms@antares.UUCP (Joe Smith) writes: >In article <DEVEN.89Mar31025148@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >>... Now, if C-A will add a ReallocMem to Exec V1.4+, it won't be a problem. >I don't understand how ReallocMem could ever work under AmigaDOS >unless the caller always does a Forbid before the FreeMem and a Permit >after the ReallocMem. As soon as you free memory on the Amiga, some >other task may get a chance to run and get the block you just freed. >(Memory blocks are either in use, or completely free - available to >anyone. There are no other possiblilities.) With Unix, each process >gets its own private virtual address space so that the other guy's >alloc won't interfere with your alloc. And sbrk provides contiguous >blocks of virtual memory, something which cannot be done with AmigaDOS. Forget AmigaDOS. This is Exec-level, and has nothing whatsoever to do with BCPL, the file system, or any other part of AmigaDOS itself. You are indeed missing the point. First, the purpose of having a ReallocMem() function is NOT to reallocate a previously freed block of memory; that is a peculiarity of some versions of Unix, which while handy, is irrelevant here. The purpose of having a ReallocMem() function is (would be) to modify the passed memory block -- either the size or type of the block. It is understood that after the ReallocMem, the old pointer is no longer valid, and the new pointer returned must be used - if the block can't be expanded or shrunken or otherwise modified where it is, it will be moved, unless the change can not be accomodated at all, in which case the old block remains allocated and intact, and the function call returns an error. You are correct in saying that sbrk() will extend a contiguous data segment, but the fact is that even though in Unix malloc() and realloc() will make calls to sbrk() which calls brk() to get more memory... You don't need to do that, because of the way memory management is done on the Amiga. You can have a malloc() routine which calls AllocMem() instead and have free() call FreeMem(), etc. I intend to to exactly that for "Amigix" and I expect to dummy- implement sbrk() and brk(), probably. After all, in Unix, sbrk() and brk() are almost NEVER called directly... only indirectly from malloc(), calloc(), etc. Those routines will call AllocMem instead, eliminating the need or value in writing sbrk() and brk(). >You keep saying that it is trivial to add ReallocMem to the OS. Given the >fact that all tasks on the Amiga share the same virtual=physical address >space (currently), I believe it is very difficult. I would venture to say >that it is impossible in version 1.x - you will have to wait for 2.0 or 3.0. And I stand by that statement. It remains a trivial task to write a proper ReallocMem for Exec. It would be about twice as complex as AllocMem, which I can't see being very complex, considering the simplicity of its task. Adding a ReallocMem to Exec has NOTHING to do with having virtual/mapped memory or not. True, a ReallocMem would need to start with a Forbid() and end with a Permit(), but so must AllocMem and FreeMem. It is only for the duration of the function call, which will be short. In article <11848@umn-cs.CS.UMN.EDU> brant@uf.msc.umn.edu (Gary Brant) writes: >In article <432@antares.UUCP> jms@antares.UUCP (Joe Smith) writes: [...] >You're missing the point; if you FreeMem first, you don't even need >ReAllocMem. ReAllocMem should take a pointer to a block and a new size >and return a block of the requested size. If a new block is needed, >ReAllocMem copies the contents of the old block to the new one before >releasing the old block to the free storage pool. I don't see why any >Forbid/Permit's would be needed here. In some versions of Unix, you can indeed free a block, and call realloc() with a pointer to the freed block, and the block will be reallocated intact. This only works if there were no malloc(), realloc() or free() calls between the free(ptr) and realloc(ptr). This is a rather strange (but useful) semantic of realloc, but not the primary reason for realloc. To implement ReallocMem properly, the function would have to Forbid(), check whether or not the reallocation request can succeed AFTER the old block is freed, (without actually freeing the block) return with an error (after a Permit()) if it can't, otherwise free the old block, allocate the new one and copy the block if it starts elsewhere, Permit() and finally return the pointer to the new block. It should always keep the block at the same address if at all possible, to avoid unnecessary copying. Clearly, such a routine would depend on the granularity of memory allocation, and as such, dependant on a particular version of Exec. Therefore, such a function ought to be included in exec.library for V1.4 and beyond, so that it will be consistent. IMHO. Alternatively, you could write a function which does a Forbid(), AllocMem() for the new block, return with an error (after a Permit()) if the AllocMem() fails, otherwise copy the old block to the new, FreeMem() the old block, Permit() and return a pointer to the new block. The fault in using this method is that there must be enough free memory to hold BOTH blocks of memory at once, so it can easily fail if you are simply SHRINKING a memory block, if there is not enough free memory. Hence, it is far preferable to do the job right... which means adding ReallocMem to exec.library... In article <1394@hub.ucsb.edu> dougp@sbphy.ucsb.edu writes: >In article <11848@umn-cs.CS.UMN.EDU> brant@uf.msc.umn.edu (Gary Brant) writes: [...] >You might also include the ability to change the type of memory by >specifing a new set of memory type flags. Of course this would >REQUIRE copying the memory if you changed from FAST to CHIP, but it >might require only messing with some registers in the MMU of future >amigas if you changed from PUBLIC to private ram. Absolutely. The function arguments that make most sense for ReallocMem are: APTR ReallocMem(oldblock, oldsize, newsize, attributes, attributemask) APTR oldblock; /* pointer to old block */ ULONG oldsize; /* size of old block */ ULONG newsize; /* size of new block */ ULONG attributes; /* attributes of new block */ ULONG attributemask; /* mask of attribute bits to be changed */ The ReallocMem function should also ideally handle NULL special cases gracefully; that is: ReallocMem(0,0,BUFSIZE,MEMF_CLEAR,-1); should act as a: AllocMem(BUFSIZE,MEMF_CLEAR); and: ReallocMem(oldblock,oldblocksize,0,0,0); should act as a: FreeMem(oldblock,oldblocksize); [See comp.std.c if you want justification for this.] *sigh* Yet another long article... Well, at least it's only 1 reply to 3 articles... Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
usenet@cps3xx.UUCP (Usenet file owner) (04/04/89)
In article <DEVEN.89Apr2223029@daniel.pawl.rpi.edu> shadow@pawl.rpi.edu (Deven T. Corzine) writes: >In article <432@antares.UUCP> jms@antares.UUCP (Joe Smith) writes: >And I stand by that statement. It remains a trivial task to write a >proper ReallocMem for Exec. It would be about twice as complex as >AllocMem, which I can't see being very complex, considering the >simplicity of its task. Adding a ReallocMem to Exec has NOTHING to do >with having virtual/mapped memory or not. I think that this need not be complicated at all. As a matter of fact, you can do it completely legally now, without adding any functions to Exec.library. new * realloc(old *,newsize,oldsize) { Forbid(); FreeMem(old,oldsize); error=AllocAbs(newsize,old); if(error==0) { AllocAbs(oldsize,old); /* should not fail, I think :-) */ error=AllocMem(newsize,attributes); if(error==0) { Permit(); return(0); } Permit(); CopyMemQuick(bla bla); FreeMem(old,oldsize); return(error); } Permit(); return(old); } I have *NOT* tested this, and have only just now thought of it. It should should work though. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In Real Life: Joe Porkka porkka@frith.egr.msu jap@syssun.cl.msu.edu (35.8.1.1)
deven@pawl.rpi.edu (Deven Corzine) (04/05/89)
In article <2347@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes:
[realloc() function]
Hmm... forgot about AllocAbs... that just might work, after all...
Deven
--
------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine ---------------------
Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America
ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847
sum... In the immortal words of Socrates: "I drank what?" ...I think.