Re: [Chicken-hackers] debugging chicken itself

[Will M Farr]

Brandon (and everyone),

I think, rather than modifying the compiler, you would have more luck  
with writing some specialized macros which are like the attached  
code.  Making the compiler automatically infer that floating-point  
numbers are being used and then doing the right thing is hard;  
wrapping each of your calls to floating-point math in (with-float- 
arithemtic ...) is easy.

The attached file implements just such a (with-float-arithmetic ...)  
macro.  At the moment, it accepts a single valid scheme expression  
composed of symbols, literal numbers, and the functions +,-,*,/ and  
compiles it to a single C function which implements the arithmetic,  
assuming that all the symbols are bound to floating-point numbers  
when the expression is evaluated.

At the moment, it's not a big win (basically because most arithmetic  
expressions aren't that long, so having a single function call for (+  
(- a b) (* 2.0 c)) as opposed to three function calls doesn't save  
much time).  But, I think if you extended the language accepted by  
the with-float-arithmetic to include f64vectors, vector indices,  
tests, and loops you'd really have something.  For some ideas in this  
area, have a look at Randall Beer's FPC-PPC for OpenMCL, which you  
can find mentioned at http://mypage.iu.edu/~rdbeer/ .

Good luck!

Will

arithmetic-compiler.scm
Description: Binary data

On Feb 21, 2007, at 3:33 AM, Brandon J. Van Every wrote:

> felix winkelmann wrote:
> > On 2/20/07, Brandon J. Van Every <address@hidden> wrote:
> > > Is there a way to trace Chicken's execution of Scheme code?  I'd  
> > > like to
> > > see the Scheme code actually executing, even if it is slow.  I'm  
> > > trying
> > > to figure out if I can improve Chicken's generation of C code for  
> > > 32-bit
> > > floating point math functions.  I find that the sources really don't
> > > make any sense to me.  If I could see them working, then maybe  
> > > I'd have
> > > an idea what's going on, what the flow of control is.
> > >
> > > Failing that, anyone recommend other ways to visualize the code?   
> > > In the
> > > MSVC universe there are typically class browsers, so you can see  
> > > what
> > > code belongs to what.  I suppose a call graph generator would be
> > > helpful; this is typical of profiling tools.
> >
> > You can use the tracing and single-stepping commands from the
> > csi toplevel, but studying the source code really is the best way.
> >
> > I guess you are talking about unboxed floats: I think this is  
> > currently
> > quite hard to implement. The CPS transformation generates many
> > small functions, which pass live data on to their continuations.  
> > Since
> > GC can kick in at various times (nearly always), that live data  
> > has to
> > be in a state that can be saved properly before GC and restored
> > afterwards. Passing unboxed data will require specialized code being
> > generated (Appel's book "Compiling with Continuations" describes
> > this quite nicely). In the end the implementation weill become quite
> > complex and the procedures that benefit from that will be few.
>
> I am far more concerned about the overhead of 1 function call per  
> math operator.  This makes it impossible for a C compiler to do any  
> optimization of the code.  Boxed floats can at least be de- 
> referenced; it's not optimal but it's not a function call.
>
>
> Cheers,
> Brandon Van Every
>
>
>
> _______________________________________________
> Chicken-hackers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-hackers