r-gcc-list@nongnu.org
> Subject: Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table
> down to last used entry
>
> > With that, it's straight forward to accomplish a small vector table:
> >
> > Just -nostartfiles, add gcrt1.S to the project and define
> _VE
On Fri, Mar 01, 2013 at 04:05:53PM +0100, Georg-Johann Lay wrote:
> Senthil Kumar Selvaraj wrote:
>
> >> Granted, the (saved memory) reward for the effort is small, but if the
> >> user would specify the number of the highest used vector, then gas
> >> conditional assembly, in a "bad vector" macro
r-gcc-list@nongnu.org
> Subject: Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table
> down to last used entry
>
> Senthil Kumar Selvaraj wrote:
>
> >> Granted, the (saved memory) reward for the effort is small, but if
> the
> >> user woul
Senthil Kumar Selvaraj wrote:
>> Granted, the (saved memory) reward for the effort is small, but if the
>> user would specify the number of the highest used vector, then gas
>> conditional assembly, in a "bad vector" macro does handle the task:
>
> Ah, but right now, the vector table is defined i
On Sat, Feb 16, 2013 at 10:09:08PM +1100, Erik Christiansen wrote:
> TL;DR: There is a workaround at the end. Is its lower intrusiveness
>better balanced against the small optimisation, than the
>binutils tweak which provides full automation? Whatever. ;-)
>
> On 15.02.13 15:41, Se
TL;DR: There is a workaround at the end. Is its lower intrusiveness
better balanced against the small optimisation, than the
binutils tweak which provides full automation? Whatever. ;-)
On 15.02.13 15:41, Senthil Kumar Selvaraj wrote:
> On Fri, Feb 15, 2013 at 08:31:42AM +0100, Georg
Ruud Vlaming wrote:
> 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.
Well, personally, I think it's a micro optimization that is only
needed in some rare cases, when one really cares for the last 50 bytes
of flash. (What'
On Fri, Feb 15, 2013 at 08:31:42AM +0100, Georg-Johann Lay wrote:
> Senthil Kumar Selvaraj wrote:
> >
> >Like the others said, the patch does not change the default behavior
> >for unhandled interrupts - they still branch to __bad_interrupt. The
> >user would have to explicitly use the --shrink-iv
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
Senthil Kumar Selvaraj wrote:
Like the others said, the patch does not change the default behavior
for unhandled interrupts - they still branch to __bad_interrupt. The
user would have to explicitly use the --shrink-ivt option to change
that - at which point, I guess he should be knowing what he
On Thu, Feb 14, 2013 at 10:38:11PM +0530, Weddington, Eric wrote:
> Hi All,
>
> I open to suggestions on such a feature, but let's talk about it in AVR
> community first and leave the binutils mailing list out of it until we arrive
> at a consensus.
>
Like the others said, the patch does not c
Weddington, Eric wrote:
> I open to suggestions on such a feature, but let's talk about it in AVR
> community first and leave the binutils mailing list out of it until we
> arrive at a consensus.
Agreed, in general it is not helpful to cross-post several mailing lists.
Johann
__
2013/2/14 Weddington, Eric :
> If this "optimization" were put in place, then there is the potential
> that these wrongly-enable interrupts could vector off to some part of the
> application code,
> start executing it, without ever having a return from interrupt (RETI), and
> could wreak havoc
>
3 9:59 AM
> To: Weddington, Eric
> Cc: Selvaraj, Senthil_Kumar; binut...@sourceware.org; avr-gcc-
> l...@nongnu.org; Wunsch, Joerg
> Subject: Re: [avr-gcc-list] [Patch, avr] Shrink interrupt vector table
> down to last used entry
>
> Weddington, Eric wrote:
> >
> > Senthil
Weddington, Eric wrote:
>
> Senthil_Kumar Sent:
>>
>> Hi,
>>
>> This patch tries to shrink the interrupt vector table by deleting unused
>> entries at the end of the table as part of linker relaxation.
>>
>> The motivation for this patch is that, currently, the full interrupt
>> vector table
> -Original Message-
> From: Selvaraj, Senthil_Kumar
> Sent: Thursday, February 14, 2013 3:48 AM
> To: binut...@sourceware.org
> Cc: avr-gcc-list@nongnu.org; Weddington, Eric; Wunsch, Joerg
> Subject: [Patch, avr] Shrink interrupt vector table down to last used
> entry
>
> Hi,
>
> This
Hi,
This patch tries to shrink the interrupt vector table by deleting unused
entries at the end of the table as part of linker relaxation.
The motivation for this patch is that, currently, the full interrupt
vector table is being placed in the linked executable, regardless of the
number of inter
17 matches
Mail list logo
