[Openmcl-devel] make-heap-buffer question

[Gary Byers]

On Sun, 19 Sep 2004, Cyrus Harmon wrote:

> So I'm not sure exactly how to use the make-heap-buffer,
> make-heap-ivector stuff, or why it's in streams, for that matter, but
> this seems a bit odd:
>

Those functions are in l1-streams.lisp because the stream code is the
only code that uses them.  They aren't particularly useful or general.

>
> (multiple-value-bind (buf p)
>      (ccl::make-heap-buffer '(unsigned-byte 32) 256)
>    (print (array-dimensions buf))
>    (setf (aref buf 0) #x7f7f7f7f)
>    (setf (aref buf 1) #xaabbccdd)
>    (setf (aref buf 1023) #xdeadbeef)
>    (let ((*print-base* 16))
>      (print (aref buf 0))
>      (print (aref buf 1))
>      (print (aref buf 1023)))
>    (print p))
>
> gives the following results:
>
> (1024)
> 7F7F7F7F
> AABBCCDD
> DEADBEEF
> #<A Mac Pointer #x10A2CC>
>
>
> I can understand buf beingg 1024 _bytes_ (in the normal 8-bit sense)
> long, but it looks to me like it's 1024 unsigned-byte 32's long. Is
> this a bug or am I missing something?

Sometimes, to avoid confusion (or possibly to introduce it) the term
"octet" is used to mean "8-bit byte".

CCL::MAKE-HEAP-BUFFER accepts an array-element-type specifier and
an element-count as arguments; it returns 4 values

1) a vector of the indicated type, with the indicated number of elements
2) a pointer, which happens to share storage with the vector
3) the number of usable octets in the buffer (the product of the number
   of elements in the vector and the size of each element in octets,
   at least in simple cases.  Bitvectors and some floating-point types
   may not be simple.)
4) the internal typecode of the vector.

For a number of reasons, I'd discourage use of CCL::MAKE-HEAP-BUFFER;
it only tries to handle a few element-type specifiers (not coincidentally,
the ones that the stream-buffer-creating code might call it with), and
doesn't even do that in a very reasonable way.

CCL::%MAKE-HEAP-IVECTOR is even lower-level and less general.

I mailed out yet another variant a month or two ago; this version
tries to be a bit more reasonable, and actually does a little bit
of error/sanity-checking:

(defun make-heap-ivector (element-count element-type)
   (let* ((subtag (ccl::element-type-subtype element-type)))
     (unless (= (logand subtag target::fulltagmask)
                target::fulltag-immheader)
       (error "~s is not an ivector subtype." element-type))
     (let* ((size-in-bytes (ccl::subtag-bytes subtag element-count)))
       (ccl::%make-heap-ivector subtag size-in-bytes element-count))))

Note that (gratuitously) this function takes the same arguments as
CCL::MAKE-HEAP-BUFFER, but takes them in the opposite order.

I'd be willing to export MAKE-HEAP-IVECTOR, document it, commit to not
changing it without advance notice, address any remaining bugs,
etc. (The same would be true for any complementary functions that
would free the storage involved, etc.)  I'm less inclined to commit to
making CCL::MAKE-HEAP-BUFFER or CCL::%MAKE-HEAP-IVECTOR behave like
they were anything other than murky components of the implementation
layer, that might change or disappear for murky, implentation-dependent
reasons.

>
> Thanks,
>
> Cyrus
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>