Just use a full word, and the string representation can use a more packed form to avoid waste.
If a full word still cannot encompass the desired set of character, use a tagged word representation (like tagged polymorphic representations in functional languages), where if the lowest order bit is cleared it's unboxed, and if it's set, it's a multiword boxed character. Sandro Jonathan S. Shapiro wrote: > Thanks for the pointer. > > Once again: string representation is not the issue at hand. The > question is only what the size of the "char" data type should be. > > Jonathan > > On Wed, Mar 10, 2010 at 4:02 AM, Constantine Plotnikov > <[email protected]> wrote: > >> On Wed, Mar 10, 2010 at 12:06 AM, Jonathan S. Shapiro <[email protected]> >> wrote: >> >>> Is there an obviously preferable choice? If not, then given that we want to >>> be able to target these platforms, what do you think we should to about all >>> this? >>> >>> >> Some time ago I stumbled across the project where some experiments >> with string representation were apparently done >> (https://trac.ccs.neu.edu/trac/larceny/wiki/StringRepresentations). I >> have not found a detailed information on the site about what the >> recordN format is. It looks like they claim O(1) read/write random >> access while having N+20 bytes memory usage for ASCII strings(?). >> Possibly it would make sense to contact them about it. >> >> Constantine >> _______________________________________________ >> bitc-dev mailing list >> [email protected] >> http://www.coyotos.org/mailman/listinfo/bitc-dev >> >> >> > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
