oops .. hit send too early - Got it. The idea was not to encode more types - just reduce the "complexity" of tagged pointers and remove the word aligned function address restriction. Yes, a separate byte heap would totally be much more 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" purposes - 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 :) On Wed, Apr 22, 2020 at 8:27 AM C K Kashyap <[email protected]> wrote: > 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 <[email protected]> > 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:[email protected]?subject=Unsubscribe >> >
