<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2">
</HEAD>
<BODY>
On Thu, 2006-08-24 at 12:32 +0200, Petter Egesund wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Some thoughts;</FONT>
<FONT COLOR="#000000">I am getting a little closer, passing all 110 test except 6. Storing of</FONT>
<FONT COLOR="#000000">stings seems to work now. What does not work is storing of integers, and</FONT>
<FONT COLOR="#000000">thereby rationals, bignums, and so on.</FONT>
</PRE>
</BLOCKQUOTE>
Thank you!
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">This will not work without some larger rewriting. As far as I can see</FONT>
<FONT COLOR="#000000">there are two options:</FONT>
<FONT COLOR="#000000">1. Force serializing of integers to 32-bit, not dependent on the</FONT>
<FONT COLOR="#000000">underlying OS. This seems to be the easy way out. What must be rewritten</FONT>
<FONT COLOR="#000000">is:</FONT>
<FONT COLOR="#000000">- storing of fixnums (which can be larger then 32-bit on 64-bit os).</FONT>
<FONT COLOR="#000000">Fixnums must be stored the same way as integers are stored today.</FONT>
<FONT COLOR="#000000">- storing of bignums, as reading directly from the bignum using</FONT>
<FONT COLOR="#000000">%bignum-ref can return 32-bit or 64-bit on different platsforms. A</FONT>
<FONT COLOR="#000000">rewrite of storing bignums can be done on two ways, either by testing on</FONT>
<FONT COLOR="#000000">platform, or by doing the work ourself, by doing some bitwise operations</FONT>
<FONT COLOR="#000000">(something like shifting bytes doing some bitwise and, and then repeat</FONT>
<FONT COLOR="#000000">until 0) I would wote for the last option, as this makes the codebase</FONT>
<FONT COLOR="#000000">less platform-dependent (might be a small speed-penalty though (I don't</FONT>
<FONT COLOR="#000000">know)).</FONT>
<FONT COLOR="#000000">2. We can start storing integers as 64-bits on 64-bits platform.</FONT>
<FONT COLOR="#000000">Probably means a lot of rewring? This will probably give the fastest</FONT>
<FONT COLOR="#000000">benchmark-results?</FONT>
<FONT COLOR="#000000">I would personally go for suggestion 1, I do not think the differnce in</FONT>
<FONT COLOR="#000000">speed will visible at all? Any opinions?</FONT>
</PRE>
</BLOCKQUOTE>
IMHO, your solution #1 is an OK patch as a stopgap. However, we definitely eventually want <BR>
to take full advantage of a 64 bit architecture --- this will be the wave of the future, and there is <BR>
no serious reason why we can't rewrite it. Having said that, I'm in no position to do it for a while,<BR>
so unless you or someone else wants to rewrite it, I propose the following:<BR>
<BR>
Let's produce a patch that works as much as possible on the 64 bit architecture, and document<BR>
the defficiency that on that architecture, for example, fixnums don't work. As long as this <BR>
continues to pass all tests on 32-bit architectures, we can release it as 0.6.1, for example.<BR>
<BR>
When Ian and I work on 0.7.0, if you or someone else will help us test on a 64-bit architecture, then<BR>
we will try to make sure that we fully support things in that release.<BR>
<BR>
I'll write up the documentation based on what we decide.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Cheers,</FONT>
<FONT COLOR="#000000">Petter Egesund</FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>