Re: [Scheme-reports] Standard Feature Identifiers are too low-level

[Marc Feeley <feeley@x>]

On 2012-01-04, at 3:13 PM, John Cowan wrote:

> Marc Feeley scripsit:
> 
>> 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.
> 
> I agree it's a mess.  Surely data would be the thing that required
> testing if anything did, however.

Unless you are writing a JIT compiler.  But I agree that for the ARM a simplistic API would probably attach endianness to data, since that is the only one that can change.

>> 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.
> 
> Well, as I say, the ticket has been filed.
> 
>> 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))).
> 
> Surely anything that avoids run-time tests (other than the unavoidable
> argument domain test) can only be a performance win.

I expect the difference to be completely lost in the noise, unless the endianness test was executed very frequently.  The test could be made very infrequent by writing code like this:

(define (u16vector-ref bytevector n) ..) ;; possibly builtin

(define u16levector-ref
  (if (dynamic-test-for-little-endian)
      u16vector-ref
      (lambda (bytevector n) ...)))

(define u16bevector-ref
  (if (dynamic-test-for-little-endian)
      (lambda (bytevector n) ...)
      u16vector-ref)))

That's why I am interested in actual performance figures to see if the endianness cond-expand feature identifiers do help performance-wise.

Marc


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