On 3/3/07, Bradley Lucier <lucier_at_math.purdue.edu> wrote:
> By having only one type of bytevector that aliases all of 32-bit
> integers, 64-bit integers, 32-bit IEEE 754 numbers, and 64-bit IEEE
> 754 numbers, optimization opportunities for compilers are severely
> degraded. One does not know, for example, whether storing a 64-bit
> IEEE double into bytevector A changes the value of a 32-bit integer
> read from bytevector B without actually checking whether A and B are
> the same objects and whether the range of indices used to access A
> and B overlap.
>
> This very problem has been recognized by recent C standards, which
> forbid such types of aliasing except by going through (char *). (The
> proposed R6RS bytevectors would propose a problem for more than
> Scheme->C compilers, however---it is a library design problem.) It
> could be said by analogy that the proposed R6RS libraries offer
> *only* a (char*) (more tamed than in C), which solves one small
> class of problems (how to allow semi-portable, low-level translation
> between data types that can be considered sequences of bytes; how to
> write I/O device drivers; ...) while completely ignoring a much
> larger and more important class of problems (allowing fast and memory-
> efficient access to large arrays of homogeneous numerical data).
Is your suggestion that Scheme compilers be allowed to assume that two
bytevectors do not alias, without either proving this statically or
checking it dynamically? This is the Fortran solution, and I would
guess that it's what the C standard has done as well. But while it
would allow compilers to optimize certain classes of programs much
more effectively (mostly scientific computation), it throws away all
of the work done to make Scheme a safe language.
If there is another way to deal with aliasing, I'd be interested to hear it.
--
sam th
samth_at_ccs.neu.edu
Received on Mon Mar 05 2007 - 08:36:59 UTC