[Ecls-list] Unicode 16-bits

[Juan Jose Garcia-Ripoll]

On Sun, Feb 20, 2011 at 7:59 AM, Matthew Mondor <mm_lists at pulsar-zone.net>wrote:

> On Sat, 19 Feb 2011 23:43:33 +0000
> Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:
>
> > Would you find it useful to have an ECL that only supports character
> codes 0
> > - 65535? That would make it probably easier to embed the part of the
> Unicode
> > database associated to it (< 65535 bytes) and have a standalone
> executable.
> > Executables would also be a bit faster and use less memory (16-bits vs
> > 32-bits per character)
>
> Would this be an option or would ECL internally use a 16-bit character
> representation all the time when unicode support is enabled for the
> build?
>

It would be optional It would make the C image smaller, now that the Unicode
database is going to be shipped as an object file -- working on it --, and
it would definitely save memory, which may help in some contexts.


> I know that some
> processors (including older x86) have faster access times for 32-bit
>

That was not my experience when working on ECL's interpreter -- it is right
now 16-bit because it was faster than 8-bit bytecodes and than 32-bit ones..

As for the 65535 bytes output file limitation, is that more difficult
> to fix?  Is it a toolchain-dependent issue which ECL has no control
> over?
>

It is a problem with Microsoft's toolchain. I do not know how to force the
compiler to accept longer strings. The only way out is to split the file
data into multiple strings, but it requires some tweaking of the compiler.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110220/57aea2e1/attachment.html>