[Aldor-l] Compiler development

[Pippijn van Steenhoven]

Hi,

I have a few additional questions regarding the aldor compiler and a few
things to correct from earlier posts.

First of all: the reason valgrind warns 14 million times even if I
allocate only 1 byte of memory is the garbage collector scanning the full
memory image including the read-only data segment and the stack for
pointers. This is how garbage collectors work, so it's fine, it just does
a good job at rendering valgrind completely useless, which is not so
nice. I am not sure how other garbage collectors get around this (or
whether they do at all).

I'm not sure who did, but someone said that the aldor GC is quite fast.
It is.. quite, but I don't see why every allocation using stoAlloc must
take 30 times longer than an allocation using system malloc. I will be
looking into the allocation later, after some bugs have been fixed.

I came across the following comment:

 * Most C compilers ought to be able to Do The Right Thing with the
 * definitions below, as the corresponding C++ compiler is obliged to
 * support std::less<Pointer>() & co,  which is obliged to be a consistent
 * total order on the Pointer type regardless of where the pointers
 *  are found.

this comment is about the relational operator applications in the
ptr[GL][ET] functions. The first assumption is right: every C compiler on
a flat memory model system will do the right thing. Nearly every platform
supported by aldor uses such a memory model, so it is fair to assume that
it works as you would expect. The rationale for this, however, is wrong.
The std::less<> template does nothing but return x < y according to
ISO/IEC 14882:2003 20.3.3p5. All it does is wrap it. Also, according to
ISO/IEC 9899:1999 (the C99 standard) section 6.5.6p9, relational
operators applied to pointers whose pointees are not members of the same
array result in unspecified behaviour. The same applies to C++ where it
is specified in 5.9p2 (the last point: Other pointer comparisons are
unspecified.)

The exception to this is the 8086 which is also said to be supported by
aldor. The 8086 architecture implements a segmented memory model where
memory pages may overlap. The assumption breaks on such systems. I have
several suboptimal solutions to the problem. One of them would be ignore
it.

Another issue is the "portable bytecode format". Right now I am too tired
to really look into it, but it seems to assume that a byte always
consists of 8 bits:

 # define BYTE_BITS              8       /* Not sizeof(...)!  See above. */

I find this comment rather misleading, since it is not possible to find
the number of bits in a byte using the sizeof operator anyway.. "see
above" points at the "these are hardcoded numbers because we need to be
portable" statement.

As far as I can see, aldor currently supports:
 - Intel 8086
 - Intel 80386
 - Motorola 68000 series
 - AIM PowerPC
 - Intel IA64
 - IBM System 370
 - AIX RT
 - AIX RS/6000
 - Sun Sparc
 - Sun Sparc64
 - Alpha AXP
 - IRIX MIPS
 - Cray
 - VAX
 - HPPA-RISC

I assume each of them currently works, but if I start rewriting things, I
might break some of them. We need people who test aldor on their
platform. Who uses what?
 
-- 
Pippijn van Steenhoven
-------------- 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/20080615/6481f77d/attachment-0002.bin>