<dlp@itasoftware.com> wrote:
+---------------
| Rob Warnock wrote [re BLISS]:
| > 	I := .I + (2 * .J);
| > versus:
| > 	X := .X FADR (2.34 FMPR .Y);
| > The problem was that you could easily shoot yourself in the foot
| > if you used integer ops on floating values or v-v.
| 
| Actually the bigger problem was all the .s.  Period was the
| dereference operator.
+---------------

Yes, since variable names were *always* addresses [well, pointers],
just like in assembler. So "I := .I + (2 * .J);" could be translated
directly into:

    MOVE  T0, I
    MOVE  T1, J
    IMULI T1, 2
    ADD   T0, T1
    MOVEM T0, I

and "I = J + 2;" [in C, "I = &J + 2;"] was:

    MOVEI T0, J
    ADDI  T0, 2
    MOVEM T0, I

+---------------
| Since the BLISS compiler was highly optimizing...
+---------------

Yup. It actually would emit this instead of my first example above:

    MOVE  T0, J
    IMULI T0, 2
    ADDM  T0, I

+---------------
| it was very happy to take code like:
|       IF A EQL B THEN ...
| ,notice that the address of A was never the same as the address of B
| and silently delete the entire IF block. ... It didn't help that the
| compiler authors resisted supporting deleted code warnings on the
| grounds that you might have intended to do that.
+---------------

Actually, IIRC it was more that the common style for writing STRUCTUREs
(a kind of macro that a BLISS user wrote to define the algorithm used
when a variable was "subscripted", e.g., "A[.I, .J+2]") in systems
code used lots of subsidiary macros for fields, e.g., "P = .P[NEXT]"
where "NEXT" might be a macro that expanded into "0,3,18,18", which
inside the STRUCTURE ended up fetching the left-hand-side of word 3
of the block pointed to by P. Those STRUCTUREs were often written as
CASE expressions that dispatched on the various small constants of the
field-selector macro expansions, the result being that there was *LOTS*
of dead code all over the place that needed to be eliminated!!

...which the BLISS compiler was very good at, but the dead code
elimination didn't occur until *long* after the macro expansion
was done & gone, so how was the compiler to know which bits of dead
code were "normal" (e.g., the massive amounts generated by the above
STRUCTURE + CASE + selector macros idiom) and which were due to users'
mistakes?!?


-Rob

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