Conference turris::decc

2103.0. "ldl into unsigned 32-bits on Windows NT: Bug or not?" by HYDRA::NEWMAN (Chuck Newman, 508/467-5499 (DTN 297), MRO1-3/F26) Fri Feb 21 1997 13:47

Consider the following source where table is declared to be an array of
unsigned integers, tj0 is declared to be an unsigned integer, and mask
is an unsigned __int64:

   tj0 = (tj0 + ti) & 255;
   mask = mask | (((unsigned __int64)table[tj0])<<40UL);

On UNIX (DEC C V5.2-030) this generates:
...
46FFF017     0974      and     r23, 255, r23    ; r23, 255, r23        ; 000727
4AE1F637     0978      zapnot  r23, 15, r23     ; r23, 15, r23         ; 000728
42EF0457     0988      s4addq  r23, r15, r23    ; r23, r15, r23        ; 000728
A2F70000     0990      ldl     r23, (r23)       ; r23, (r23)           ; 000728
4AE1F637     09A0      zapnot  r23, 15, r23     ; r23, 15, r23         ; 000728
5FFF041F     09A4      fnop                     ;
4AE51737     09BC      sll     r23, 40, r23     ; r23, 40, r23         ; 000728
44170400     09D4      bis     r0, r23, r0      ; r0, r23, r0          ; 000728

On Windows NT (DEC/MS C/C++ 10.20.6197) this generates:
...
465FF012     0790      and     a2, 255, a2      ; a2, 255, a2           ; 000241
42490052     0794      s4addl  a2, s0, a2       ; a2, s0, a2            ; 000242
A2520000     0798      ldl     a2, (a2)         ; a2, (a2)
4A451732     07A4      sll     a2, 40, a2       ; a2, 40, a2            ; 000242
44120400     07B4      bis     v0, a2, v0       ; v0, a2, v0            ; 000242


Two comments:

1)  The NT code does a load into an unsigned.  Since LDL does a sign extension,
shouldn't there be a ZAPNOT as in the UNIX code at instruction 09A0:

2)  The UNIX code does a ZAPNOT at instruction 0978, after and'ing with 255. 
This ZAPNOT isn't needed.  Is the NT compiler smart enough to know this, or
would it not have even put it there if the AND hadn't been there?

In my case I know that table is only significant in the lower byte, and the NT
code is exactly what I want.  Is there something I can do to the code to inhibit
the ZAPNOT instructions on Digital UNIX?

								-- Chuck Newman

> 1) The NT code does a load into an unsigned.  Since LDL does a sign
> extension, shouldn't there be a ZAPNOT as in the UNIX code at instruction
> 09A0:

The canonacle representation of an unsigned 32 bit integer in a 64 bit
register is sign extended.  This freaks people out occationally.
Also, GEM -- the optimizer -- has code which keeps track of what bytes are
clean and what bytes are junk in registers.  If some bytes are not to be
used, GEM tries to avoid inserting instructions to clean them up.

The frontends for the two compilers are different enough that the Unix
problem might be a code quality problem.  Except that Unix has been much
slower in following GEM releases.  Perhaps the compiler in cc.alt (which is
newer and has later versions of GEM, though not as recent as Visual C++
V5.0 Beta2) will generate the improved code.

> 2) The UNIX code does a ZAPNOT at instruction 0978, after and'ing with 255.
> This ZAPNOT isn't needed.  Is the NT compiler smart enough to know this, or
> would it not have even put it there if the AND hadn't been there?

See above.

> In my case I know that table is only significant in the lower byte, and the
> NT code is exactly what I want.  Is there something I can do to the code to
> inhibit the ZAPNOT instructions on Digital UNIX?

1. Try using the cc.alt compiler.  
2. Encourage the Unix and therefore DEC C teams to shorten the delays
between when GEM declares a base level suitable for customers, and the time
when such a compiler reaches customers.
3. Log as yet unfixed code quality bugs (that's what we call 'em) in
GEMGRP::GEM-CODE-QUALITY.NOTE.

Roland.