[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Shorter code?

From: hutchinsonandy
Subject: Re: [avr-gcc-list] Shorter code?
Date: Thu, 12 Jun 2008 16:39:43 -0400

The theory is that RTL should map to single target instructions. So all the optimisation can be done at RTL level with a few oppertunistic "peephole" optimsation beyond that.

However, the AVR uses multiple (avr) instructions to match RTL to cope with 16, 32 bit data types.

The reason for this is that arithmetic, compare and similar operation that require CARRY cannot be handled in RTL for the AVR. RTL can handles the CARRY part, (indeed other targets do it this way). The problem with AVR is related to it's limited addressing capabilities. So additional instructions may need to be inserted that corrupt CARRY.

For example, This would happen if one byte of a multi-byte ADD had to be fetched from a memory address, that (for example) was more than 63 bytes away from a base register. To reach that address, another addition would be performed - which knackers the CARRY.

GCC does not (yet) have a mechanism to handle that.


Sent from my Dingleberry wired device.

-----Original Message-----
From: Ruud Vlaming <address@hidden>
To: address@hidden
Sent: Thu, 12 Jun 2008 4:23 pm
Subject: Re: [avr-gcc-list] Shorter code?

On Thursday 12 June 2008 15:59, Schwichtenberg, Knut wrote:
it looks that you use a structure to define your high and low byte.
don't you define a union covering high and low byte structure and a 16
bit value? Gcc knows how to handle that and there is no need for
shifting. I use this very often and if your CPU support 16 bit loads
uses them.


On Thursday 12 June 2008 16:20, Paulo Marques wrote:
One trick I use to help the compiler is to define something like:

typedef struct { uint8_t l, h; } BYTES;

typedef union {
   uint16_t w;
   BYTES b;

The structure solution was known to me, and then i forgot
about it, so thanks for the hint, i will implement that. But
my question was also of more general of nature.

1) Why is there no compiler optimization pass after code generation
that takes care of this? It seems so natural.
==> Wel Eric said why, simply because no one did write it yet. So hey, i can be first! I assume however that such optimizations must be written in RTL,
which is quite new to me.

2) Is there some short way in C to convince ggc to do that trick, just like
gcc understands that
 if (( val & 0x04) == 0x04)
can be translated to a single instruction on the avr.
But is seems there is non for the situation i described (aside from
the union solution)

Thanks for your responses.

AVR-GCC-list mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]