Got it. The idea was not to encode more types - just reduce the "complexity" of tagged pointers and impose the word aligned function address restriction but from what I gather. Yes, a separate byte heap would totally be much ore complex. One of the reasons of this desire was to build miniPicoLis with TCC :) which does not seem to generate WORD aligned function addresses. The second reason for this desire was to have a system for "instructive" purpose - where it seems that doubling the space may not be such a bad idea. The wasted space would be clearly visible and perhaps help with the appreciation for the tagged pointer as an optimization.
But yes, I can clearly see that a 9byte cell is not a good idea :) Regards, Kashyap On Wed, Apr 22, 2020 at 7:28 AM Alexander Burger <a...@software-lab.de> wrote: > Hi Kashyap, > > > Quick question - when you mentioned "doubling of space" - perhaps you > were > > talking about systems that can only have WORD aligned pointers - is that > > correct? > > Not only. Also on a byte-addressed machine, imagine if you make a cell of > two > 9-byte words, you get every cell aligned at another offet, with terrible > performance. On most machines you will get a bus error anyway. > > So my second proposal was to use a separate heap of bytes. But this also > gets > extremely uncomfortable and inefficient, as you need to index into two > heaps for > each access. You won't get a simpler system, as you intended. > > And what to do with that byte? Encode more types than fit into the 4 bits > in > Pil? Then you must also interprete those types at runtime during > interpretation. > Seems you open a pandora box ;) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
