Re: Fun-O Basic Edition Compiler

[Bruce Hoult <address@hidden>]

In article <3C325335.7090604@quiotix.com>, Jeffrey Siegal 
<jbs@quiotix.com> wrote:

> > How can you do it for multiplication, other than by dividing afterwards 
> > and comparing, or pre-classifying the operands?
> 
> Well, sometimes you can preclassify at compile time...

Yes, if one operand is a constant, k, then you can test the abs() of the 
other against 2^31/k.

You can do pretty reasonable pre-classification by using some sort of 
logarithm of the operands and adding.  PPC has a count-leading-zeroes 
instruction that might be useful here.  But, you pretty quickly get into 
a situation where it's faster to divide the result by one operand and 
check that the answer is the other operand -- especially on modern 
out-of-order CPUs where there's likely to be an idle division unit 
anyway, and since nothing else depends on the results of the division it 
doesn't hold up the normal flow of processing much.  It'd just be making 
good use of the micro-parallelism that usually gets wasted :-)  (an 
argument which applies to much error checking, such as bounds checks, 
and makes it nearly free today)


> > OTOH, maybe it's time for Gwydion to have just a *little* assembler.  
> > That's not nice given that it runs on a number of different CPUs, but 
> > maybe it's not *too* bad: x86 and PPC will cover most people.  SPARC 
> > and MIPS and HPPA and IA64 would probably get the rest.
> 
> What's wrong with a little assembler on systems you chose to support and 
> standard C elsewhere?

A *little* wouldn't hurt much.  And, in fact, we already have some for 
constructing closures at runtime for Dylan functions being passed out to 
C libraries (e.g. the OS) as callbacks.


> On systems with 32x32->64 multiplication, this becomes very easy. (I 
> think that's what you were getting at.)

Yes.


> By the way, I just looked in the DRM and <integer> is *not* defined to 
> wrap there.  The overflow behavior is left implementation-defined.  So 
> programs which rely on <integer> wrapping are non-portable.

Correct.

I don't know of too many programs which *rely* on overflow of arithmetic 
wrapping.  There is quite a lot which does depend on the semantics of 
the bitwise boolean operators and shift operations, including things 
such as ash(foo, -big_number) producing a result with the sign bit 
replicated through the entire number.

Also, there are a limited number of implementations, and they both agree 
on wrapping by default, which suggests that the most likely thing to 
change is the documentation.


> That 
> suggests some merit in a compile-time option to trap such things, and it 
> also suggests some merit in having a class which is defined to wrap and 
> one which is defined to trap, for when the programmer explicitly wants 
> one behavior or the other.

These would be good things.

Dylan's "rename on import" features also make it easy to switch a body 
of code from using one class to another.

-- Bruce