[gambit-list] How access arbitrary memory addresses (r/w)?
mikael.more at gmail.com
Thu Aug 9 17:56:10 EDT 2012
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)
2012/8/9 Mikael More <mikael.more at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list