> Now a PLEA! It's been over 48 hours, some 250 people have downloaded
> the compiler, and there's been almost no feedback! Even if you can't
> find anything wrong (which seems unlikely) any comments will be appreciated.

[1] Under Win95 default DOS box, an attempt to compile a file named TEST.C
    failed; the error-message window contained the single line "CPP>".  This
    problem did not exhibit itself after I exited to DOS.

[2] Shifting right a signed long or signed int will produce sign-padding code;
    a sighted byte, however, will be shifted as unsigned.

[3] Even with full optimizations enabled, the compiler makes excessive use of
    ptemp; for any destination operand not declared volatile the compiler can
    and should use the destination operand as the workspace [e.g. if I code
    {a=b<<1;} the compiler should regard it as {a=b; a<<=1;} rather than the
    longer and slower {t=b; t<<=1; a=t;}.

[4] Given that addition and subtraction are common operations, the compiler
    would benefit greatly from special code for handling all cases of signed
    and unsigned values and constants of different sizes (3 different sizes
    of values, 15 for constants [since any byte may be zero]).  This would be
    much more effective than extending numbers into ptemp before processing
    them.  For example, uint=uchar1+uchar2 could be coded as:

        movf    uchar1,w
        addwf   uchar2,w
        movwf   uintLo
        clrf    uintHi
        rlf     uintHi

    and slong=schar+uchar could be coded as:

        clrf    slongB1
        btfsc   schar,7
        decf    slongB1
        movf    uchar,w
        addwf   schar,w
        movwf   slongB0
        btfsc   C
        incf    slongB1
        movlw   0
        btfcs   slongB1,7
         movlw  $FF
        movwf   slongB2
        movwf   slongB3

    For ulong+=uchar, this works well [kzero is a byte known to hold zero]

        movf    uchar,w
        addwf   ulongB0
        rlf     kzero,w
        addwf   ulongB1
        rlf     kzero,w
        addwf   ulongB2
        rlf     kzero,w
        addwf   ulongB3

I think the most offensive piece of code I've seen yet was for slong-- which
may be coded as follows:

        movlw   1
        subwf   slongB0
        btfss   C
         subwf  slongB1
        btfss   C
         subwf  slongB2
        btfss   C
         subwf  slongB3

Eight bytes.  I think the compiler generated more than twice that.

Not very good code generation for a PIC, but since its architecture is rather
unique conventional CG techniques won't work too well.  On the other hand, at
least I've only found one 'semi-bug': schar>>=1; from that perspective the
compiler at least seems to work.