<div class="gmail_quote">On Sun, Feb 20, 2011 at 7:59 AM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net">mm_lists@pulsar-zone.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I know that some<br>
processors (including older x86) have faster access times for 32-bit<br></blockquote><div><br></div><div>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..</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">As for the 65535 bytes output file limitation, is that more difficult<br>
to fix?  Is it a toolchain-dependent issue which ECL has no control<br>
over?<br>
</blockquote></div><br>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.<div>

<br></div><div>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>


</div>