I meat: "0xE000 for everything, that must be persisted to disk". There, of
course, you can also reserve three slots for float, integer, string ...

Best regards, Guido

Am Mittwoch, 22. April 2020 schrieb George-Phillip Orais <
[email protected]>:
> 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 <[email protected]> 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 <[email protected]>:
>> > 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 <[email protected]>
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:[email protected]?subject=Unsubscribe
>> >

Reply via email to