On 2012-01-04, at 2:02 PM, John Cowan wrote:

> Marc Feeley scripsit:
>
>> The ARM is definitely not dead, and probably the architecture with
>> the largest market currently.
>
> Middle-endian doubles, who knew?  Gag me with a fork.

The more troublesome endianness aspect is that the ARM allows switching the endianness at run time (by flipping a flag in the CPU's status register).  Moreover the ARM stores code in little-endian format and data in either little-endian or big-endian format (IIRC).  So what do the little-endian and big-endian features refer to, code or data?  It is a mess that simple cond-expand feature identifiers cannot address well.

>> Which lower-level software and how can I interface to them given that
>> there's no FFI in R7RS-small?
>
> R7RS-small does not *prevent* an implementation from supporting an FFI,
> obviously.  There will not be an FFI in R7RS-large as things currently
> stand; however, my bytevector library proposal provides BE, LE, and
> native versions of most numeric types.

In that case, why not defer the specification of these feature identifiers to R7RS-large, if and when they are actually needed?  I dislike standardizing things that have not been tested and whose usefulness hasn't been demonstrated.

Regarding bytevectors and endianness, Gambit avoids the endianness issue by separating the different uniform vector types (e.g. you can't treat a u16vector as a u8vector).  I'd be interested to see performance figures for your bytevector library proposal and how much performance is gained by having access to the endianness through a cond-expand, rather than just testing it at run time (i.e. (= 0 (u8vector-ref '#u16(1) 0))).

Marc

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports