Thanks Alex, Yup, I can see what's going on now about RAM vs ROM :) About the the CELL having an additional byte, I meant that the CELL size would be 2*WORD + 1... that should work too right? I would not need any masking in that case.
Regards, Kashyap On Mon, Apr 20, 2020 at 11:06 PM Alexander Burger <a...@software-lab.de> wrote: > Hi Kashyap, > > > 1. About RAM vs ROM. Call me lazy but I would really appreciate a > > description of how the RAM vs ROM decision is taken here (and in general > > too..I mean, it is not clear to me how gen3m.c determines how something > is > > never written to or not) > > if (x > 0) > > Rom[x] = strdup(buf); > > else > > Ram[-x] = strdup(buf); > > The sign of 'x' is determined when reading the symbol, in the functions > romSym() > and ramSym(). > > You can see where something gets stored to by whether RomIx or RamIx is > used. > Cell data all go to ROM, most symbol value cells to RAM (except some > constants > like NIL or T). This allows also symbols in ROM to be redefined at runtime. > > > > 2. Can I try and make the CELL have an additional byte to store the TYPE > > and get rid using tagged pointers? Clearly, it would be less efficient at > > runtime but perhaps it would be more easy to understand. Is there any > > reason that this would not work? > > No, this would work. You could use the most significant byte, but have to > mask > it when using the pointer (and live with the decreased address space size > ;) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
