[Aldor-l] Compiler development

[David Casperson]

Pippijn, you wrote

> 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).

Pardon my ignorance, I don't know what valgrind does.  I
shouldn't speak for Stephen Watt but I suspect that the reason
that the garbage collector does this large-scale search is an
assumption that ALDOR memory is shared with some other system,
for instance, Aldor running inside of Maple.


> 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.

I wrote the comment above.  The main point here is that before I
changed these definitions, the compiler was using signed
comparisons of pointers (cast to some integral type), and that
was causing the Mac OS X port to break.

I am aware that in C/C++ we are in Nasal Daemon territory when we
attempt to manipulate two pointers that don't point into the same
underlying array (or one past the end in C++), but it is hard to
see how to find a portable C fix to this that works across
platforms.  Presumably, if we run into problems on segmented
architectures we may have add some external routines to the
CC_noncanonical_pointer section.

> 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.

I am surprised to hear this.  I had seen comments to the effect
that instances of

     std::less<X*> ...

were required to supply a meaningful order for all legal X*
pointers, and in particular for pointers from different arrays.
I'm afraid that I can't cite a standard here, but the writer was
knowledgeable, and commenting specifically about implementations
of C++ on possibly non-flat architectures.

> 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.)

Aside the from the exception granted to ensure that "end"
iterators for plain arrays are valid, this is correct.  The
comment whose provenance I cannot remember explicitly asserted
that this did not hold for std::less and company.  This still
doesn't get us a solution that works in C, but it does seem to
indicate that for most architectures this is likely to work.


> 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.

That's my take too.  A slightly better solution might be to put
the ptrXX macros inside the conditional part of
CC_noncanonical_pointer in cport.h, and put comments in cconfig.h
explaining what is required when working with segmented
architectures.


> ...
> -- 
> Pippijn van Steenhoven

David
-- 
Dr. David Casperson, Assistant Professor     |  casper at unbc.ca
Department of Computer Science               |  (250)   960-6672 Fax 960-5544
College of Science and Management            |  3333 University Way
University of Northern British Columbia      |  Prince George, BC   V2N 4Z9
                                            |  CANADA