[Aldor-l] Bytecode

[pip88nl at gmail.com]

Hi,

currently, the Aldor compiler uses its own backend for writing data in a
platform independent format. Maintaining this for many platforms is a
pain, because new platforms keep emerging and the compiler code is
complex already.

In 1987, RFC1014 was created, describing a format known as XDR (eXternal
Data Representation). It supports all vital C datatypes and is directly
supported by many operating systems, notably POSIX compliant ones. There
are various toolkits around for windows.

If we really have to port to platforms for which no XDR libraries exist,
it is probably trivial to create or port one.


Another part of the compiler is the big integer arithmetic class. I would
very much like to move this to GMP. I didn't find any optimisations that
are done based on intimate knowledge of the bigint representation, but
maybe Stephen can comment on that.

Whether we can indeed move big integers to GMP is uncertain. Aldor byte
code encodes big integers as list of limbs of a certain size. They are
copied directly into the internal bigint representation as "places".
(This makes it impossible to make BInt abstract, by the way.) I'm not
sure how this can be done with GMP, which is not abstract either, but the
representation is implementation defined and may differ between versions.

I would also like to remove garbage collection from the compiler itself
and use it only for the runtime. The collector works fine but relies
heavily on platform dependent behaviour. This would result in removing
the garbage collector and memory map retrieval from the compiler code
entirely and put it into its own, separate, library.

I am rather reluctant to move Aldor to C++, because of the lack of C++
compilers on certain platforms (such as Minix 3 (where GCC is available,
but not well tested), which uses the Amsterdam Compiler Kit).


The main reason for me to "outsource" parts of the compiler is that I
eventually want to verify the compiler. That means, I want to prove that
all algorithms used terminate and yield correct results. Currently, the
compiler is wrong. It does not always terminate and does not yield
correct results. In parallel, I want to add microtests that check whether
the functions do what they are supposed to do for all (valid and invalid)
input.

I don't know whether it is possible to "fix" the compiler so it can be
formally proved right, but I'm getting a bit frustrated with it.
Theoretically no-op changes breaking everything, parts relying on
undefined or platform-specific behaviour, etc. are deadly. As a
compiler of a mathematical language, I think it is unacceptable to be
broken like this.


A (probably quite good) reason not to switch to XDR is that it would
probably break old bytecode. It might be possible to design an XDR
interface such that it is binary compatible with the Aldor bytecode, but
it would be a huge mess, because Aldor bytecode supports 16 bit integers
whereas XDR has only 32 and 64 bit integers. Also, Aldor stores floating
point numbers in its own (XFloat) format. I think this is the same as
IEEE floating point format also used by XDR. All things considered, it is
unfeasible to support the Aldor bytecode format with XDR.
It would be easy (through not trivial, it would take some time) to write
a converter for Aldor bytecode to XDR.

Now the question remains: do we want to move to XDR?


Last but not least, I would like to attend everybody to the following
mailing list items I need more feedback on:
http://www.nabble.com/Abstract-Data-Types-td20205068.html
http://www.nabble.com/Calling-ptrCanon-twice-td18987511.html
http://www.nabble.com/Internal-data-types-td19000983.html
http://www.nabble.com/Layering-in-the-compiler-td19002005.html


I would appreciate any thoughts, comments and/or suggestions to my
proposal.

Regards,

-- 
Pippijn van Steenhoven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://aldor.org/pipermail/aldor-l_aldor.org/attachments/20081209/51f10e0b/attachment.bin