Hi Guido, I think you mean 0xF000 for everything? This is indeed cool! but hmm does it limit the memory for each data type? Like what if the application uses only integers so does it mean it cannot use the memory location for float and strings?
BR, Geo On Wed, Apr 22, 2020 at 8:44 PM Guido Stepken <gstep...@gmail.com> wrote: > Hi Kashyap! > > Reserving 1-3 bit from 32 or 64 bit register for special purposes, e.g. > indicating type or as persistence flag (ORM-wrapper) is the old fashioned > way. It unnecessarily costs cycles, reduces precision ... > > The modern, "fully functional" (no state bits anywhere!) - and correct - > way would be to indicate type by its position in memory: > > 0xC000 all floats, 0xD000 all integers, 0xE000 all strings, 0xD000 > everything, that have to be persisted do disk. Let another CPU do the > persistence! ;-) > > Have fun! > > Best, Guido Stepken > > Am Mittwoch, 22. April 2020 schrieb C K Kashyap <ckkash...@gmail.com>: > > Thanks Alex, > > I was thinking of increased memory space - not exactly doubling - I was > thinking it would just be one additional byte per CELL. Ofcourse this > additional byte would not have the same lifetime of the CELL so it should > not need any extra management. > > I feel encouraged - I'll give it a try :) > > Regards, > > Kashyap > > On Tue, Apr 21, 2020 at 10:11 PM Alexander Burger <a...@software-lab.de> > wrote: > >> > >> Hi Kashyap, > >> > >> > 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. > >> > >> I see. Yes, that would work. But it would either double the memory > usage, or > >> require some management of this additional byte (e.g. in a separate, > parallel > >> byte heap), which complicates things a lot more than it benefits. > >> > >> ☺/ A!ex > >> > >> > >> -- > >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
