This is the mail archive of the firstname.lastname@example.org mailing list for the guile project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
Christian Lynbech <email@example.com> writes: > Guile contains a global variable called `scm_heap_org' which is > documented as "the lowest base address of any heap segment" and is > initialized from the base address of the first heap segment allocated. > > This assumes that malloc allocates from the low end of memory, such > that for two pointers p1 and p2 obtained from subsequent calls to > malloc, it holds that p1 < p2. > > This may be the convention on a number of popular UNIX implementations > but it does not hold universally, with the pSOS as one exception (pSOS > is an OS used for embedded systems which we are using for a new line > of powerpc based cards). > > As far as I can tell, the only use for scm_heap_org is to convert a 32 > bit pointer into an offset with a smaller range (to free up some tag > bits perhaps). If so. any offset would do, allowing for a more robust > strategy. I am currently using the address of scm_heap_org itself, as > in: > > scm_heap_org = CELL_UP (&scm_heap_org); > > and it seems to work fine. > > If anybody has a more elegant (or robust) solution, please let me know. Will it be the case everywhere that &scm_heap_org < mallocated storage, though? If not, it's just moving to annoyance to someone else ;). A more robust solution is probably to encode these pointers as seg-offset:heap seg, where we find the actual pointer by doing (offset is 14 bits, seg is 10 bits... I've probably screwed something in here, but you get the idea): (cell is the car of the object where the offset is located) int seg = (((long)cell) >> 8 ) & 0x400; int offset = (((long)cell) >> 18); ptr = (SCM) ((long)(scm_heap_table[seg].bounds) + sizeof(scm_cell) * scm_heap_table[seg].ncells * offset); It's kinda gross, though (so, maybe not more elegant :). It also constrains the number of cells in any segment to 16384 on a 32 bit machine (not necessarily a bad idea, but still an additional constraint). Optionally, we could put all the objects that need to be done this way in their own heap (I've been thinking about whether it'd be beneficial to segregate some of the different kinds of objects this way, actually). -- Greg