Conference turris::decc_bugs

1284.0. "Questionable code generated by C compiler involving mtpr_mces" by STAR::BELLOWS () Wed Apr 02 1997 15:56

I was attempting to optimize some code and stumbled across the following...

Code 1:

    uint64          mces;

    mces = mfpr_mces;
    mtpr_mces(mces|PR$M_MCES_MCK);

Resulting generated code:

    00000010     31E8               MFPR_MCES           ;            ; 050620
    44003400     31EC               BIS     R0, 1, R0   ; R0, 1, R0  ; 050621
    43E00010     31F0               SEXTL   R0, R16     ; R0, R16
    00000011     31F4               MTPR_MCES           ;
 
--------------------------------------------------------------------------------
Code 2:

    uint64          mces;

    mtpr_mces(mfpr_mces | PR$M_MCES_MCK);

Resulting generated code:

    00000010     313C               MFPR_MCES           ;            ; 050590
    44003410     3140               BIS     R0, 1, R16  ; R0, 1, R16
    00000011     3144               MTPR_MCES           ;

--------------------------------------------------------------------------------

It was assumed that Code 1 & 2 were logically equivalent, however there appears
to be a fairly significant difference.

It is curious that in Code 1, the result from the BIS instruction is sign
extended from the first longword.  This could be highly undesirable because the
mces register could contain important status bits in the upper longword that may
need to remain asserted after clearing bits in the lower longword.  Can anyone
explain the reason for the SEXTL instruction, that does not show up in Code 2?


Thanks,

- Greg

If you look in BUILTINS.H, you'll see that DEC C believes that
MFPR_MCES returns an int (ie, 32 bits) and that MTPR_MCES expects
an int parameter.  I think all the rest follows from this...

If you edit the header and change the prototype to use __int64 instead
of int, you get the right result.  Alternatively, you can use the asm
intrinsic to invoke any machine instructions, including PAL calls.
Having separate builtins for each PAL call is not necessary.

We'll fix the header file in V5.6.