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

[Weddington, Eric]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Georg-Johann Lay
> Sent: Friday, March 01, 2013 8:06 AM
> To: Selvaraj, Senthil_Kumar
> Cc: address@hidden
> 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 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 in avr-libc
> > (crt1/gcrt1.S) and gets built into crtxxx.o at avr-libc build time.
> It
> > is then linked into the final executable automatically by the gcc
> > driver. I guess that rules out conditional assembly?
> 
> It is reasonable that gcrt1.S is contained in a distribution so that
> users can
> assemble an use it directly.  There's already an issue for this:
> #38125.
> 
> http://savannah.nongnu.org/bugs/?38125
> 
> With that, it's straight forward to accomplish a small vector table:
> 
> Just -nostartfiles, add gcrt1.S to the project and define
> _VECTORS_SIZE.
> 
> That way it is flexible and freely adjustable without binutils hacks.


I would prefer the method that Johann outlined above, if someone wants to 
actually do this. (Thanks, Johann, for bringing this up!)

It's mostly going to be advanced users who will want and/or need such a 
micro-optimization. And advanced users will able to do the above method fairly 
easily.

Overall, I think that this kind of optimization is too risky for the little 
gain they will achieve. But who am I to stop someone from making stupid 
decisions? ;-)

Eric