On 2013-03-05, at 9:42 PM, Mikael mikael.rcv@gmail.com wrote:

Dear Marc,

There's ___FETCH_(S|U)(64|32|16|8) but no ___FETCH_F32 and ___FETCH_F64.

Currently those need to be defined separately by the user something like

#define ___FETCH_F32(x) &___F32VECTORREF(X,0) #define ___FETCH_F64(x) &___F64VECTORREF(X,0)

The ability to fetch F32 and F64-vectors is useful when passing a float or double array to some C library, for instance for math or 3D.

Is there any particular reason for why they were not bundled til now? What about including them, if not else then for completeness?

Thanks, Mikael

The purpose of the ___FETCH_* and ___STORE_* macros was to support 8/16/32/64 bit memory operations on all architectures wether those data sizes have a direct machine instruction equivalent or not. For example, on some (now very old) cray architectures, the only supported memory operations were 64 bit reads and writes. So on a cray, these macros implement 8/16/32 bit reads and writes using 64 bit reads and writes. More relevant to more recent architectures, the 64 bit reads and writes are implemented using 32 bit reads and writes on 32 bit architectures without a 64 bit datatype. This may seem like overengineering but it is all coherent with Gambit's portability goal.

For completeness I will add the following:

#ifdef ___F32 #define ___FETCH_F32(base,i)*(___CAST(___F32*,base)+(i)) #define ___STORE_F32(base,i,val)*(___CAST(___F32*,base)+(i)) = (val) #define ___CAST_F32(x)___CAST(___F32,x) #endif

#ifdef ___F64 #define ___FETCH_F64(base,i)*(___CAST(___F64*,base)+(i)) #define ___STORE_F64(base,i,val)*(___CAST(___F64*,base)+(i)) = (val) #define ___CAST_F64(x)___CAST(___F64,x) #endif

Marc