avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] FAQ (was: strange behaviour with ceil())


From: Theodore Roth
Subject: Re: [avr-gcc-list] FAQ (was: strange behaviour with ceil())
Date: Mon, 29 Jul 2002 10:48:33 -0600 (MDT)

On Mon, 29 Jul 2002, Joerg Wunsch wrote:

:) (Distinction between space and tab in Makefiles)
:)
:) > As a side note, I would put forth the argument that any program
:) > should not make a distinction between TABS and SPACES.
:)
:) Sure, but that's a merely historical point with the Unix make utility.
:) It's a bit too late to really change this now. ;-) (Although GNU make
:) does its best to allow for both forms, but see my initial posting,
:) relying on this will make a Makefile artificially incompatible with
:) other versions of make.)

You're not a true Unix programmer until you've had to hunt down some
spaces in a makefile that should be tabs. ;-) Not a pleasant experience
with older versions of make (Xenix-286 had the worst error messages I've
ever seen). Gnu-make seems to make it almost tolerable. If you edit a
makefile in emacs with color syntax hilighting on, it will color the bogus
spots for you.

:) The Unix fathers were a bit lazy in typing.  (Actually, their
:) typewriters were running at 100 Baud, so they could only type 10
:) characters per second.)  This made them chose short command names, and
:) short filenames.  Thus, many standard filename suffixes in Unix are
:) single-letter only.

So true.

:) > What is the down side in combining them?
:)
:) My guess is that the initial reason for having them in separated
:) libraries were rather the address space limitations of the PDP-11 Unix
:) originates from.  By splitting off the mathematical library from the
:) remainder of the C library, they could overcome the effects of the
:) small 64 KB data address space.

I think this is part of the reason...

:)
:) These days, it's IMHO not warranted to really have two separate
:) libraries.  I'm all for it to combine all the functions in a single
:) libc.a, and ship an empty libm.a for compatibility (to not break
:) Makefiles that already use "-lm".)
:)
:) Marek and Ted, what do you think about it?

I could go either way on this. Considering that glibc has almost
everything in libc.so now a days, it's probably not totally unacceptable.
The only reason I can come up with for the continued separation of libm
from libc is that it makes it easier to link against a different libm,
which might have custom tuned, higher performance versions of the math
library. You would then only need to change -L at link time to pull in
new libm.

I need to study up on what the link editor does and how it searches
archives before I can give an answer that isn't just hand waving.

In the end, it might be best to continue with tradition.

:)
:) > So perhaps a general AVR GCC FAQ is needed.
:)
:) I already volunteered to maintain it. ;-)

And I would have commited it to cvs last night, but had an unexpected
visitor which lead to the drinking of too much beer...


Ted Roth

avr-gcc-list at http://avr1.org



reply via email to

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