Just to see, I just dug into how ##u8vector-ref works, and what I got is that in code with or without  (declare (standard-bindings) (extended-bindings)) ,  ##u8vector-ref and also  ##fxnum+  are not inlined in the output code.

Is this correct Marc?

(I suppose I did not get this right, bc Gambit's performance goals are to keep those kind of as fast as in C, and for that inlining is required?)


Also I checked what assembly is actually generated from resolving the memory address of a u8vector ___SCMOBJ in the C world, and it's only two assembly operations, neat!

(an AND -4 and an ADD 4 to the register with the ___SCMOBJ value in it, to get the contained pointer value)

Mikael

2012/8/9 Mikael More <mikael.more@gmail.com>
Ah, I just realized:

In order for ##sysmem-byteref  and  ##sysmem-byte-set!  to be implementable as single CPU instruction operations, the pointer argument must be required to be fixnum only.

This is really fine.

2012/8/9 Alex Queiroz <asandroq@gmail.com>
This is not really Scheme, it is C, which can be done via a very short
C extension.

Well, it can certainly be Scheme if you want it to be Scheme, and I'm at a point where I really want this to be Scheme.

I don't want it to be a C extension, at least not in the ordinary sense where there's some kind of FFI barrier between the Scheme and C code, that at least makes a C function call out of the operation and thus adds a CALL addr and a RET (= 2 ops!) to the MOV sth,[sth] op. Also, I'd happy that the compiler would inline this when in compiled mode by itself, just like it does with ##u8vector-ref/set!.

I.e., I just want direct, unprotected access straight to the RAM at the CPU's ordinary speed for it.