Re: typedef void *

[Radey Shouman <Radey_Shouman at splashtech dot com>]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> jimb@red-bean.com writes:
> > 
> > > ramap.c is entirely incomprehensible to me.
> > 
> > Indeed.  You too?  :)
> 
> Well, I've looked a little more at ramap.c, and now I know it is
> for mapping operations over arrays efficiently, but that about as far
> as it goes.

For what it's worth, ramap.c started out as a translation of the array
mapping functions in SLIB to C.

ramap.c implements array mapping procedures ARRAY-MAP!,
ARRAY-FOR-EACH, ARRAY-INDEX-MAP!, and also ARRAY-EQUAL?.  Internally
it maps C procedures over one dimensional slices of arrays, so that
calling overhead and array indexing does not dominate the cost of
mapping.  You could think of this as loop unrolling.  For arrays in
lexicographic order (eg, all of those not made by MAKE-SHARED-ARRAY or
TRANSPOSE-ARRAY), the entire array may be unrolled.

The array mapping functions duplicate some of the dispatching done by
eval, so as to avoid dispatching on procedure type for each member of
an array -- some familiarity with the evaluator might help reading
ramap.c.

There are array mapping procedures for arithmetic on uniform arrays
without allocating cells.  These are quite stereotyped and could
probably be better done by machine.  I think the original ugly SCM
hack for mapping primitive procedures (+, *, <, > ...) to C level
array procedures is still in place; this should be replaced by a
more Guile-like mechanism.  Ideally, users would be able to add
`vectorized' functions as needed.

When mapping some primitive functions without particular vectorized
versions over uniform arrays, ramap.c will attempt to minimize
allocation by recycling pairs used for storing floats and doubles.
This assumes that primitives of certain types will never store their
arguments.  This may be too strong an assumption concerning user C
code for Guile's purposes.  (Perhaps some sort of C level declaration
could be supported.)

The array arithmetic procedures were written to vectorize if possible
on CRAY vector machines (the IVDEP declarations).  This might possibly
be important for a truly minuscule fraction of Guile users, (in fact,
this fraction cannot be bounded away from zero).