On 3/3/07, Bradley Lucier <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
