|Is it still possible to strangle the designer of the PIC architecture or
|has he/she already left for Intel?

When it is not necessary to switch RAM banks, the PIC's architecture is
generally quite nice.  The lack of ADDLW on the 12-bit cores is a little
annoying, but it doesn't normally cause any real problems and there isn't
exactly a lot of spare room in the opcode map (the NOP-family instructions
(e.g. sleep, tris, etc.) don't fill all possibilities, and there's no need
for 32 'clrw' variants, but beyond that there's no room for anything else.

RAM banking, of course, causes most ideas of niceness to go out the window.
Even this shouldn't be too bad, though; while some assembly programmers
might play interesting games with the banking bits, it should be pretty
easy for a compiler to know the state of the banking bits at each instruct-
ion.  The pre-code generator could thus generate code using absolute addr-
esses and an "output cleanup" stage of the compiler could generate banking
instructions.

There are only two caveats I can see with that approach:

[1] If an instruction which may be conditionally skipped needs to switch
    RAM banks, the compiler may have to 'rework' the code; e.g. on a
    16C77 [w/ shared area]

                btfss           A,0
                 incf           B,f

        If A and B are both in bank 1, or one of them is in bank 1 and the other
        is in a shared area, the code would be...

                bsf             RP0
                btfss           A,0
                 incf           B,f

        If A and B are in different banks, the code would become...

                bsf             RP0
                btfsc           B,0
                 goto           ZZZ999
                bcf             RP0
                incf            B,f
        ZZZ999:
                ; Note: State of RP0 is unknown here!

        The 'decfsz' instruction is a bit more of a pain...

                bsf             RP0
                decfsz  A,f
                 goto           ZZZ998
                goto            ZZZ999
        ZZZ998:
                bcf             RP0
                incf            B,f
        ZZZ999:
                ; Note: State of RP0 is unknown here!

[2] When a piece of the code can be reached by two routes, unless the final
    cleanup examines the code following that point, it may be unable to
    judge where to re-set the bank bits to their proper values.  For example,
    in the code examples above, if the following code was going to access
    RAM bank 1, it would be best to put a "bsf RP0" before the final label
    so it would only have to be executed if RP0 had been cleared.  In the
    "decfsz" case, if the next access will be in bank 0 it would be best to
    clear RP0 just before the "goto ZZZ999".

Still, while I can understand the PIC's banking making it harder for comp-
ilers to produce GOOD code, I still don't see why they should have trouble
producing CORRECT code [btw, the CCS compiler can even do the above types
of rewrites even on code written with inline assembly].