Path: g2news2.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 18 Oct 2010 21:33:19 -0500
Newsgroups: comp.lang.java.programmer,comp.lang.lisp
Subject: Re: some personal rambling on java the lang
References: <e4b7645f-08fd-440c-a659-5ae050a44a56@c32g2000vbq.googlegroups.com> <t3lfb6ptmem1bif2gr0fttp2cahd5nmmi8@4ax.com> <N5udnZZvBrBHhSHRnZ2dnUVZ_sWdnZ2d@speakeasy.net> <bcoob6hvgt9o4um46581rdvk3e9v2k71ot@4ax.com>
Organization: Rob Warnock, Consulting Systems Architect
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
From: r...@rpw3.org (Rob Warnock)
Originator: r...@rpw3.org (Rob Warnock)
Message-ID: <J7WdnVJAJsnyniDRnZ2dnUVZ_q6dnZ2d@speakeasy.net>
Date: Mon, 18 Oct 2010 21:33:19 -0500
Lines: 92
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 66.93.131.53
X-Trace: sv3-ulWsx2jjRB87CFQQjguKT32gitm1tUCWA9/GNAEkqw5lSMqYXkqszpf0ZRAHbwk3+GLu55xN577mUYp!jg43WJyG53qIGQbo+/AuCVJLC+W77X/XlXJb2R8bKQkRuVmPdfABuyZWb9F7KZb/VkygQzAVefoS!OrVBtdsLRnPFxpty1jNEt0IY6yc=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5084

George Neuner  <gneun...@comcast.net> wrote:
+---------------
| r...@rpw3.org (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.]

-----
Rob Warnock			<r...@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607