Can you read? I clearly stated that:


So I already covered the case of your code posted above.


Why should it get worse? It's trivial to see that even if the compiler insists on applying the post-increment prior to the dereference it could have done it as:

; FUNCTION Func0 (BEGIN)
    R     MOV     R0,b
    R     INC     b
          MOV     A,@R0
    R     MOV     R0,a
    R     INC     a
          MOV     @R0,A
          RET
; FUNCTION Func0 (END)

See! No absolute register addressing required. And it's the same number of instructions and cycles as the "hand optimised" Func1.


I do. Because once you have multiple register sets in use it becomes very difficult to manage assignment of register sets to functions. And if you want to have a common function, callable from different register set functions, then it's impossible with absolute register addressing turned on.

And the worst bit is that even though the compiler knows that FuncA using register set 1 is directly calling FuncB with register set 2 it doesn't even issue a warning! It just generates code that doesn't work!


I would agree, if "absolute register addressing" was in anyway needed in these simple functions, but as I have shown above, it's not.


Not for Keil it's not. I distilled the problem down to a simple case. I see this sort of ugly code generation all the time from Keil. It doesn't matter whether the code is in a separate function or in the middle of a loop or anything else. Keil always seems to do a bad job with this sort of thing.


Absolutely not in Keil's case. It can't even get the simple things right. It definitely does not do better if you give it more code. I look at its assembly output often, and I am invariably shaking my head over what it has generated.