+---------------
| (e-mail address removed) (Rob Warnock) wrote:
| >Ahhh, how quickly they forget!!! BLISS <
http://en.wikipedia.org/wiki/BLISS>
| >predated C (at least publicly), and not only had pointers and an explicit
| >dereference operator (the infamous "dot"!)
|
| You're right ... I did forget about BLISS. However, my comment was
| about when the term entered popular usage - which I don't believe
| BLISS accomplished.
+---------------
Maybe not in the general public, though it certainly made it
to a large subset of DEC users... and not always favorably! ;-} ;-}
+---------------
| >But even better, BLISS has "structures" which were actually little
| >*user*-defined pieces of code for calculating a pointer, including
| >subfields [the "P" (offset) & "S" (width) values above], so a more
| >idiomatic way to write it [assuming "foo" had previously been "mapped"
| >with an appropriate structure] would be:
| >
| > foo[13, my_nibble] = .foo[13, my_nibble] + 5;
|
| Interesting ... but does a pointer to a partial word have any utility
| beyond device register control?
+---------------
Sure, the same thing as bitfields in C -- any time you have compact
data structures where you want to pack multiple values per machine word.
+---------------
| (Maybe what it was meant for?)
+---------------
Not really. Actually, BLISS's pointers almost *exactly* mirror the
hardware byte pointers in the DEC PDP-10 instruction set. The BLISS code:
foo[13]<12,4> = .foo[13]<12,4> + 5;
could be written in PDP-10 assembler like this:
movei t0, foo+15 / Note: Default base in MACRO-10 is octal.
hrli t0, 140400 / Make a byte pointer from &foo[13].
ldb t1, t0 / Load byte using byte pointer in t0.
addi t1, 5
dpb t1, t0 / Deposit byte.
If you need the subscript "13" to be computed dynamically, then you
can use the built-in indexing in byte pointers, and construct one
at compile time [assuming you can fix which register will be used
for indexing -- here we assume that "t2" == register 7]:
myfield: xwd 140407,foo / Byte pointer to foo[t2]<12,4>
Then the code becomes:
move t2, ...[the index]...
ldb t1, myfield / The contents of t2 get used by the hardware
addi t1, 5 / in the calculation of the effective addr.
dpb t1, myfield
The motivation for having such flexible byte pointers in hardware came
in part from the fact that the PDP-10 was a 36-bit wide word-addressed
machine that used 7-bit ASCII for normal text files [packed 5 to a word
with one bit wasted] but also used *6*-bit subset ASCII for file names
and extensions, as well as keywords in system calls. But the hardware
actually supported *any* byte size from 1 to 36. [In fact, it even
supported a byte size of 0, which gave a sometimes-useful no-op!]
I should also mention that there were also ILDB & IDPB instructions,
which would first *increment* the referenced byte pointer [by decrementing
the "position" field by the "size" field] and then perform the LDB or DPB
function on the ultimate target location. If there weren't enough bits
left in the byte pointer for the field to fit in the current word [the
"position" field went negative], the ILDB/IDPB would increment the *word*
address and reset the position field to 0, thus allowing the use of
ILDB/IDPB to step sequentially through the bytes of a packed string.
-Rob
p.s. Yes, I used mixed-endian conventions in my sample code in the
previous posting. The BLISS code there (and the PDP-10 assembler above)
used big-endian byte descriptions, while the C code used little-endian.
[I was trying to keep it simple.]
I'm more at home with VAX.