[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] How to use pgmspace.h in a library source without war
Re: [avr-gcc-list] How to use pgmspace.h in a library source without warning?
Tue, 11 Jun 2013 14:28:21 +0200
Thunderbird 18.104.22.168 (Windows/20100228)
Weddington, Eric schrieb:
-----Original Message----- From: Georg-Johann Lay
[mailto:address@hidden Sent: Saturday, June 08, 2013 6:36 AM To:
Weddington, Eric Cc: Thomas D. Dean; address@hidden
Subject: Re: [avr-gcc-list] How to use pgmspace.h in a library
source without warning?
Weddington, Eric wrote:
computers get faster every year
Computers don't get faster.
It's just the case that the not-so-fast computers are declared as
scrap, and thrown away an then replaced by a-bit-faster computers;
again and again and again...
Pedantically, yes. That's what I was referring to.
I don't think that things should get more complicated and more
resource gulping -- in the contrary: things should get easier to
grasp and to handle and to understand.
In a way, lib/device would actually be simpler then lib/arch. When a
user compiles a program, they compile it for a specific device, not
an architecture. Then the library for the architecture gets linked
The only thing that I see that gets complicated is transitioning from
one style to the other, and then the increase in compilation.
Just perform the following 2 steps:
1) Make AVR-LibC adopt avr-gcc's multilib layout.
Currently, we have
$ avr-gcc -print-multi-lib
2) Change avr-gcc's multilib layout to whatever you want.
Notice that this fixes #35407 (add tiny-stack multilibs).
Again, I see it being offset by being able to build on newer, faster
computers and by building in parallel. Will it be completely offset?
No, of course not. But then we can really design libraries to be
specific to devices and get rid of some of the kludges and
compromises that are in there in building it per arch.
we just had the request to (effectively) raise -Os to a multilib option.
That way the libraries can be tailored for small code or for fast code.
And there was the request to raise -f[no-]short-double to a multilib
option so that double can be 32 or 64 bits wide.
That would flood us with ~800 multilibs. Arrgh.