URL:
http://savannah.nongnu.org/bugs/?19050
Summary: gcrt1.S should call main rather than jumping to it
Project: AVR C Runtime Library
Submitted by: joerg_wunsch
Submitted on: Tuesday 02/13/2007 at 13:29
Category:
Update of bug #19050 (project avr-libc):
Priority: 5 - Normal = 9 - Immediate
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?19050
___
Follow-up Comment #1, bug #19050 (project avr-libc):
Call main() as a normal function have some drawback:
1. Loss of two bytes of RAM for storing 'main' return address in stack.
2. Increase code size, if 'main' function has local variables.
Now stack frames for 'main' function is setup by a
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Anatoly Sokolov
Sent: Tuesday, February 13, 2007 9:52 AM
To: Anatoly Sokolov; Joerg Wunsch; [EMAIL PROTECTED];
avr-libc-dev@nongnu.org
Subject: [avr-libc-dev] [bug #19050] gcrt1.S should
- Original Message -
From: Eric Weddington [EMAIL PROTECTED]
Sent: Tuesday, February 13, 2007 8:35 PM
Subject: RE: [avr-libc-dev] [bug #19050] gcrt1.S should call main rather
thanjumping to it
You make some very good points. Unfortunately, main() is already converted
over to a normal
-Original Message-
From: Anatoly Sokolov [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 13, 2007 11:32 AM
To: Eric Weddington; 'Joerg Wunsch'; Joerg Wunsch;
avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call
main rather thanjumping to it
-Original Message-
From: Joerg Wunsch [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 13, 2007 1:00 PM
To: avr-libc-dev@nongnu.org
Cc: 'Anatoly Sokolov'; Eric Weddington
Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call
main rather thanjumping to it
As Eric
All,
I'm not looking to do an avr-libc release soon, but I wanted to ask about
which version ought to be released next.
Should it be the 1.6 branch because of the new floating point library? I'm
thinking that that would be a very nice feature to release next.
No rush...
Eric Weddington
As Eric Weddington wrote:
Should it be the 1.6 branch because of the new floating point
library? I'm thinking that that would be a very nice feature to
release next.
I thought of releasing a snapshot from the development branch (1.5)
for the first time, so people could test the new FP
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Joerg Wunsch
Sent: Tuesday, February 13, 2007 1:55 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] Next release version
As Eric Weddington wrote:
Should it be the 1.6
Hello,
On Tue, Feb 13, 2007 at 10:35:41AM -0700, Eric Weddington wrote:
1. Loss of two bytes of RAM for storing 'main' return address
in stack.
True, but probably no big deal anymore - today, most interesting
devices have more RAM than the ones at the time when the original
decision was
5 instructions in prologue/epilogue, 0 ( 2 for 'i' ) RAM bytes used.
39 instructions in prologue/epilogue, 12( +2 for 'i') RAM bytes used.
I would prefer to correspond to 'C' standard completely, but we are
ready to pay such price, for that that function 'main()' to be callable?
I have a
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Joerg Wunsch
Sent: Tuesday, February 13, 2007 2:28 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call
main ratherthanjumping to it
As Anatoly
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
org] On Behalf Of Björn Haase
Sent: Tuesday, February 13, 2007 3:27 PM
To: avr-libc-dev@nongnu.org
Subject: Re: [avr-libc-dev] [bug #19050] gcrt1.S should call
main ratherthanjumping to it
For similar
I was under the impression that the main overhead could be eliminated via the
use of the naked and/or noreturn attributes. It seems to work in my own simple
tests; is this not the case?
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
As Eric Weddington wrote:
I'm sorry, could you clarify this? Are you suggesting that we will
have to *add* a command-line option to get the smaller code?
Yes, in the same sense as -mint8 produces smaller code when applied.
Except, -mno-mainframe causes way less portability issues.
Marek's
On Tue, Feb 13, 2007 at 02:36:54PM -0700, Eric Weddington wrote:
I agree completely: -mcall-prologues is still desired if it produces smaller
code.
OK, you may be right it still makes sense on the very small devices
(I don't have a strong opinion, just a suggestion), though it's still
possible
Follow-up Comment #2, bug #19050 (project avr-libc):
In oficial GCC 4.x main() do not converted to a normal function. 'atmega256'
patch does it.
For fast correction of a bug it is necessary to restore special handling of
main() funcion in 'patch-zz-atmega256x' patch.
These changes should be
As Anatoly Sokolov wrote:
These changes should be reverted:
- if (main_p)
-{
- fprintf (file, (\t
- AS1 (ldi,r28) ,lo8(%s - HOST_WIDE_INT_PRINT_DEC )
CR_TAB
- AS1 (ldi,r29) ,hi8(%s - HOST_WIDE_INT_PRINT_DEC )
CR_TAB
-
As Dean wrote:
I was under the impression that the main overhead could be
eliminated via the use of the naked and/or noreturn attributes. It
seems to work in my own simple tests; is this not the case?
See Marek's discussion about __C_task (or OS_task). In short, it's a
noreturn function that
- Original Message -
From: Joerg Wunsch [EMAIL PROTECTED]
As Anatoly Sokolov wrote:
These changes should be reverted:
- if (main_p)
-{
- fprintf (file, (\t
- AS1 (ldi,r28) ,lo8(%s - HOST_WIDE_INT_PRINT_DEC ) CR_TAB
- AS1 (ldi,r29) ,hi8(%s -
URL:
http://savannah.nongnu.org/bugs/?19055
Summary: Error with function eeprom_write_word
Project: AVR C Runtime Library
Submitted by: beaver_cavern
Submitted on: Tuesday 02/13/2007 at 23:58
Category: Library
22 matches
Mail list logo
