Re: scm_heap_org considered harmfull

[Greg Harvey <Greg.Harvey@thezone.net>]

Christian Lynbech <chl@tbit.dk> 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[0]) + 
                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