[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
 LIST*  LOAD-BYTE
- To: MOON at MIT-AI, JONL at MIT-MC
- Subject:  LIST*  LOAD-BYTE
- From: GLS at MIT-AI (Guy L. Steele, Jr.)
- Date: Tue ,4 Dec 79 11:16:00 EDT
CC: GLS at MIT-AI, (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI
 LIST* of zero arguments ought to be an error, as has
already been pointed out. I originally wanted (LIST* a) => a,
but forget whether that was done originally or not.
 [a] Regarding byte pointers, the LISP Machine syntax still has the
two severe disadvantages that (i) you can't parse it unless it is
in octal notation, and (ii) the byte size is limited to 63 decimal.
I have in the past suggested that a function BPTR be introduced
such that (BPTR p s) takes two non-negative fixnums p and s and
produces a byte pointer. The nature of this pointer is machine-
dependent, but may be given to the LOAD-BYTE etc. functions
and be expected to work. Probably also there would have to be
functions BPTR-SIZE and BPTR-OFFSET to extract the s and p
numbers from a byte pointer.
The advantages of this are several.
(i) Neither p nor s is limited in value by these definitions.
(ii) The precise representation of a byte pointer can be machine-dependent
for greater efficiency. For example, the LISP Machine byte pointer
format is not suitable for the VAX.
(iii) When writing (BPTR p s) one can write p and s in whatever radix
[b] Regarding left-to-right versus right-to-left, I would suggest that
bits always come out in right-to-left order *when converted to fixnums*
for the reasons expounded by Moon. Thus (LOAD-BYTE #B"0101100" (BPTR 2 3))
produces the fixnum 6. (Are not bits naturally numbered this way
anyway in the VAX?) For machine-@dependent crocks, a machine-dependent
set of primitives may also extract byte in whatever way is convenient
for the machine.
The S-1 will store bits in left-to-right order (bag-biters they),
but the compiler will gladly output bit-reverse instructions to keep
this compatible interpretation (eliding them when possible).