On 12/18/06, Nils Springob <[EMAIL PROTECTED]> wrote:
Hi,
and it is possible to use an anonymous struct:
True. However, unnamed struct/union fields are an extension of the C
language provided by GCC and not strictly portable. It is a nice
feature though. It would be nice if it crept its way in
Hi,
and it is possible to use an anonymous struct:
static inline uint16_t bswap_16_inline(uint16_t x)
{
union {
uint16_t x;
struct {
uint8_t a, b;
};
} in, out;
in.x = x;
out.a = in.b;
out.b = in.a;
return out.x;
}
Regards,
Nils
On 12/18/06, David VanHorn <[EMAIL PROTECTED]> wrote:
Am I missing something here?
Why not pop to assembler, push the high, push the low, pop the high, pop the
low?
* Inline assembler cannot be used at compile time, for example to
initialize a static variable.
* If the swap function is called
On 12/18/06, Anton Erasmus <[EMAIL PROTECTED]> wrote:
Hi,
Not a macro, but the following seems to generate reasonable code.
...
Thanks Anton,
I came to the same conclusion.
Cheers,
Shaun
static inline uint16_t bswap_16_inline(uint16_t x)
{
union {
uint16_t x;
On 18 Dec 2006 at 11:28, Shaun Jackman wrote:
> On 11/26/06, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > On Saturday 18 November 2006 00:30, Shaun Jackman wrote:
> > > The following macro expands to some rather frightful code on the AVR:
> > >
> > > #define BSWAP_16(x) \
> > > x) >> 8)
On 11/26/06, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
On Saturday 18 November 2006 00:30, Shaun Jackman wrote:
> The following macro expands to some rather frightful code on the AVR:
>
> #define BSWAP_16(x) \
> x) >> 8) & 0xff) | (((x) & 0xff) << 8))
Sometimes gcc is generating better
Denis Vlasenko wrote:
The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) >> 8) & 0xff) | (((x) & 0xff) << 8))
Sometimes gcc is generating better code if you cast
values instead of masking. Try:
( (uint8_t)((x) >> 8) | ((uint8_t)(x))
On Saturday 18 November 2006 00:30, Shaun Jackman wrote:
> The following macro expands to some rather frightful code on the AVR:
>
> #define BSWAP_16(x) \
> x) >> 8) & 0xff) | (((x) & 0xff) << 8))
Sometimes gcc is generating better code if you cast
values instead of masking. Try:
It isn't only on the AVR that bswap_32() is nontrivial to get
right.
These two versions would rule on the i386 if GCC would be just a
little bit
smarter:
I prefer the single instruction bswap that we now generate for
__builtin_bswap[32,64] myself...
-eric
On Fri, Nov 17, 2006 at 04:30:53PM -0700, Shaun Jackman wrote:
> Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
> with -O2.
>
> I won't bother to show bswap_32 here, which produces a real disaster!
> Think 47 instructions, for what should be 6.
You may get better code i
On Sun, Nov 19, 2006 at 08:31:22AM -0700, Eric Weddington wrote:
> Rask, do you have FSF paperwork in place?
Yes, it was completed recently.
--
Rask Ingemann Lambertsen
> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED]
> Sent: Sunday, November 19, 2006 3:55 AM
> To: Eric Weddington
> Cc: Paul Brook; gcc@gcc.gnu.org; Shaun Jackman;
> avr-gcc-list@nongnu.org
> Subject: Re: [avr-gcc-list] Re: AVR byte swap optim
On 11/19/06, Eric Weddington <[EMAIL PROTECTED]> wrote:
> Use gcc head, __builtin_bswap and make sure the AVR backend
> implements the
> bswap rtl patterns.
There's the problem. You can't just glibly say "make sure the AVR backend
implements the bswap rtl patterns". There are precious few volunt
> -Original Message-
> From:
> [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> org] On Behalf Of Paul Brook
> Sent: Saturday, November 18, 2006 9:46 AM
> To: gcc@gcc.gnu.org; Shaun Jackman
> Cc: avr-gcc-list@nongnu.org
> Subject: [avr-gcc-list] Re:
> Ideally, this macro would expand to three mov instructions and a ret.
> Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
> with -O2.
>
> I won't bother to show bswap_32 here, which produces a real disaster!
> Think 47 instructions, for what should be 6.
Use gcc head, __buil
On Fri, Nov 17, 2006 at 04:30:53PM -0700, Shaun Jackman wrote:
> The following macro expands to some rather frightful code on the AVR:
>
> #define BSWAP_16(x) \
> x) >> 8) & 0xff) | (((x) & 0xff) << 8))
[snip]
>
> Ideally, this macro would expand to three mov instructions and a ret.
> Is
16 matches
Mail list logo
