[Aldor-l] Using GMP and extending the biging protocol

[Ralf Hemmecke]

On 08/16/2008 02:36 PM, pip88nl at gmail.com wrote:
> On Sat, Aug 16, 2008 at 01:12:08PM +0200, Ralf Hemmecke wrote:
>> First, the aldor interpreter working on bytecode is slow anyway (and 
>> even more buggy than the compiler) (so basically unusable).
> 
> That's irrelevant. Bytecode is needed to do anything with aldor at all.

We are hopefully both speaking about the .ao format, right?

>> Why wouldn't it make sense, that any bytecode interpreter has to provide 
>> an implementation of BInt that is consistent with the Aldor BigInt 
>> specification? So if the interpreter calls gmp code that would be fine.
>> Where is the problem?

> It would work if the bytecode loader was BInt based and converted the
> BInts it loads to mpz_t right away. That would require some refactoring,
> be ugly and slower on boot and compilation but it would work.

>> Couldn't an optimizer still optimize biginteger code form .as programs 
>> based on specification?

> I'm not sure what you mean here.

>> Isn't it the case already now that the BInt implementation lives in the 
>> interpreter/compiler and only "pointers" to BInt implementations live in 
>> the foam code?
> 
> Not really.. see aldor/aldor/src/foam.c:1747 where it loads the binary
> representation of a BInt from bytecode. Also, in .fm code, they are
> represented as strings: (Cast Word (Arr Char 49 50 51 52 53 54 55 56 57))
> would be "123456789". Larger integers are also stored like this. With
> optimisation turned on, they are stored as (BInt <number>) so a big
> integer would be (BInt 123456789) and in fact as binary bigint in
> bytecode.

Now if you mean that (BInt 123456789) would appear in the foam code, 
that is connected to optimization above. In fact if there is something like

   (BIntPlus (BInt 123456789) (BInt 1))   (does foam look like that?)

then the optimizer could replace that by (BInt 123456790). That doesn't 
require that the compiler knows anything about the runtime 
implementation of BInt, right?

 > Just pointers could never work in persistent data anyway,
> because the data is gone after a process ends.

Well, of course I did not mean pointers as in C. If it is more clear 
than yes, the bytecode could have some optimized representation of 
bigintegers (instead of arrays of characters). That is probably what you 
mean by you cannot remove BInt completely.

But why were it a problem if the .ao code contained just arrays of 
characters for bigints which are converted to the gmp representation (or 
whatever bigint library is used) at runtime (or interpreter time)?
There are certainly only a handful of explicit biginteger literals 
appearing in any .as program. Why would that slow down boot time 
dramatically?

But before going into more detail, it is much more important that the 
compiler produces non-segfaulting code. So I quite like your auditing 
work. Thanks a lot.

Ralf