The bug that Dennis found the other day is actually related to the AND operator.
The AND will screw up predictably and even more seriously than what was
happening to Dennis. To wit: 

	EXTERNAL ARRAY : VECTOR [,BYTE];
	LOCAL TEMP:UNSIGNED BYTE;
	TEMP = 7;	
	ARRAY[0] = .ARRAY[2] AND .TEMP;

Generates the following code:

	MOV #7,R0		;TEMP
	MOV ARRAY+2,ARRAY+0	;This is a real GEEK thing to do
	COM R0
	BICB R0,ARRAY+0

Notice that not only does it incorrectly generate a word move from what might be
an odd address, but it stomps all over ARRAY+1. This problem only seems to
happen when using an AND operator and when the operands are addresses of bytes.
If TEMP is declared as a word then it generates the correct code. Both the
current compiler (v4.1) and the new one (v4.2) do exactly the same thing in this
instance. At the moment, I have no recommended solution to this problem.
(Patient: Doctor, Doctor, it hurts when I do this! Doctor: Well, don't do that;
That'll be fifty bucks, please.) 

If you want to try the new compiler, do:

	$ set command utl$mac:bliss042

which will make subsequent compiles use the v4.2 compiler. If you want v4.1
back, logout and back in again.

ds

Awhile ago someone reported a BLISS-16 bug where the compiler was generating
word mode references to an array of bytes. I isolated the bug to the use of
the AND operator and sent in an SPR to DEC. Here is the text I sent them:

"There is a problem with the AND operator when the operands are addresses of
bytes as demonstrated with the following code fragment:

MODULE BUG (ENVIRONMENT(T11), ADDRESSING_MODE(ABSOLUTE)) =
BEGIN
    EXTERNAL ARRAY : VECTOR [,BYTE];
    GLOBAL ROUTINE BUG1 : NOVALUE =
	BEGIN
	LOCAL TEMP : BYTE;
	TEMP = 7;
	ARRAY[0] = .ARRAY[2] AND .TEMP;
	END;
END ELUDOM

Not only does it make a word reference to an arry of bytes which may be 
located on an odd byte boundary, but it stomps all over an adjacent cell. 
The problem seems to occur only when the AND operator is used with 
addresses of bytes. This problem is present in both BLISS-16 V4.1 and V4.2."

I got the reply this morning:

"Thank you for reporting this problem to us. It is indeed a bug in the BLISS-16
compiler. The problem also occured with the OR operator as well as the AND. We
have fixed the problem and will include the correction in the next maintenance
release of BLISS-16. In the meantime, you can work around the problem by
introducing a temporary byte sized variable and assigning the result of the 
AND to it and then assigning the value of the temp to ARRAY[0].

Thank you for your interest in the BLISS products."

ds

On 22-Apr-1986 I sent an SPR to DEC detailing the Bliss bug discovered by
Dennis. I got a reply this morning. 

"The response recieved for your Software Performance Report is as follows.
...We do not plan to publish this SPR.

Problem:

The compiler generates incorrect code for the program fragment below:

	WHILE .TEMP2 DO;	!This triggers the error
	IF .TEMP4		!Any code between it and the loop is lost
	THEN WHILE 1 DO;	!This is the infinite loop

Response:

The compiler incorrectly handled infinite loops under certain circumstances.
This problem has been fixed. The next maintenance version of the compiler will
contain the correction for this problem. In the meantime, we suggest the
work-around of compiling without optimization (using /OPT=LEVEL:0).

Thank you for your intrest in BLISS_16."

As usual, the answer is "...yep, its broke. Don't do that." Expect the the
next version (4.3) in about 4 months. In the meantime, if you need to use
infinite loops, see Dennis Harper about how he got around this problem.

ds