[Ecls-list] Unicode 16-bits

[Matthew Mondor]

On Sun, 20 Feb 2011 21:56:43 +0000
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> 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.

If it's optional I have no objection whatsoever :)

> > 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..

Was that work done on a real 32-bit architecture (i.e. not on an "SX"
ix86)?  Otherwise I can only speculate, but perhaps that low CPU cache
and expensive memory accesses might have been the reason...  It seems
that on recent x86 accessing a subword appears as fast as accessing a
full native-size word, though, I'm not sure of the current state with
other processors.

> 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.

That's unfortunate.  I have no idea if this idea would be easy to
implement for various toolchains, but for the GNU toolchain it's
possible to use binutils objcopy to produce an object file out of an
arbitrary file (which in this case for instance could be a large text
file), and to link that object file normally with the final executable
or library object...

This hackish makefile used this with the GNU toolchains to link
RAWOBJS within the final executable (two images and a public RSA key):
http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/tests/bktr_client/GNUmakefile?rev=1.8;content-type=text%2Fx-cvsweb-markup

Unfortunately, even then the exported symbol name would differ on
mingw, thus:
http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/tests/bktr_client/src/rawobjs.h?rev=1.3;content-type=text%2Fx-cvsweb-markup
-- 
Matt