AW: AW: [avr-libc-dev] mixed 32 / 16 / 8bit expressions

[Björn Haase]

>Are your rtl descriptions also capable of optimizing expressions like:
>
> (char/QI)x = (signed char/QI)y + (unsigned char/QI) ;
>
>Such that although GCC want's to promote the + operation to be an int
>as it's operands aren't of the same sign, they need not be as the target
>of the operation is not wider than it's largest un-promoted operand?

I have just had a look at what the RTL sequences look like, when
programing code like your example. For your sample case the stupid method,
I have applied so far does not work. I assume, that the best place for
improving this case is probably at the RTL generation step and I have
absolutely no idea about how this part of gcc works.

>And would be pleased to assist with any asm support function recoding
>as may be required conform to a refined ABI as necessary to enable a
>transition to a more efficient register allocation scheme. (seconding
>Eric's views.)

So far, I am not even sure, that the suggested modifications in the
register use for argument passing would improve the code.
It is merely my personal feeling, telling me that this is the place to look
at.
My hope is that, when teaching the compiler to pass arguments in the
most suitable registers, the automatic variables will tend to
end up in more suitable registers by default without using sophisticated
algorithms.

We also should not forget, that there possibly are a *lot* of other
places that use knowledge on the present ABI. I, e.g., have no idea
whether  gdb  assumes the parameters to be passed in consecutive
registers. We would, e.g.,  also need to reconsider the function calls by
function pointers that presently use Z, if Z possibly is assumed to contain
function arguments, etc. . We must be aware of quite a number of possible
errors.

BTW, does anybody know, which kind of ABI is used by IAR?

>How would you like to proceed with the experiment? (i.e. developmental .md
>file repository html/ftp link? Version of pre-release 4.0 required? etc.?)

No idea. I have played with the .md patterns mainly, because it was fun to
understand a bit better how the compiler works. And also because it was
fairly easy to implement. So far, I'd like to suggest that anyone
who is willing to test the change is invited to post his results. I would be
willing to respond to the reports and include possible bug-fixes and pass
them
to the maintainers in case that they consider them useful.

Concerning possible changes concerning the register usage, I will certainly
not start doing anything before having heard what the compiler experts (i.e.
Marek Michalkiewicz and Denis Chertykov) think about it.

>PS - Than with a little luck if we can figure out how to get GCC to
allocate
>constant data which can't be efficiently in-lined into flash program memory

I remember to have read some mailing list threads where someone has tried to
find a way to make more efficient use of the program memory. Likewise it
would
be fine, if one could treat the EEPROM simply like RAM variables, would it?
I fear, however, that the core problem is "C". If I am correct, the fact,
that
there is just one single "pointer" type implicitly assumes a Von-Neuman
architecture. Possibly one could find a workaround using c++ class template
for "constants in PROGMEM" that implements methods that make the function
calls
reading the progmem values transparent to the user code. Similarly for the
eeprom.

>along with possibly a scheme to enable the allocation of a handful of
global
>register as may be required by fast interrupt routines to work in a
friendly
>way with a refined register allocation scheme;  that would be very nice.

In case that one rewrites the argument passing algorithms of gcc, I agree
that
one should keep that in mind.

Yours,

Björn