[Top][All Lists]

[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

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] How to use pgmspace.h in a library source without warning?
Date: Tue, 11 Jun 2013 14:28:21 +0200
User-agent: Thunderbird (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 in.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]