[avr-gcc-list] Incorrect code by gcc?

Hi, When developing an OS for the smallest Atmels (ATtiny861/461/21) i observed a strange effect. Sometimes, depending on the optimization choosen by gcc, the compiler generates code which cannot be correct (in my view). Most of the time the code is not functional too. The problem is that use of

Re: [avr-gcc-list] Incorrect code by gcc?

On Thursday 03 April 2008 00:27, Andy H wrote: > Not a bug Very good spotting. Andy! Thank you! Thats the reason i wanted it to post here before sending in a bug report. Unfortunately i already did so, so i marked the bug as INVALID now. The bugnumber was 35807 > According to the sources you pos

Re: [avr-gcc-list] Incorrect code by gcc?

r push/pop directly instead of a frame pointer? > best regards and hope tulips look good. / \ / \ / \ / \ || || || || \ / \ / \ / \ / || || || || || || || || || || || || Ruud. > Ruud Vlaming wrote: > > On Thursday 03 April 2008 00:27, Andy H wrote: > > > >> Not a bug >

Re: [avr-gcc-list] Incorrect code by gcc?

e language and i am programming the smallest avr, no bytes spoiled. I want to have control over the code, but i don't want to write bare assembler because it is so hard to maintain. It is a matter of taste i guess. Regards Ruud. > -Original Message- > From: Ruud Vlaming <

Re: [avr-gcc-list] gcc 4.3.0

Also, I get an average increase of the codesize (everything identical but the gcc version) of 5% moving from 4.2.3 to 4.3.0 (averiged over 12 projects, varying from 1% to 9%). I did not yet did research on the cause. Ruud. On Friday 11 April 2008 16:01, Klaus Rudolph wrote: > I have installed

Re: [avr-gcc-list] gcc 4.3.0

On Saturday 12 April 2008 21:19, Anatoly Sokolov wrote: > > Also, I get an average increase of the codesize (everything identical > > but the gcc version) of 5% moving from 4.2.3 to 4.3.0 (averiged > > over 12 projects, varying from 1% to 9%). I did not yet did research > > on the cause. > > T

Re: [avr-gcc-list] gcc 4.3.0

On Sunday 13 April 2008 23:53, you wrote: > On Sat, 12 Apr 2008 20:55:58 +0200, you wrote: > >Also, I get an average increase of the codesize On my 12 projects the results are: Compared between different compiles on 4.3.0 only > -fno-inline-small-functions > -fno-split-wide-types Both combined: be

Re: [avr-gcc-list] A Question Of Optmization

Yeah, I think it is not as strange as it might seem. If you say -O0 the compiler will do exactly what you asked him to do. And this is what you intended. But if you let the compiler optimize, it recognizes that your variable TimerTick is set to 10 and will never change. So it will just make sure

Re: [avr-gcc-list] A Question Of Optmization

Sorry, i meant first volatile unsigned char TimerTick; and then TimerTick = 10; Since you need the variable in the ISR routine. Ruud. On Tuesday 15 April 2008 20:12, Karl O. Feger wrote: > Dear all, > > I'm relatively new to AVR-GCC and try to do something, > > that is standing pro

[avr-gcc-list] the framepointer

Hi After my rather embarressing mistake accusing the gcc of buggy behaviour i tried to understand the way framepointers are implemented in the avr.c backend. I have a few questions and remarks, that may be helpfull to other with the same problems. First, I see in the avr.c a special handling fo

Re: [avr-gcc-list] the framepointer

On Saturday 19 April 2008 14:27, you wrote: > the source you refer to has assembler prolog/epilog. ie its old. Nice joke Andy. Sorry to say this, some of us still live in the stone age and use gcc 4.2.3 ;-) > The latest is written in RTL and does much better job of minimizing > the code. (I ha

Re: [avr-gcc-list] the framepointer

On Saturday 19 April 2008 23:26, you wrote: > The save around call will not use R18 upwards, > as these are call clobbered. You'r right. > Without studying source and compiler RTL and optimisation level used I > cannot say why it did not use a lower register. > It may be the cost assumptions

Re: [avr-gcc-list] the framepointer

l code ends up using r2829 - when gcc eventually > figures in the frame pointer - VERY FRUSTRATING > > It so happens I rewriting my prolog to properly allow no-frame-pointer, > regardless of stack slots. Not for you, but to avoid problems with new > IRA register allocator which may

[avr-gcc-list] Shorter code?

Hi Normally gcc generates well optimized code, but sometimes i wunder how gcc can do simple things so complicated. Here is an example, uint16_t genGetTickCount(void) { return (((uint16_t) uxTickCount.HighByte) << 8) | (uint16_t) (uxTickCount.LowByte) ; } generates 0768 : 768: 80 91 1d 0

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. Why > 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 ve

Re: [avr-gcc-list] (no subject)

Hi If i try (changed your code a bit to make it compile) #define mbitPatternPowerMode (7<<2) #define mADCNoiseReduction 0x20 #define mbitSleepMask 0x04 void Test_MCUCR(void) { MCUCR=(MCUCR&(~mbitPatternPowerMode))|(mADCNoiseReduction|mbitSleepMask); } I get the same result. If you ho

Re: [avr-gcc-list] Eclipse, avarice, JDB usage?

Hi DLC, > No one on AVR-chat appears to use avarice, avr-gcc and Eclipse. All > are using AVR studio or nothing at all for debugging. SO, my question > to this group is. How? Does anyone have any experience using the > following nifty tools all together? I use Eclipse (on linux), and gcc+

[avr-gcc-list] Howto I/O in asm instructions?

Hi, There are a couple of ways to use i/o address in assymbly. Below i used a some: #define _EEARL_ "0x1E" uint8_t portFSReadByte(unsigned char * pAddress) { uint8_t result; asm volatile ( \ "in r26, __SREG__ \n\t" "cli \n\t" "out %2, %A0\n\t

Re: [avr-gcc-list] Howto I/O in asm instructions?

On Thursday 03 July 2008 08:43, Wouter van Gulik wrote: > Ruud Vlaming schreef: > > (2) You can use the asm paramter list, like for EEARH ... > You could go for option 2 if you use syntax like this > http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Extended-Asm.html That is indeed

Re: [avr-gcc-list] # in #define

On Wednesday 09 July 2008 16:57, Arkadiusz Krysiak wrote: > Know anyone metod to place in body definition sign "#" ? > i need to make definition like to this: > #define name(x,y) #define #x #y Apart from the fact that this group is not the right one to ask this question (it' a general preprocesso

[avr-gcc-list] Typo in iotnx61.h?

Just for the record, i think there is a typo in the file: avr-libc-1.6.2/include/avr/iotnx61.h #define TCCR0B _SFR_IO8(0x33) #define CS000 #define CS011 #define CS022 #define PSR03 #define TMS 4 the last line should read #define TSM 4 I searched for it in the bug-data

[avr-gcc-list] cbr and negative numbers

Suppose you compile the (nonsense) code below under 'standard' settings (see below for my settings, but is does not really matter for now) Then there is no problem. However, if you activate the 8 bit integer option -mint8 you get an error: code_Test.s:75: Error: number must be less than 256

Re: [avr-gcc-list] cbr and negative numbers

On Wednesday 10 September 2008 16:01, you wrote: > > > -Original Message- > > However, if you activate the 8 bit integer option -mint8 > Full halt. > > -mint8 is not really supported. Yes, we know it causes all sorts of > problems. It should never be used. I'd really like to see it ripp

Re: [avr-gcc-list] Re: cbr and negative numbers

On Wednesday 10 September 2008 23:15, David Brown wrote: > Have you tried using "M" as the constraint rather than "i" ? I haven't > tried this myself, but according to > "M" is an > 8-bit integer constant in the range 0 to 255. Tha

Re: [avr-gcc-list] cbr and negative numbers

On Wednesday 10 September 2008 23:45, Weddington, Eric wrote: > But I highly doubt that the other developers are going to fix a problem > that only shows up with -mint8. Yeah, you are correct. And if i mange to dive into the problem and fix it myself (which i doubt i can) the patch would proba

Re: [avr-gcc-list] Re: cbr and negative numbers

On Thursday 11 September 2008 16:19, you wrote: > > Now i don't know of any instruction that takes an immediate 16 bit > operand, but still. > > CALL (takes 2-byte operand on most AVRs, 3-byte operand on avr6 > (m2560/1) > JMP  (takes 2-byte operand on most AVRs, 3-byte operand on avr6 > (m2560/1

Re: [avr-gcc-list] cbr and negative numbers

On Thursday 11 September 2008 22:55, Joerg Wunsch wrote: > If you've got a patch that doesn't break anything else (in particular > in non-mint8 land), I think it has a real chance of being > incorporated. Otherwise, it will be tough. Of course, that goes without saying. Maybe i have a look afte

Re: [avr-gcc-list] cbr and negative numbers

On Friday 12 September 2008 17:19, Gre7g Luterman wrote: > > So have a look at my OS for the AVR, sources included (GPLv3) > > http://www.femtoos.org/ > > ;-) > > There's an OS for the AVR? It is for the AVR but at this moment there is only one port, for the ATtiny861,461,261 The OS is complete

Re: [avr-gcc-list] cbr and negative numbers

On Friday 12 September 2008 20:17, Stu Bell wrote: > > Is it stable yet? > > Check the Tutorials forum on avrfreaks.net -- there's a thread with a > pile of Oses for AVRs of all flavors. Hmm, i had better called mine YAVTROS - Compact form for: Yet Another AVR Real Time OS ;-) But i didn't, beca

Re: [avr-gcc-list] cbr and negative numbers

On Friday 12 September 2008 21:53, Pink Boy wrote: > As an aside, Freertos was just getting underway when I started > using AVRX, but is now much more widely supported and mature now. FreeRTOS is very good, and i ported it (for own use) to the ATtiny861. It runs perfectly, but is to large for an

[avr-gcc-list] Transfer bit conserved by gcc?

It is hard to find an awnser to the following question by google, so lets post it here. Is it true that avr-gcc never produces code that makes explicit use of the T-bit? In other words, can i presume the T-bit is conserved over any function call when the assembly was generated entirely by gcc, i

Re: [avr-gcc-list] Transfer bit conserved by gcc?

On Friday 19 September 2008 16:25, you wrote: > > > Is it true that avr-gcc never produces code that makes > > explicit use of the T-bit? > > No. > In GCC 4.3.2, in the machine description for the avr > (gcc/config/avr/avr.md), there is define_insn "abssf2" > that will use the T bit. It gener

Re: [avr-gcc-list] Transfer bit conserved by gcc?

On Saturday 20 September 2008 12:37, you wrote: >> The md file states: >> >> (define_insn "abssf2" >> [(set (match_operand:SF 0 "register_operand" "=d,r") >> (abs:SF (match_operand:SF 1 "register_operand" "0,0")))] >> "" >> "@ >> andi %D0,0x7f >> clt\;bld %D0,7" >> [(set_at

Re: [avr-gcc-list] Transfer bit conserved by gcc?

On Sunday 21 September 2008 00:32, Ruud Vlaming wrote: > Since this is the only place where the T bit is used, it seems > a sensible thing to do and it gives control of that bit back > to the assembly programmers. Well actually it is not, the other place i found is define_insn "

Re: [avr-gcc-list] Transfer bit conserved by gcc?

On Sunday 21 September 2008 10:42, Anatoly Sokolov wrote: > fplib in avr-libc use T bit. atoi, atol, itoa ltoa and > vfprintf (__ultoa_invert) functions use T bit also. Hmm, it is clear that even if these functions can be recoded not to use the T bit, which is at least for some if not all possib

Re: [avr-gcc-list] Transfer bit conserved by gcc?

On Sunday 21 September 2008 22:22, you wrote: > T-bit is used by avr-gcc for internal purpose, the same way as temp reg (r0) > and cannot be used for storing value. I see. I looked at it and i cannot get clear in which circumstances, this is, but it does not really matter i suppose. Point is, you

[avr-gcc-list] $DATA_ORIGIN in binutils-2.18

Just to let you know, binutils-2.18/ld/scripttempl/avr.sc reads [ http://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.bz2 ] MEMORY { text (rx) : ORIGIN = 0, LENGTH = $TEXT_LENGTH data (rw!x) : ORIGIN = 0x800060, LENGTH = $DATA_LENGTH eeprom (rw!x) : ORIGIN = 0x81, LENGTH = 64K } So

Re: [avr-gcc-list] $DATA_ORIGIN in binutils-2.18

10:45, Ruud Vlaming wrote: > Just to let you know, binutils-2.18/ld/scripttempl/avr.sc reads > [ http://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.bz2 ] > > MEMORY > { > text (rx) : ORIGIN = 0, LENGTH = $TEXT_LENGTH > data (rw!x) : ORIGIN = 0x800060, LENGTH = $DATA_

Re: [avr-gcc-list] Pre-prologue and post-epilogue asm code insertion?

On Tuesday 21 October 2008 03:55, Mark Litwack wrote: > Is there an easy way to insert a few lines of asm code in an > ISR before the prologue starts (at the ISR entry) and then > some additional code after the epilogue (right before the > RETI)? I had a similar challenge and there are three 'sol

Re: [avr-gcc-list] $DATA_ORIGIN in binutils-2.18

On Monday 20 October 2008 21:26, Weddington, Eric wrote: > It's probably easier if you get your patches from WinAVR CVS... :-) Thanks for the tip. So easy, and i was not aware of that. Maybe because i am a little to WinShy i guess ... Anyway, let me share, just for the record, what i found. (1)

[avr-gcc-list] minit-stack

On gcc 4.2.3 it was possible to use something like -minit-stack="xOS+xOSstackShift" as compiler option. where xOS is an array or structure, and xOSstackShift a constant number to be defined by asm(".set xOSstackShift, " DefToString(OSstackInit) " \n\t "); This way it is possible to let

Re: [avr-gcc-list] minit-stack

On Wednesday 22 October 2008 17:00, you wrote: > > > -Original Message- > > From: > > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > org] On Behalf Of Ruud Vlaming > > Sent: Wednesday, October 22, 2008 2:40 AM > > To: avr-gcc-list@nongn

Re: [avr-gcc-list] $DATA_ORIGIN in binutils-2.18

On Wednesday 22 October 2008 16:41, Weddington, Eric wrote: > If you are trying to build a newer toolchain, then I have a different set of > patches for you. :-) I'm working on the next release of WinAVR, which > will include binutils 2.19 (not yet released, but the latest snapshot is > 2.18.9

Re: [avr-gcc-list] minit-stack

On Thursday 23 October 2008 07:25, Joerg Wunsch wrote: > > On gcc 4.2.3 it was possible to use something like > > > > -minit-stack="xOS+xOSstackShift" > > While -minit-stack used to be documented (but deprecated, as you > already noticed), the option to perform calculations in its value was >

Re: [avr-gcc-list] minit-stack

On Wednesday 22 October 2008 10:39, Ruud Vlaming wrote: > -Wl,--defsym=__stack=xOS+xOSstackShift > However, that trick does not longer functions. Got it. This trick does function if you leave the quotes out, so -Wl,--defsym=__stack="xOS+xOSstackShift" is wrong and -Wl,--de

Re: [avr-gcc-list] minit-stack

On Thursday 23 October 2008 12:05, Joerg Wunsch wrote: > Ruud wrote: > > >This trick does function if you leave the quotes out, so > >-Wl,--defsym=__stack="xOS+xOSstackShift" is wrong and > >-Wl,--defsym=__stack=xOS+xOSstackShift is correct. > > Is this under Win32? Normally, the Unix shell remo

[avr-gcc-list] avrdude on cygwin

I have a problem compiling the avrdude 5.5 on the latest cygwin. With ../avr-libc-$LIBC_VERSIE/configure --prefix=$PREFIX --build=`../avr-libc-$LIBC_VERSIE/config.guess` --host=avr make && make install it returns (after some work) with: In file included from lexer.c:990: /usr/lib/gcc/i686-pc

Re: [avr-gcc-list] avrdude on cygwin

On Wednesday 19 November 2008 22:44, Joerg Wunsch wrote: > Does the patch below make it compile? Yes it does, with: Hunk #1 succeeded at 355 with fuzz 2 (offset -19 lines). Hunk #2 succeeded at 388 with fuzz 2 (offset -19 lines). Very good, since this compiles for linux and cygwin alike (tested b

Re: [avr-gcc-list] Add 'OS_main' and 'OS_task' attributes in avr-gcc 4.2.1

On Tuesday 09 December 2008 14:39, Bob Paddock wrote: > I had hoped that using OS_main would get rid of the call to main, > wastes stack space, and all of the dead _exit code, which is not allowed > under some design guidelines (as well as taking space), that will > never be executed, but it doesn

Re: [avr-gcc-list] How to do context saving manually in ISR(__vector_name)

Hi Lin Maybe it is an idea to try the OS_task attribute instead of naked. __attribute__ (( OS_task )) I did not try it for ISR but for standard methodes is does just that, it makes it naked, but creates a stack frame when needed. If you cannot use it on an interrupt handler directly, just mak

Re: [avr-gcc-list] Using __tmp_reg__ etc in assembly file

On Wednesday 21 January 2009 23:09, Colin Wall wrote: > I know I can always do my own #define, but it feels wrong to re-define > something that already exists... You can make use of the constructions (examples): out (_SFR_IO_ADDR(SREG)), r25 out (_SFR_IO_ADDR(SPL)), r26 out (_SFR_

[avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

Hi, I don't think it was mentioned here yet, so please know that, when you try to build avr-libc-1.6.4 with the patches, 30-avr-libc-1.6.4-dwarf2.patch 31-avr-libc-1.6.4-builtins.patch 40-avr-libc-1.6.4-fix-attiny13a-arch.patch applying the last patch results in an error when building cd avr

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Tuesday 27 January 2009 01:25, you wrote: > Oh, of course, I do that too. Thanks for mentioning that. Things that have been automated have a tendency to be forgotten. However, that is not always wise, for the bootstrap script seems to have a flaw i think. It checks for the version numbers 2.

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Tuesday 27 January 2009 01:19, Timo Sandmann wrote: > Am 26.01.2009 um 23:50 schrieb Ruud Vlaming: > > config.status: error: cannot find input file: avr/lib/avr25/ > > attiny13a/Makefile.in > I used the bootstrap-script to let automake generate the missing > Makefile.i

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Thursday 29 January 2009 05:54, you wrote: > Yes, the version checking in the bootstrap script is > quite stupid. Right now it looks for specific versions only. > It would be ideal if we could look for a range. > > > The question is: is this really needed? Can the > > script not simply issu

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

onfigure script. # -# autoconf-2.59, 2.60, 2.61, or 2.62 is required +function version() +{ # Simple version normalizer by Ruud Vlaming (r...@betaresearch.nl) + echo $1 | sed -e 's/$/ /' -e 's/^/ /' \ +-e 's/^.*[v ]\([0-9]\)\.\([0-9].*\)$/ 0\1.\2 /' \ +-e

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Friday 30 January 2009 18:21, Weddington, Eric wrote: > > Here it is. I added some sed hocus-pocus to normalize the version > > numbers before comparisson. It is NOT bullit proof, but it handles > > one and/or two digit, possibly mixed, version numbers of two and/or > > three levels, possibly

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Friday 30 January 2009 19:08, Weddington, Eric wrote: > Since you are an avr-libc developer (with commit privledges) > you need to subscribe to the avr-libc-dev list. I did, but somewhere in the line it takes time. > > Please realize that this kind of approach is highly sensitive > > to the

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Sunday 01 February 2009 17:19, you wrote: > > > I'm ok with say that we require some verion >= X. Anything > > < X should fail. Anything >= X should be allowed. With X > > being the lowest version that we check for. > > > > Test for autoconf min version alredy present in "configure.ac": > > 3

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Sunday 01 February 2009 18:53, Weddington, Eric wrote: > > > -Original Message- > > From: Ruud Vlaming [mailto:r...@betaresearch.nl] > > Sent: Sunday, February 01, 2009 9:47 AM > > To: Weddington, Eric; Joerg Wunsch; Anatoly Sokolov > > Cc: avr-gc

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Sunday 01 February 2009 23:25, you wrote: > > > -Original Message- > > From: Ruud Vlaming [mailto:r...@betaresearch.nl] > > Sent: Sunday, February 01, 2009 2:36 PM > > To: Weddington, Eric > > Cc: avr-gcc-list@nongnu.org > > Subject: Re: [a

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Monday 02 February 2009 00:51, Timo Sandmann wrote: > > Am 01.02.2009 um 23:46 schrieb Ruud Vlaming: > >> Users are supposed to download the official releases here: > >> <http://download.savannah.gnu.org/releases-noredirect/avr-libc/> > >> and use t

Re: [avr-gcc-list] no avr/lib/avr25/attiny13a/Makefile.in

On Monday 02 February 2009 13:53, you wrote: > When I applied the xmega-patches to binutils 2.19, the build-process > failed: > ../../binutils-2.19/bfd/elf32-avr.c: In function > 'bfd_elf_avr_final_write_processing': > ../../binutils-2.19/bfd/elf32-avr.c:1331: error: 'bfd_mach_avrxmega1' > u

Re: [avr-gcc-list] Code optimistaion in AVR Tiny13

On Monday 16 February 2009 15:11, Robert von Knobloch wrote: > On inspection I find that the compiler has 'in-lined' at least 3 > function calls that I had written as a function to achieve compactness. > Is there any way I can stop this, or is this a bug? There has been some discussions about thi

Re: [avr-gcc-list] How to force GCC to not to remove "nop" statements ?

On Thursday 19 February 2009 19:01, Vincent Trouilliez wrote: > I made a few trials. It appears that up to and including 3 nop > statements, GCC leaves them alone. But if I put 4 of them, it removes > them all ! Are you absolutely sure they are really left out? I assume they are just not shown i

Re: [avr-gcc-list] introducing a new section in data memory

On Friday 20 February 2009 19:41, Weddington, Eric wrote: > Attachment error. Trying again for the list. Just to inform you, the first post contained readable and correct attachments, whereas the second one needs manual uudecoding. I saw this before on your posts. Somehow it seems posts appear

Re: [avr-gcc-list] avr-ld on Windows crashes with -relax

On Tuesday 24 February 2009 05:29, Jim Brain wrote: > WinAVR 20081205 in use. > > I have an app that, if I use: > > LDFLAGS += -Wl,-O9,-relax > > avr-ld dies during link. If I take off -relax, as is well. I think this is a bug. Try: -Wl,--gc-sections -Wl,--relax instead of your options.

Re: [avr-gcc-list] avr-ld on Windows crashes with -relax

On Wednesday 25 February 2009 06:43, you wrote: > Ruud Vlaming wrote: > > On Tuesday 24 February 2009 05:29, Jim Brain wrote: > > > >> WinAVR 20081205 in use. > >> I have an app that, if I use: > >> LDFLAGS += -Wl,-O9,-relax > >> avr-ld

Re: [avr-gcc-list] Re: How to force GCC to not to remove "nop" statements ?

On Friday 06 March 2009 01:34, Gene Smith wrote: > Vincent Trouilliez wrote: > > On Thu, 19 Feb 2009 11:14:40 -0700 > > "Weddington, Eric" wrote: > > > >> If you are using WinAVR 20081205 then you can use one of the new builtin > >> functions: > >> void __builtin_avr_delay_cycles(unsigned long _

Re: [avr-gcc-list] Building AVR-Toolchain

On Monday 04 May 2009 11:36, B.A.f.H. wrote: > Hello, > I'm new to compiling avr-gcc-compiler. I would develop code > for the TinyOS project, but the used compiler in the project > doesn't support my mikrocontroller (Atmel atmega1284p). > So I have to build an new toolchain. I would build the av

Re: [avr-gcc-list] Building AVR-Toolchain

On Monday 04 May 2009 13:58, B.A.f.H. wrote: > thanks, but I have another problem, the computer for developing has > no internet connection and for the computer with internet connection, > I have no admin-privileges. I see. Indeed the script starts with downloading the required files. Now, i d

Re: [avr-gcc-list] Building AVR-Toolchain

On Friday 08 May 2009 13:52, you wrote: > I've tried to build the new toolchain with rpmbuild, see the spec-files in > the attachement. > I oriented myself to your script. I used the newest cgywin setup.exe with the > newest > packages and the toolchain test was passed with no errors. > The b

Re: [avr-gcc-list] Building AVR-Toolchain

On Friday 08 May 2009 15:26, you wrote: > > - i see no file for the patches for bin-utils. thanks, they look fine. > Sorry, in the attachement is the missing file. > > > - i am unfamiliar with 50-avr-libc-fixversion.patch > > (it was not included in my toolchain, what was that again?) > > I'm

Re: [avr-gcc-list] char to int promotion in bitwise operators

I think it is about time that the compiler is extended with a possibility to work with 8 bit integers in a native way. (like it was extended to read the 0b101010 format) If gcc can calculate with integers of 16, 32 and 64 bits wide why not 8, the mother of all integers? A second best would be a s

Re: [avr-gcc-list] char to int promotion in bitwise operators

On Friday 21 August 2009 23:06, Weddington, Eric wrote: > > On Behalf Of Ruud Vlaming > > > > I think it is about time that the compiler is extended > > Patches welcome. Yes Eric, i was waiting for that response ... it took you just over an hour ;-) I have looked into

[avr-gcc-list] zero length array in nocommon

Hi, I noticed a strange behaviour when you place a zero length array in 'nocommon'. For example, if you use something like const unsigned char TEST_C[0]; it compiles (assuming NO settings like -ffunction-sections -Wl,--gc-sections -Wl,--relax) to *(COMMON) COMMON0x0080007e

Re: [avr-gcc-list] zero length array in nocommon

On Wednesday 23 September 2009 21:14, Joerg Wunsch wrote: > Ruud Vlaming wrote: > > > I noticed a strange behaviour when you place a zero length array in > > 'nocommon'. > > No idea why the behaviour changes, but as a note of warning: a > zero-length a

Re: [avr-gcc-list] zero length array in nocommon

On Thursday 24 September 2009 06:20, Joerg Wunsch wrote: > Ruud Vlaming wrote: > In your case, I'd revert the code to the portable #ifdef. I did. No choice right :-( > > Anyway, you're right, as long as GCC claims support for it, it ought > to work, so you might con

Re: [avr-gcc-list] zero length array in nocommon

On Thursday 24 September 2009 04:14, you wrote: > ... and just learn to read code with #ifdefs. A bit of indentation usually > helps. ;-) Surely you're joking right? ;-) My work on Femto OS was subject of a research paper [1] which discussed that heavy use of preproccessor directives is not neces

Re: [avr-gcc-list] Re: zero length array in nocommon

On Thursday 24 September 2009 10:51, David Brown wrote: > As shown by the link you gave, zero-length arrays are only really valid > when they are the last element in a struct (they can be very useful there). I cannot read any restrictions on the use of zero-length arrays. It states "Zero-length a

Re: [avr-gcc-list] Optimization - what is bad on this code ?

On Sunday 04 October 2009 22:34, Carl Hamilton wrote: > I can't say why the compiler has thrown out their bodies (I haven't looked > at the code that closely), but the "while" loops in both functions will > never exit. Well that is enough reason for the compiler to throw away the bodies. If a func

Re: [avr-gcc-list] Re: Optimization - what is bad on this code ?

On Monday 05 October 2009 09:53, David Brown wrote: > Ruud Vlaming wrote: > > Give it a try. > > Your explanation is correct (and the 8/16-bit issue explanation was > particularly nice), but your advice at the end is not. Although that is a matter of taste, this was meant

Re: [avr-gcc-list] Unused registers?

Hi Tomas, In general it is very hard to force gcc to utilize all registers or particular registers. And if you succeed, observe that in most of the times it results in extra mov's, so it does not tend to reduce code. One exception is with framepointers. Gcc should avoid framepointers if you asked

Re: [avr-gcc-list] assembly-c mix and interrupts

Your description is rather vague, but in any case i would say that at interrupt you should save everything you make use of in your routine. It seems to me that it is very unlikely that you do not make (indirect) use of the SREG. Thus you have to save (and restore!) it. From experience i can say t

Re: [avr-gcc-list] AVR environment on Solaris 10

On Tuesday 01 December 2009, Andreas Höschler wrote: > I am trying to setup an AVR development environment > on my Solaris 10 machine as follows: You can give my toolchainbuilder a try. Although it is not tested on Solaris, it runs on gentoo, Ubuntu, macos windows with cygwin, and probably other

Re: [avr-gcc-list] AVR environment on Solaris 10

Hi Anreas, Thank you for trying. This seems not to encouraging. But, at least this tool tests before it runs into unclear errors... ;-) Let me remark, that some of those tools are not specially needed by my builder, but more for the build process itself, which may not be as appearent as it may s

Re: [avr-gcc-list] PLease help wtih a correct code

Shall I write your thesis too? Ruud On Sunday 28 February 2010, Jeano Kalawa wrote: > Hallo everbody. >   > I am working with my final prosject at University. I work with a SHT  75 > sensirion sensor to measure temperature and humidity. I use an ATmega 32 > controller and have to send data to a

Re: [avr-gcc-list] WinAVR discontinued ?!?!?

On Monday 07 June 2010, Bernard Fouché wrote: > It's still tricky to have WinAVR quality on Linux, I hope the next > tool/organization will also package a WinAVR quality gcc for Linux... Indeed, for my toolchain builder (usable for Linux, Windows and Mac OS alike) i also use the WinAVR patches. V

Re: [avr-gcc-list] crosstool-NG

On Friday 04 March 2011, Bernard Fouché wrote: > Making all of our AVR code on Linux, I used to download WinAVR to > rebuild a toolchain on Linux, knowing the result would work. Now the > only solution is to go for Bingo600's scripts... That is not entirely true. You can also use my toolchainbu

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

On Thursday 12 January 2012, Weddington, Eric wrote: > The problem that I have with -mint8 is: > - it doesn't follow the standard > - it breaks avr-libc (or rather, avr-libc isn't adapted to it) > - people use it, because the backend hasn't been taught how to do the > right thing. > > The thing is

Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefsareincorrect

> > The problem i have with the standard C is that it lacks a > > proper 8 bit arithmetic. That is why -mint8 comes in so > > handy, and produces very compact code. In many > > cases 8 bit are more than enough to do the job, but within > > the standard you are enforced to use a char (!) for nu

[avr-gcc-list] gcc 4.7 changes

On http://gcc.gnu.org/gcc-4.7/changes.html i saw some very interesting changes listed regarding the AVR. I did not have the time yet to see what it results in, but i am very curious about other experiences. Ruud ___ AVR-GCC-list mailing list AVR-GCC-

Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table down to last used entry

I think this is a nice feature, and i see no harm. At some projects i also put code in the vector table to save space. As others have pointed out, developers should know what they are doing, which is the case with many other compiler switches as well. Also, i do not find the name less cryptic