On 17 Feb 2009, at 3:47 pm, Eduardo Cavazos wrote:
Eduardo Cavazos wrote:
(define (bytevector-ieee-double-native-ref blob i)
(f64vector-ref (blob-f64vector/shared blob) i))
So the obvious problem here is the conversion is going to impact
performance.
If somebody who is familiar with Chicken internals can suggest a way
to extract an 'f64' element from a blob directly, I think I'll be
set. :-)
Hello!
There's a few ways. For a start, you can always make shared vectors,
as you do above - since they share the storage, creating them should
be pretty efficient.
Or you can write a C function that does tevector-ieee-double-native-
ref; see the section in the manual about accessing foreign functions -
a blob is passed to the C world as a pointer, and you can do
((double*)ptr)[index] in C and lo, a double will emerge. (IIRC, an f64
is a double, right?).
But, in the long run, I think Something Must Be Done.
Personally, I feel that bytevector is a bad idea - vector-of-bytes
is just one possible interpretation of a region of memory. I like the
idea of a blob that has no inherent access primitives - but that has
ways of making 'aliases' to regions of it that have types.
I made a proposal about this a while ago - I also wanted to avoid
having to copy memory blocks returned by foreign code into blobs for
use in the Chicken world; my proposal was to rewrite chicken's blobs
so that they may either be a heap-allocated region (for small blobs)
or an arbitrary pointer and length with a custom finalizer function
(which can handle calling free() on malloc-ed blocks). Having thus
abstracted out the management of the memory block, the underlying blob
system could then form a basis for other large-data types - such as
SRFI-4 vectors or R6RS bytevectors (if you must). These types would
all keep a reference to a blob used as the backing store, then a
base index and a length, so they can refer to just a subregion of the
blob. It might also be worth storing a custom stride that's used as
the multiplier when referencing rather than just sizeof(element), so
that it'd be possible to make:
1) A vector that represents a row *or* column out of a 2D array - or
any higher dimension
2) A vector that goes *backwards* without having to reverse it
explicitly, by having a negative stride
3) An infinite vector of the same element (by having a zero stride and
a MAXINT length)
Then it'd be possible to make sub*vector/shared functions that just
make a new vector referring to the same underlying blob, but having
different start/length.
ABS
--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
