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

[pip88nl at gmail.com]

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.

> 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. Just pointers could never work in persistent data anyway,
because the data is gone after a process ends.

Pippijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.aldor.org/pipermail/aldor-l_aldor.org/attachments/20080816/192c59dd/attachment-0002.bin>