[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Standard Feature Identifiers are too low-level
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
(lambda (bytevector n) ...)))
(lambda (bytevector n) ...)
That's why I am interested in actual performance figures to see if the endianness cond-expand feature identifiers do help performance-wise.
Scheme-reports mailing list