The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) >> 8) & 0xff) | (((x) & 0xff) << 8))
uint16_t bswap_16(uint16_t x)
{
0:9c 01 movwr18, r24
2:89 2f mov r24, r25
4:99 27 eor r25, r25
The GCC build (svn revision 118976) is not finding the target as,
although it appears to be in the right place.
Thanks,
Shaun
$ ../configure --target=avr --enable-languages=c --prefix=/usr
...
$ cat gcc/as
#!/bin/sh
exec "$@"
$ /usr/bin/avr-as --version | head -1
GNU assembler 2.16.1
$ make
...
I would like to multiply a 16-bit number by an 8-bit number and
produce a 24-bit result on the AVR. The AVR has a hardware 8-bit *
8-bit -> 16-bit multiplier.
If I multiply a 16-bit number by a 16-bit number, it produces a 16-bit
result, which isn't wide enough to hold the result.
If I cast one
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each 8x
On 12/4/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
...
For comparison, a hand
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
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 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, 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
Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a
switch in gcc-4.0?
Cheers,
Shaun
On Mar 22, 2005 12:29 PM, Andreas Jochens <[EMAIL PROTECTED]> wrote:
> Package: romeo
> Severity: normal
> Tags: patch
>
> When building 'romeo' on amd64 with gcc-4.0,
> I get the following erro
Hello,
I'm implementing a tiny vfork/exit implementation using setjmp and
longjmp. Since the function calling setjmp can't return (if you still
want to longjmp to its jmp_buf) I implemented vfork using a statement
expression macro. Here's my implementation of vfork.
jmp_buf *vfork_jmp_buf;
#defin
On 6/29/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 29, 2005 at 10:34:20AM -0700, Shaun Jackman wrote:
> > the statement expression macro? My best idea was to use alloca, but it
> > wouldn't look pretty. Can someone confirm that memory allocated with
On 6/29/05, Russell Shaw <[EMAIL PROTECTED]> wrote:
> Alloca is like creating a stack variable, except it just gives you some
> generic bytes that don't mean anything. Exiting the local scope will
> trash the local variables and anything done with alloca(). You'll need
> to store some information i
In a typical Ethernet/IP ARP header the source IP address is
unaligned. Instead of using...
out->srcIPAddr = in->dstIPAddr;
... I used...
memcpy(&out->srcIPAddr, &in->dstIPAddr, sizeof(uint32_t));
... to account for the unaligned destination. This worked until gcc 4,
which now gener
On 8/2/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> In order for anyone to answer your questions about the alignment of
> various types in a struct, don't you think you should perhaps have told us a
> little about what those types actually are and how the struct is laid out?
Of course, my apologie
On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> One of the things that continues to baffle me (and my colleagues) is
> the bizarre way in which attributes such as "packed" work when applied
> to structs.
>
> It would be natural to assume, as Shaun did, that marking a struct
> "packed" (or, for
On 8/2/05, Dave Korn <[EMAIL PROTECTED]> wrote:
> There are two separate issues here:
>
> 1) Is the base of the struct aligned to the natural alignment, or can the
> struct be based at any address
The base of the struct is aligned to the natural alignment, four bytes
in this case.
> 2) Is t
On 8/2/05, Joe Buck <[EMAIL PROTECTED]> wrote:
> I suppose we could make & on an unaligned project return a void*. That
> isn't really right, but it would at least prevent the cases that we know
> don't work from compiling.
That sounds like a dangerous idea only because I'd expect...
int
On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> It sounds like the workaround is to avoid memcpy, and just use
> variable assignment. Alternatively, cast the pointers to char*, which
> should force memcpy to do the right thing. Ugh.
I swear originally, back in the gcc 2.95 days, I used memcp
On 8/2/05, Paul Koning <[EMAIL PROTECTED]> wrote:
> It sounds like the workaround is to avoid memcpy, and just use
> variable assignment. Alternatively, cast the pointers to char*, which
> should force memcpy to do the right thing. Ugh.
Casting to void* does not work either. gcc keeps the alignm
On 8/2/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> operator. None of these examples produce an unaligned load:
I should clarify the wording I'm using here. By "an unaligned load" I
mean code to safely load from an unaligned pointer.
Cheers,
Shaun
On 8/3/05, Richard Henderson <[EMAIL PROTECTED]> wrote:
> It is nevertheless correct. Examine all of the parts of the expression.
>
> In particular, "&s->b". What type does it have? In an ideal world, it
> would be "pointer to unaligned integer". But we have no such type in
> our type system,
On 8/4/05, Carl Whitwell <[EMAIL PROTECTED]> wrote:
> Hi,
> thought I'd drop you a mail, would put it on gcc mailing list but
> haven't got time to work out how to send it there at this moment.
The gcc mailing list is [EMAIL PROTECTED]
> All testing here is done on x86 processors using g
On 8/5/05, Carl Whitwell <[EMAIL PROTECTED]> wrote:
> On 8/4/05, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> > Are you using an x86 host and an arm target?
>
> Actually no, my major concern at the time was the large quantity of
> legacy code with packed structures tha
The Debian HPPA buildd is failing with an ICE when building SwingWT
for the HPPA.
Here's the full build log:
http://buildd.debian.org/fetch.php?&pkg=swingwt&ver=0.87-2&arch=hppa&stamp=1126289145&file=log&as=raw
Here's the interesting line:
swingwtx/swing/JOptionPane.java:325: internal compiler er
The following code snippet produces code that loads a register, r5,
from memory, but never uses the value. The code is correct though, so
not a major issue. In addition, it never uses r3 or r12, which are
"free" registers, in that they don't have to be saved by the callee.
For a one line function t
Is it possible to disable the heuristic inline function logic? I would
like the following behaviour:
* static inline functions are always inlined
* non-static functions are never inlined
* static functions that are called once are inlined
* static functions that are called more than once are not i
2009/11/18 Shaun Jackman :
> Is it possible to disable the heuristic inline function logic? I would
> like the following behaviour:
>
> * static inline functions are always inlined
> * non-static functions are never inlined
> * static functions that are called once are inlined
&g
When assigning a bool to a single bit of a bitfield located in the
bit-addressable region of memory, better code is produced by
if (flag)
bitfield.bit = true;
else
bitfield.bit = false;
than
bitfield.bit = flag;
I've included a short test and
2009/11/28 Richard Guenther :
> On Sat, Nov 28, 2009 at 11:43 PM, Shaun Jackman wrote:
>> When assigning a bool to a single bit of a bitfield located in the
>> bit-addressable region of memory, better code is produced by
>> if (flag)
>> bitfield
2008/12/1 K.J. Kuan-Jau Lin(林寬釗) <[EMAIL PROTECTED]>:
> Hi Shaun,
>
> I have trouble in uClinux world.
> After long and painful debugging, i found it is due to the "R_ARM_GOTOFF32"
> relocation type.
> By google, i found you got the same problem before.
> (http://mailman.uclinux.org/pipermail/uclin
GCC reports an error for this snippet:
int main()
{
foo:
int x;
}
foo.c:4: error: expected expression before 'int'
... but not this snippet:
int main()
{
foo:
(void)0;
int x;
}
Is this expected behaviour? At the very least, it seems like an
unusual distinction.
Please
What optimisation option is needed to prod arm-elf-gcc -mthumb to
generate a tail call? ARM works as expected.
Please cc me in your reply. Thanks!
Shaun
arm-elf-gcc (GCC) 4.1.0
$ cat
The default -mpic-register (on ARM/Thumb) is r10. In -mthumb mode, r10
is not available to the math instructions as a direct argument. On top
of that, preserving r10 complicates the function prologue. Does it
make more sense to use a directly accessible register, r7 for example,
as the default -mp
On 6/26/06, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
As of gcc-4.2 it isn't fixed, it's just like any other pseudo generated
by the compiler.
Glad to hear it!
Thanks,
Shaun
I'm using MULTILIB_OPTIONS and MULTILIB_DIRNAMES to compile a PIC/XIP
toolchain. I'm familiar with the MULTILIB_EXCEPTIONS mechanism to
specify incompatible configurations. How, though, do I indicate that
msingle-pic-base depends on fPIC?
MULTILIB_OPTIONS+= fPIC
MULTILIB_DIRNAMES += pic
MUL
After I've modified the MULTILIB options in t-arm-elf, what's the
fastest way to test the new configuration without rebuilding the
entire toolchain? Right now the best method I have is `make clean-gcc
all-gcc', which is admittedly quite slow.
Please cc me in your reply. Thanks!
Shaun
On 26 Jun 2006 14:04:36 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> >
The usual hacked up way is to MULTILIB_EXCEPTIONS to remove
-msingle-pic-base without -fPIC. Something like
MULTILIB_EXCEPTIONS = -msingle-pic-base
might do it.
I tried your suggestion, but it didn't seem to have the desir
On 26 Jun 2006 14:42:20 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
No, that wouldn't work. MULTILIB_EXCEPTIONS takes a shell glob
pattern. It is invoked for each option set which is going to be
generated. I would expect that one of the option sets would be simply
"-msingle-pic-base".
On 6/26/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
Reading through gcc/genmultilib, it looks as though
MULTILIB_EXCLUSIONS can take a '!' parameter, but MULTILIB_EXCEPTIONS
cannot.
The solutions was to use MULTILIB_EXCLUSIONS!
MULTILIB_EXCLUSIONS += !fPIC/msingle-pic-base
On 6/26/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
After I've modified the MULTILIB options in t-arm-elf, what's the
fastest way to test the new configuration without rebuilding the
entire toolchain? Right now the best method I have is `make clean-gcc
all-gcc', which is
I'm attempting to build an XIP "Hello, world!" application for the ARM
processor. I'm compiling with -fPIC -msingle-pic-base with the default
-mpic-register=r10. The layout of the memory map is such that the
.text and .rodata are in flash memory, and the .got, .data and so
forth are loaded into RA
On 6/27/06, Erwin Authried <[EMAIL PROTECTED]> wrote:
Hi,
which compiler/binutil version did you use? Could you post the source
that you used?
One other thing (although that doesn't seem to have to do with your
problem): It is important that you use -fpic (not -fPIC) so that the
correct multilib
On 6/27/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
I'm attempting to build an XIP "Hello, world!" application for the ARM
processor. I'm compiling with -fPIC -msingle-pic-base with the default
-mpic-register=r10. The layout of the memory map is such that the
.tex
On 6/27/06, David McCullough <[EMAIL PROTECTED]> wrote:
Are you using the ld-elf2flt/elf2flt.ld combo ?
It lays things out in a known way and has a '-move-rodata' option which
will put the rodata in with the .text if it contains no relocation info
needed at runtime.
Something like this on the l
On 6/27/06, David McCullough <[EMAIL PROTECTED]> wrote:
AFAIK, you need to drop the -FPIC in favour of -fpic everywhere.
From the GCC manual, -fpic vs. -fPIC `makes a difference on the m68k,
PowerPC and SPARC.' For my purposes, it makes no difference on the
ARM.
You could try some experime
On 6/28/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
I have experimented with GCC 4.0.3, 4.1.0, and 4.1.1. I found that
4.1.x behave the same; however, GCC 4.0.3 does not emit GOTOFF32
relocations. Apparently these are a new feature and preferable in some
instances since they do redu
Hello Richard, Dan,
I'm trying to track down which part of the GCC source tree makes the
decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
reference to a static function. I thought there was a good chance one
of
On 6/28/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
GOTOFF support has been there for a long while. Only use of it for
static functions is recent. It should be easy to find. But this is
not at all the only problem. GCC's PIC model assumes a fixed
displacement between segments.
Even if
On 6/28/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Wed, Jun 28, 2006 at 03:17:30PM -0600, Shaun Jackman wrote:
> I'm not terribly familiar with the GCC source tree. I scanned
> config/arm/arm.c and its SVN log for changes that might affect
> GOTOFF32, but came u
On 6/28/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
It was probably me. But why can't you do this yourself? Look at the
assembly. See what the output string is. Search for it in
config/arm/. Use svn blame, as already suggested.
I did search the assembler text and found the constant an
On 6/29/06, Richard Earnshaw <[EMAIL PROTECTED]> wrote:
No, it was PhilB, but it must have been two or three years ago now.
Thanks, Richard. I suspect svn r71881 is responsible. I'll start
testing and hopefully put a patch together. I would suspect r49871,
but this patch is in 4.0.3, which does
Shaun
2006-06-29 Shaun Jackman <[EMAIL PROTECTED]>
* config/arm/arm.c (local_symbol_p): New function.
(legitimize_pic_address, arm_assemble_integer): Use it to prevent
GOTOFF relocations to the .text segment in execute-in-place code.
In
Any comments on this patch? This patch, or something like it, is
absolutely necessary to support execute-in-place (XIP) on uClinux.
Please cc me in your reply. Cheers,
Shaun
On 6/29/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
This patch forces the use of GOT relocations instead of GOTOF
Is it possible by hacking the specs file to change the target for
arm-elf-gcc from -marm to -mthumb? I tried a few obvious things like
changing marm in *multilib_defaults to mthumb, but this did not have
the desired effect.
Please cc me in your reply. Thanks!
Shaun
When -Ttext is used in combination with -mthumb it causes a relocation
truncated to fit message. What does this mean, and how do I fix it?
Please cc me in your reply. Thanks,
Shaun
$ arm-elf-gcc --version | head -1
arm-elf-gcc (GCC) 3.4.0
$ cat hello.c
int main() { return 0; }
$ arm-elf-gcc -Ttex
I have had no trouble specifiying the linker script using the -T
switch to gcc. I am now trying to specify the linker script from a
specs file like so:
%rename link old_link
*link:
-Thello.ld%s %(old_link)
gcc complains though about linking Thumb code against ARM libraries --
I've specified -mthu
> I did fix at least one bug, such that -Ttext does something useful with
> ELF toolchains, if your linker script it set up to use it. I think the
> ARM BPABI script may be the only one set up that way, though.
That would be excellent. I dislike having to read / modify / write
(read: fork) an exi
(cc'ing gcc@gcc.gnu.org)
On Nov 21, 2007 2:38 AM, Wouter van Gulik <[EMAIL PROTECTED]> wrote:
> Also consider the fuse bit get routine. This scheme gives more knowledge
> to the compiler, unfortunately gcc fails to see the loading of r31 can
> done once:
>
> using this:
>
> ===
Is it possible to disable the heuristic inline function logic? I would
like to select the following behaviour:
* all static inline functions are always inlined
* all static functions that are called once are inlined
(-finline-functions-called-once)
* no other functions are inlined
I'm using -Os a
Is there a switch to never inline a non-static function?
Thanks,
Shaun
On Dec 19, 2007 6:25 PM, Shaun Jackman <[EMAIL PROTECTED]> wrote:
> Is it possible to disable the heuristic inline function logic? I would
> like to select the following behaviour:
>
> * all static inline fu
61 matches
Mail list logo
