Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #16269 > unrolled thread
| Started by | Avinash Sonawane <avinash.sonawane1990@gmail.com> |
|---|---|
| First post | 2012-01-26 13:59 -0800 |
| Last post | 2012-01-27 11:12 -0600 |
| Articles | 20 on this page of 100 — 30 participants |
Back to article view | Back to comp.lang.c
About -lm switch used for linking math.h Avinash Sonawane <avinash.sonawane1990@gmail.com> - 2012-01-26 13:59 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-26 14:15 -0800
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-26 17:17 -0500
Re: About -lm switch used for linking math.h Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-26 20:54 -0500
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 02:12 +0000
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-26 23:29 +0100
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-26 23:09 -0700
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-27 08:37 +0100
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 09:48 +0000
OT:Re: About -lm switch used for linking math.h Kleuske <kleuske@nowhere.net> - 2012-01-27 10:15 +0000
Re: OT:Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 14:43 +0000
Re: OT:Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 07:49 -0800
Re: OT:Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 15:55 +0000
Re: OT:Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 10:14 -0800
Re: OT:Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 11:23 -0800
Re: OT:Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 09:42 -0700
Re: OT:Re: About -lm switch used for linking math.h 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:08 -0800
Re: OT:Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-14 13:14 +0200
Re: About -lm switch used for linking math.h Rui Maciel <rui.maciel@gmail.com> - 2012-01-27 16:56 +0000
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 17:34 +0000
Re: About -lm switch used for linking math.h Rui Maciel <rui.maciel@gmail.com> - 2012-01-27 17:50 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 17:58 +0000
Re: About -lm switch used for linking math.h tom st denis <tom@iahu.ca> - 2012-01-27 10:15 -0800
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 19:25 +0000
Re: About -lm switch used for linking math.h Kleuske <kleuske@nowhere.net> - 2012-01-28 18:09 +0000
Re: About -lm switch used for linking math.h jt@toerring.de (Jens Thoms Toerring) - 2012-01-27 21:32 +0000
Re: About -lm switch used for linking math.h "Wolfgang.Draxinger" <Wolfgang.Draxinger@physik.uni-muenchen.de> - 2012-01-27 12:40 +0100
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 12:48 +0000
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-27 14:28 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-27 17:14 +0000
Re: About -lm switch used for linking math.h gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-27 17:34 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 10:43 -0700
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 12:25 -0600
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 18:41 +0000
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 13:45 -0500
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 11:29 -0800
Re: About -lm switch used for linking math.h Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-27 22:35 +0100
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 17:19 -0600
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 19:22 -0500
Re: About -lm switch used for linking math.h Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:32 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 16:26 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 13:30 +1300
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 17:04 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 14:10 +1300
Re: About -lm switch used for linking math.h Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-27 21:06 -0500
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 20:09 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 20:15 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 23:03 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 19:10 +1300
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-28 04:28 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-28 15:25 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:39 +1300
Re: About -lm switch used for linking math.h Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-29 09:53 -0800
Re: About -lm switch used for linking math.h Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-03 10:39 +0000
Re: About -lm switch used for linking math.h Joshua Maurice <joshuamaurice@gmail.com> - 2012-02-01 16:42 -0800
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-02-02 01:29 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-28 15:22 -0800
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-29 16:52 -0600
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-30 02:04 -0800
Re: About -lm switch used for linking math.h Ike Naar <ike@iceland.freeshell.org> - 2012-01-30 10:22 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-30 02:36 -0800
Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-14 13:33 +0200
Re: About -lm switch used for linking math.h Ike Naar <ike@iceland.freeshell.org> - 2012-02-14 23:48 +0000
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-02-14 16:35 -0800
Re: About -lm switch used for linking math.h Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:44 +0200
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-30 04:30 -0800
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-30 14:36 +0000
Re: About -lm switch used for linking math.h Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 23:50 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-28 15:29 -0800
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-29 09:11 -0800
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-29 17:49 +0000
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-29 10:07 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-29 14:24 -0800
Re: About -lm switch used for linking math.h Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-29 09:43 -0800
Re: About -lm switch used for linking math.h Keith Thompson <kst-u@mib.org> - 2012-01-27 16:54 -0800
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-28 01:09 +0000
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 14:20 +1300
Re: About -lm switch used for linking math.h Azazel <azazel@remove.azazel.net> - 2012-01-30 17:40 -0600
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-31 00:05 +0000
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-27 20:03 +0000
Re: About -lm switch used for linking math.h Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-27 12:26 -0800
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 10:24 +1300
Re: About -lm switch used for linking math.h "BartC" <bc@freeuk.com> - 2012-01-27 21:32 +0000
Re: About -lm switch used for linking math.h James Kuyper <jameskuyper@verizon.net> - 2012-01-27 16:39 -0500
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-27 23:24 -0600
Re: About -lm switch used for linking math.h Ian Collins <ian-news@hotmail.com> - 2012-01-28 20:38 +1300
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 02:17 -0600
Re: About -lm switch used for linking math.h Richard Damon <news.x.richarddamon@xoxy.net> - 2012-01-28 14:07 -0500
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 15:07 -0600
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-28 21:09 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-27 21:39 -0700
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-28 11:21 +0000
Re: About -lm switch used for linking math.h Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-01-28 17:51 -0700
Re: About -lm switch used for linking math.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-29 02:03 +0000
Re: About -lm switch used for linking math.h Kaz Kylheku <kaz@kylheku.com> - 2012-01-28 18:58 +0000
Re: About -lm switch used for linking math.h jacob navia <jacob@spamsink.net> - 2012-01-28 20:48 +0100
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-28 22:54 -0600
Re: About -lm switch used for linking math.h jgk@panix.com (Joe keane) - 2012-01-29 21:42 +0000
Re: About -lm switch used for linking math.h Robert Wessel <robertwessel2@yahoo.com> - 2012-01-30 00:14 -0600
Re: About -lm switch used for linking math.h Stephen Sprunk <stephen@sprunk.org> - 2012-01-27 11:12 -0600
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-01-27 12:26 -0800 |
| Message-ID | <8086eb21-ff6e-4f71-871d-578cfdd3d209@k6g2000vbz.googlegroups.com> |
| In reply to | #16309 |
On Jan 27, 8:03 pm, j...@panix.com (Joe keane) wrote: > > One day, C was just a language. People wrote some utility functions. > Most languages had input and output statements. Many had special built in functions. C was a bit different. Everything in the language proper mapped to two or three assembly instructions. Everything else was a function. There was no difference between user-defined functions and built in ines, and virtually every function could be implemented in C. The library grew up with the language, however. -- MPI Tutorial - learn parallel programming in C http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-28 10:24 +1300 |
| Message-ID | <9ogivvF8j0U5@mid.individual.net> |
| In reply to | #16310 |
On 01/28/12 09:26 AM, Malcolm McLean wrote: > On Jan 27, 8:03 pm, j...@panix.com (Joe keane) wrote: >> >> One day, C was just a language. People wrote some utility functions. >> > Most languages had input and output statements. Many had special built > in functions. > > C was a bit different. Everything in the language proper mapped to two > or three assembly instructions. Everything else was a function. There > was no difference between user-defined functions and built in ines, > and virtually every function could be implemented in C. > > The library grew up with the language, however. The library also grew to be pretty big in comparison with the "standard" library. On early machines there wasn't any hardware floating point support and RAM was a precious resource, so a separate library made sense. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-01-27 21:32 +0000 |
| Message-ID | <jfv56m$u0m$1@dont-email.me> |
| In reply to | #16311 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:9ogivvF8j0U5@mid.individual.net... > On 01/28/12 09:26 AM, Malcolm McLean wrote: >> On Jan 27, 8:03 pm, j...@panix.com (Joe keane) wrote: >>> >>> One day, C was just a language. People wrote some utility functions. >>> >> Most languages had input and output statements. Many had special built >> in functions. >> >> C was a bit different. Everything in the language proper mapped to two >> or three assembly instructions. Everything else was a function. There >> was no difference between user-defined functions and built in ines, >> and virtually every function could be implemented in C. >> >> The library grew up with the language, however. > > The library also grew to be pretty big in comparison with the "standard" > library. On early machines there wasn't any hardware floating point > support and RAM was a precious resource, so a separate library made sense. Perhaps I no longer understand what the purpose of a linker is, but I thought that they extracted only the functions that were needed from a library (and any further functions that *they* depend on). It was not necessary to load the entire library. So linking in a maths module should not make the program any bigger, if no maths functions are actually used. (Certainly, when I one time decided to dispense with the services of a linker, and wrote my own loader, that loader was very fast just because it *did* just load libraries in their entirety.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-01-27 16:39 -0500 |
| Message-ID | <4F231986.2090408@verizon.net> |
| In reply to | #16313 |
On 01/27/2012 04:32 PM, BartC wrote: > > > "Ian Collins" <ian-news@hotmail.com> wrote in message > news:9ogivvF8j0U5@mid.individual.net... ... >> The library also grew to be pretty big in comparison with the "standard" >> library. On early machines there wasn't any hardware floating point >> support and RAM was a precious resource, so a separate library made sense. > > Perhaps I no longer understand what the purpose of a linker is, but I > thought that they extracted only the functions that were needed from a > library (and any further functions that *they* depend on). It was not > necessary to load the entire library. So linking in a maths module should > not make the program any bigger, if no maths functions are actually used. The size of unused library functions wasn't the issue; the time spent searching the library to see whether there was a correspondingly named function was the problem. Hard as that might be to imagine now, at one time that was a serious constraint on the build time of programs.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-01-27 23:24 -0600 |
| Message-ID | <nt07i7lj333uqi4e90merqgpovcl93mgsm@4ax.com> |
| In reply to | #16313 |
On Fri, 27 Jan 2012 21:32:15 -0000, "BartC" <bc@freeuk.com> wrote: > > >"Ian Collins" <ian-news@hotmail.com> wrote in message >news:9ogivvF8j0U5@mid.individual.net... >> On 01/28/12 09:26 AM, Malcolm McLean wrote: >>> On Jan 27, 8:03 pm, j...@panix.com (Joe keane) wrote: >>>> >>>> One day, C was just a language. People wrote some utility functions. >>>> >>> Most languages had input and output statements. Many had special built >>> in functions. >>> >>> C was a bit different. Everything in the language proper mapped to two >>> or three assembly instructions. Everything else was a function. There >>> was no difference between user-defined functions and built in ines, >>> and virtually every function could be implemented in C. >>> >>> The library grew up with the language, however. >> >> The library also grew to be pretty big in comparison with the "standard" >> library. On early machines there wasn't any hardware floating point >> support and RAM was a precious resource, so a separate library made sense. > >Perhaps I no longer understand what the purpose of a linker is, but I >thought that they extracted only the functions that were needed from a >library (and any further functions that *they* depend on). It was not >necessary to load the entire library. So linking in a maths module should >not make the program any bigger, if no maths functions are actually used. > >(Certainly, when I one time decided to dispense with the services of a >linker, and wrote my own loader, that loader was very fast just because it >*did* just load libraries in their entirety.) They usually do, although it depends on the library writers having done a competent job of segmenting the objects that go into the library. Probably a more significant issue is that you can't actually do that for C, because functions like printf() cannot easily be classified as using, or not using, floating point, since the usage depends on the format strings being passed in. So you'd usually get much of the FP library since printf() *might* need it (and remember that on many small machines, including many of the earlier ones, the FP library included the emulation code for the basic FP operations). Still, this is a QOI issue - the standard assumes that there is *some* set of magic incantations you'll need to make to get your program compiled and linked, and for GCC/*nix based implementations this commonly requires a "-lm" as part of that. Would it make more sense to use the reverse case (IOW specify "no FP support")? I think so, but it's not a big deal, and the former approach is already enshrined. And changing it might well break some stuff.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-01-28 20:38 +1300 |
| Message-ID | <9ohmv3F8j0U11@mid.individual.net> |
| In reply to | #16345 |
On 01/28/12 06:24 PM, Robert Wessel wrote: > On Fri, 27 Jan 2012 21:32:15 -0000, "BartC"<bc@freeuk.com> wrote: > >> >> >> "Ian Collins"<ian-news@hotmail.com> wrote in message >> news:9ogivvF8j0U5@mid.individual.net... >>> On 01/28/12 09:26 AM, Malcolm McLean wrote: >>>> On Jan 27, 8:03 pm, j...@panix.com (Joe keane) wrote: >>>>> >>>>> One day, C was just a language. People wrote some utility functions. >>>>> >>>> Most languages had input and output statements. Many had special built >>>> in functions. >>>> >>>> C was a bit different. Everything in the language proper mapped to two >>>> or three assembly instructions. Everything else was a function. There >>>> was no difference between user-defined functions and built in ines, >>>> and virtually every function could be implemented in C. >>>> >>>> The library grew up with the language, however. >>> >>> The library also grew to be pretty big in comparison with the "standard" >>> library. On early machines there wasn't any hardware floating point >>> support and RAM was a precious resource, so a separate library made sense. >> >> Perhaps I no longer understand what the purpose of a linker is, but I >> thought that they extracted only the functions that were needed from a >> library (and any further functions that *they* depend on). It was not >> necessary to load the entire library. So linking in a maths module should >> not make the program any bigger, if no maths functions are actually used. >> >> (Certainly, when I one time decided to dispense with the services of a >> linker, and wrote my own loader, that loader was very fast just because it >> *did* just load libraries in their entirety.) > > > They usually do, although it depends on the library writers having > done a competent job of segmenting the objects that go into the > library. > > Probably a more significant issue is that you can't actually do that > for C, because functions like printf() cannot easily be classified as > using, or not using, floating point, since the usage depends on the > format strings being passed in. So you'd usually get much of the FP > library since printf() *might* need it (and remember that on many > small machines, including many of the earlier ones, the FP library > included the emulation code for the basic FP operations). Are you confusing floating point arithmetic (and it's emulation) with the floating point mathematical functions in libm? Functions like printf() would certainly use the former, but not the latter. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-01-28 02:17 -0600 |
| Message-ID | <29b7i71r5pguho91vc9dg06ajljkqv50h7@4ax.com> |
| In reply to | #16347 |
On Sat, 28 Jan 2012 20:38:11 +1300, Ian Collins <ian-news@hotmail.com> wrote: >On 01/28/12 06:24 PM, Robert Wessel wrote: >> On Fri, 27 Jan 2012 21:32:15 -0000, "BartC"<bc@freeuk.com> wrote: >> >>> >>> >>> "Ian Collins"<ian-news@hotmail.com> wrote in message >>> news:9ogivvF8j0U5@mid.individual.net... >>>> On 01/28/12 09:26 AM, Malcolm McLean wrote: >>>>> On Jan 27, 8:03 pm, j...@panix.com (Joe keane) wrote: >>>>>> >>>>>> One day, C was just a language. People wrote some utility functions. >>>>>> >>>>> Most languages had input and output statements. Many had special built >>>>> in functions. >>>>> >>>>> C was a bit different. Everything in the language proper mapped to two >>>>> or three assembly instructions. Everything else was a function. There >>>>> was no difference between user-defined functions and built in ines, >>>>> and virtually every function could be implemented in C. >>>>> >>>>> The library grew up with the language, however. >>>> >>>> The library also grew to be pretty big in comparison with the "standard" >>>> library. On early machines there wasn't any hardware floating point >>>> support and RAM was a precious resource, so a separate library made sense. >>> >>> Perhaps I no longer understand what the purpose of a linker is, but I >>> thought that they extracted only the functions that were needed from a >>> library (and any further functions that *they* depend on). It was not >>> necessary to load the entire library. So linking in a maths module should >>> not make the program any bigger, if no maths functions are actually used. >>> >>> (Certainly, when I one time decided to dispense with the services of a >>> linker, and wrote my own loader, that loader was very fast just because it >>> *did* just load libraries in their entirety.) >> >> >> They usually do, although it depends on the library writers having >> done a competent job of segmenting the objects that go into the >> library. >> >> Probably a more significant issue is that you can't actually do that >> for C, because functions like printf() cannot easily be classified as >> using, or not using, floating point, since the usage depends on the >> format strings being passed in. So you'd usually get much of the FP >> library since printf() *might* need it (and remember that on many >> small machines, including many of the earlier ones, the FP library >> included the emulation code for the basic FP operations). > >Are you confusing floating point arithmetic (and it's emulation) with >the floating point mathematical functions in libm? Functions like >printf() would certainly use the former, but not the latter. No - in many implementations (obviously only ones where FP emulation is required) they've been in the same library. In any event, a substantial chunk of the code in printf() and friends is specific to FP, and an integer only version would be much smaller, no matter where the FP emulation code is.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2012-01-28 14:07 -0500 |
| Message-ID | <jg1h1a$40d$1@dont-email.me> |
| In reply to | #16345 |
On 1/28/12 12:24 AM, Robert Wessel wrote: > On Fri, 27 Jan 2012 21:32:15 -0000, "BartC" <bc@freeuk.com> wrote: > > Probably a more significant issue is that you can't actually do that > for C, because functions like printf() cannot easily be classified as > using, or not using, floating point, since the usage depends on the > format strings being passed in. So you'd usually get much of the FP > library since printf() *might* need it (and remember that on many > small machines, including many of the earlier ones, the FP library > included the emulation code for the basic FP operations). > One compiler I used ages ago, on a machine with no built in floating point support, so there was a library that needed to be linked in if your application used floating point, actually defined 2 versions of the printf and related families. The version in the standard library did not have support for floating point formats/numbers. A second version, with the same name, was included in the floating point library which did support the floating point types. Since the defined order of linking the libraries was to check the floating point library first, (if the linker was told you needed floating point), programs which used floating point got the full printf function, while programs which did not use floating point got the limited version of printf, and didn't get the "bloat" of pulling in the floating point library. It was possible to trick the compiler with things like unions to create floating point values and then have printf fail to be able to print them, since the program never needed "floating point math" so could link without the floating point library. Of course the answer is that the "conforming mode" requires linking in the floating point library, even if not needed by the user code.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-01-28 15:07 -0600 |
| Message-ID | <mmo8i7l385232hojsr668ofjcd61ujccll@4ax.com> |
| In reply to | #16362 |
On Sat, 28 Jan 2012 14:07:21 -0500, Richard Damon <news.x.richarddamon@xoxy.net> wrote: >On 1/28/12 12:24 AM, Robert Wessel wrote: >> On Fri, 27 Jan 2012 21:32:15 -0000, "BartC" <bc@freeuk.com> wrote: >> >> Probably a more significant issue is that you can't actually do that >> for C, because functions like printf() cannot easily be classified as >> using, or not using, floating point, since the usage depends on the >> format strings being passed in. So you'd usually get much of the FP >> library since printf() *might* need it (and remember that on many >> small machines, including many of the earlier ones, the FP library >> included the emulation code for the basic FP operations). >> > >One compiler I used ages ago, on a machine with no built in floating >point support, so there was a library that needed to be linked in if >your application used floating point, actually defined 2 versions of the >printf and related families. The version in the standard library did not >have support for floating point formats/numbers. A second version, with >the same name, was included in the floating point library which did >support the floating point types. Since the defined order of linking the >libraries was to check the floating point library first, (if the linker >was told you needed floating point), programs which used floating point >got the full printf function, while programs which did not use floating >point got the limited version of printf, and didn't get the "bloat" of >pulling in the floating point library. That sort of thing is still quite common for implementations targeting small embedded systems. Although supply two versions of the complete library (and you'd link one or the other, but not both) seems to be a bit more common an approach, rather than relaying on search order.
[toc] | [prev] | [next] | [standalone]
| From | jgk@panix.com (Joe keane) |
|---|---|
| Date | 2012-01-28 21:09 +0000 |
| Message-ID | <jg1o6r$c85$1@reader1.panix.com> |
| In reply to | #16310 |
In article <8086eb21-ff6e-4f71-871d-578cfdd3d209@k6g2000vbz.googlegroups.com>, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >There was no difference between user-defined functions and built in >ines, and virtually every function could be implemented in C. The advantage here is that the headers [and source if you have it] were actual files that you can read, and they were written in something like C, not APL, or some compiled binary form.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2012-01-27 21:39 -0700 |
| Message-ID | <1bmx98tp8o.fsf@pfeifferfamily.net> |
| In reply to | #16309 |
jgk@panix.com (Joe keane) writes: > In article <1bipjxvfqk.fsf@pfeifferfamily.net>, > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote: >>The better question would be why the C standard library function >>prototypes aren't all automatically available, without a bunch of >>#include's. To me it seems like they ought to be, but the people >>writing the standards and the people writing the compilers don't agree >>with me, so they aren't. > > Because the C standard mainly codified existing practice. > > One day, C was just a language. People wrote some utility functions. > If you want a function and it isn't in your program, you copy it from > one that does have it. If you for some unknown reason want a > declaration, of course that should go in a header file. > > Eventually, people settled on a more-or-less standard C library, that > contains stuff like stdio that 'everyone' needs. And then, there's a > math library; many programs don't need that stuff. And then, there's > the X library; suprisingly many programs don't do graphics. Umm.... I wasn't involved in C in the *very* early years. But by 1978 (when I first used the language, on a Unix Version 6 PDP 11) the standard C library was firmly in place. Your description sounds a lot more like the description of the early development of operating systems a couple of decades before I was involved, than my early experience with C. The first C compiler I used (on that V6 machine) didn't use separate namespaces for different structs. I remember spending hours and hours tracking down an instance of using a field name defined in one struct as a member in a different one -- no error from the compiler, and total gibberish at runtime.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-01-28 11:21 +0000 |
| Message-ID | <0.7e209aec352656b682a2.20120128112148GMT.87aa583wdv.fsf@bsb.me.uk> |
| In reply to | #16341 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: > jgk@panix.com (Joe keane) writes: <snip> >> Because the C standard mainly codified existing practice. >> >> One day, C was just a language. People wrote some utility functions. >> If you want a function and it isn't in your program, you copy it from >> one that does have it. If you for some unknown reason want a >> declaration, of course that should go in a header file. >> >> Eventually, people settled on a more-or-less standard C library, that >> contains stuff like stdio that 'everyone' needs. And then, there's a >> math library; many programs don't need that stuff. And then, there's >> the X library; suprisingly many programs don't do graphics. > > Umm.... I wasn't involved in C in the *very* early years. But by 1978 > (when I first used the language, on a Unix Version 6 PDP 11) the > standard C library was firmly in place. I think you may be misremembering. The V6 manuals show that the C library had no stdio, no malloc/free, no string handling... Most of that arrived in V7. If the C library had been firmly in place by 1978, I'd expect it to be documented in K&R, and it's not. It must have been worked out (internally) by 1978 because it was mostly there when V7 came out in 1979, but I suspect K&R saw it as just one of many possible libraries for quite some time. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2012-01-28 17:51 -0700 |
| Message-ID | <1b7h0btjpf.fsf@pfeifferfamily.net> |
| In reply to | #16349 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: > >> jgk@panix.com (Joe keane) writes: > <snip> >>> Because the C standard mainly codified existing practice. >>> >>> One day, C was just a language. People wrote some utility functions. >>> If you want a function and it isn't in your program, you copy it from >>> one that does have it. If you for some unknown reason want a >>> declaration, of course that should go in a header file. >>> >>> Eventually, people settled on a more-or-less standard C library, that >>> contains stuff like stdio that 'everyone' needs. And then, there's a >>> math library; many programs don't need that stuff. And then, there's >>> the X library; suprisingly many programs don't do graphics. >> >> Umm.... I wasn't involved in C in the *very* early years. But by 1978 >> (when I first used the language, on a Unix Version 6 PDP 11) the >> standard C library was firmly in place. > > I think you may be misremembering. The V6 manuals show that the C > library had no stdio, no malloc/free, no string handling... Most of > that arrived in V7. If the C library had been firmly in place by 1978, > I'd expect it to be documented in K&R, and it's not. It must have been > worked out (internally) by 1978 because it was mostly there when V7 came > out in 1979, but I suspect K&R saw it as just one of many possible > libraries for quite some time. Taking a look at the V6 man pages, I am surprised by some of the things that are indeed missing -- no malloc() (though there is an alloc(), and there is a free()), no string handling. But while I don't find stdio by that name, I do find printf(), putc(), fopen(), and related functions. I also find abort(), atof(), and a host of other familiar names in Chapter 3. Also, looking up cc in Chapter 1, one of the files linked in by default is /lib/libc.a, which is described as "C library; see section III" The V6 C reference manual does describe things like formatted output (16.3), and states printf is available in "the C library". I call all this "pretty firmly entrenched". See http://wwwlehre.dhbw-stuttgart.de/~helbig/os/v6/doc/index.html
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-01-29 02:03 +0000 |
| Message-ID | <0.f406a754d0b843410a0e.20120129020336GMT.87fwez2rk7.fsf@bsb.me.uk> |
| In reply to | #16375 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >> >>> jgk@panix.com (Joe keane) writes: >> <snip> >>>> Because the C standard mainly codified existing practice. >>>> >>>> One day, C was just a language. People wrote some utility functions. >>>> If you want a function and it isn't in your program, you copy it from >>>> one that does have it. If you for some unknown reason want a >>>> declaration, of course that should go in a header file. >>>> >>>> Eventually, people settled on a more-or-less standard C library, that >>>> contains stuff like stdio that 'everyone' needs. And then, there's a >>>> math library; many programs don't need that stuff. And then, there's >>>> the X library; suprisingly many programs don't do graphics. >>> >>> Umm.... I wasn't involved in C in the *very* early years. But by 1978 >>> (when I first used the language, on a Unix Version 6 PDP 11) the >>> standard C library was firmly in place. >> >> I think you may be misremembering. The V6 manuals show that the C >> library had no stdio, no malloc/free, no string handling... Most of >> that arrived in V7. If the C library had been firmly in place by 1978, >> I'd expect it to be documented in K&R, and it's not. It must have been >> worked out (internally) by 1978 because it was mostly there when V7 came >> out in 1979, but I suspect K&R saw it as just one of many possible >> libraries for quite some time. > > Taking a look at the V6 man pages, I am surprised by some of the things > that are indeed missing -- no malloc() (though there is an alloc(), and > there is a free()), no string handling. But while I don't find stdio by > that name, I do find printf(), putc(), fopen(), and related functions. There was no fopen as we know it. Not only was there no FILE interface but there were separate function to open and to create a file. Apart from there being no string functions, there was no ctype, setjmp, signal, assert, gentenv, system... and so on. > I > also find abort(), atof(), and a host of other familiar names in Chapter > 3. You can also find a host of differences and missing functions. I suppose it depends on what side of the question one is supporting. > Also, looking up cc in Chapter 1, one of the files linked in by default > is /lib/libc.a, which is described as "C library; see section III" > > The V6 C reference manual does describe things like formatted output > (16.3), and states printf is available in "the C library". There most certainly was, for each implementation, a C library. I hope I did not suggest there wasn't. But to me, "the standard C library was firmly in place" means that what was later to be the standard C library was in place by Unix V6. That's not the case, by a long measure. If all you meant was that there was a library, and that it was standard "at the time" then that's not really saying much, but even that is debatable. For example, I think that there was a "standard C library" for GCOS that was not the same as the Unix one. They remained different for a long time -- that's why ANSI C was such a success. > I call all this "pretty firmly entrenched". > > See http://wwwlehre.dhbw-stuttgart.de/~helbig/os/v6/doc/index.html -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-01-28 18:58 +0000 |
| Message-ID | <20120128104804.929@kylheku.com> |
| In reply to | #16309 |
On 2012-01-28, Stefan Ram <ram@zedat.fu-berlin.de> wrote: > not be in the spirit that say that inbuilt operators of the > language map to inbuilt operations of the processor, while > functions might combine such operations to form larger units. I would say there is no such spirit. The first implementations of C (well, B) generated "threaded" code. ``The B compiler on the PDP-7 did not generate machine instructions, but instead `threaded code' [Bell 72], an interpretive scheme in which the compiler's output consists of a sequence of addresses of code fragments that perform the elementary operations. The operations typically—in particular for B—act on a simple stack machine.''[1] The need for run-time support routines just to have all the operators working on all of the arithmetic types is more frequent than one might think; you don't have to reach to examples like 8 bit micros. (Think: libgcc). --- [1] _The Development of the C Language_, 1993, Dennis M. Ritchie, http://cm.bell-labs.com/who/dmr/chist.html
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-01-28 20:48 +0100 |
| Message-ID | <jg1jdv$4r6$1@speranza.aioe.org> |
| In reply to | #16360 |
Le 28/01/12 19:58, Kaz Kylheku a écrit : > The need for run-time support routines just to have all the operators working > on all of the arithmetic types is more frequent than one might think; you don't > have to reach to examples like 8 bit micros. (Think: libgcc). Adapting lcc-win for a customer beginning in March: no floating point, no recursion, no dynamic memory (malloc): 16 bit processor. More or less the same as I did for a 16 bit Analog Devices processor some years ago. Floating point will be supported in a HEAVY emulation layer. There are quite a few jobs like this.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-01-28 22:54 -0600 |
| Message-ID | <c5k9i7t0pfbrptj05mhsd4mod9r27a10k9@4ax.com> |
| In reply to | #16363 |
On Sat, 28 Jan 2012 20:48:16 +0100, jacob navia <jacob@spamsink.net> wrote: >Le 28/01/12 19:58, Kaz Kylheku a écrit : > >> The need for run-time support routines just to have all the operators working >> on all of the arithmetic types is more frequent than one might think; you don't >> have to reach to examples like 8 bit micros. (Think: libgcc). > >Adapting lcc-win for a customer beginning in March: no floating point, >no recursion, no dynamic memory (malloc): 16 bit processor. > >More or less the same as I did for a 16 bit Analog Devices processor >some years ago. > >Floating point will be supported in a HEAVY emulation layer. > >There are quite a few jobs like this. All that heavy? fp_bit.c is less than a couple thousand lines (and would be less if it supported fewer options).
[toc] | [prev] | [next] | [standalone]
| From | jgk@panix.com (Joe keane) |
|---|---|
| Date | 2012-01-29 21:42 +0000 |
| Message-ID | <jg4efh$kdl$1@reader1.panix.com> |
| In reply to | #16309 |
In article <floating-point-20120128191759@ram.dialup.fu-berlin.de>, Stefan Ram <ram@zedat.fu-berlin.de> wrote: > Early and small microprocessors (the 6502 is still > manufactured today!) also do not have »number crunchers«, so > that a C with double isn't just a small layer that make the > processor's operations available via operations in a > portable language on these processors, but it needs a > library even for the floating point operators, which might > not be in the spirit that say that inbuilt operators of the > language map to inbuilt operations of the processor, while > functions might combine such operations to form larger units. I doubt the fact that some machines don't have number crunchers escaped Dennis Ritchie. So we have two choices, make everyone use functions for floating-point operations, or stray a bit from the tightness of operations to machine operations, in the case of missing number cruncher. The first would be pretty awkward [i.e., worse than FORTRAN]. There's also the case where there *are* instructions for such things; they just trap and leave some code to figure out what to do. Also if it you know that the target doesn't have floating-point support, you'd probably do something else (home-brew fixed-point). No need to get exact 754 semantics, if you don't need it. But he didn't extend it to user-defined types.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-01-30 00:14 -0600 |
| Message-ID | <5abci757f6bit9r5jf7lrkgsl1sr5eq31n@4ax.com> |
| In reply to | #16408 |
On Sun, 29 Jan 2012 21:42:10 +0000 (UTC), jgk@panix.com (Joe keane) wrote: >In article <floating-point-20120128191759@ram.dialup.fu-berlin.de>, >Stefan Ram <ram@zedat.fu-berlin.de> wrote: >> Early and small microprocessors (the 6502 is still >> manufactured today!) also do not have »number crunchers«, so >> that a C with double isn't just a small layer that make the >> processor's operations available via operations in a >> portable language on these processors, but it needs a >> library even for the floating point operators, which might >> not be in the spirit that say that inbuilt operators of the >> language map to inbuilt operations of the processor, while >> functions might combine such operations to form larger units. > >I doubt the fact that some machines don't have number crunchers escaped >Dennis Ritchie. > >So we have two choices, make everyone use functions for floating-point >operations, or stray a bit from the tightness of operations to machine >operations, in the case of missing number cruncher. The first would be >pretty awkward [i.e., worse than FORTRAN]. > >There's also the case where there *are* instructions for such things; >they just trap and leave some code to figure out what to do. Which is exactly what we used to do on MS-DOS - a block of INT XXs were reserved to encode the x87 instructions. The runtime would either handle those interrupts and emulate the FP, or patch the calling code with a NOP and the correct first byte of the "real" x87 instruction. >Also if it you know that the target doesn't have floating-point support, >you'd probably do something else (home-brew fixed-point). No need to get >exact 754 semantics, if you don't need it. Although that only works if you have *only* the emulated FP. Changing the semantics if there was an FP coprocessor installed would be a bad thing. MS used to allow C programs to be compiled with their FP formats, as well as the x87 format, although only the latter allowed the use of the coprocessor. IBM's mainframe C/C++ implementation allows you to compile for either the traditional floating hex format or IEEE.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2012-01-27 11:12 -0600 |
| Message-ID | <jfuluk$2jr$1@dont-email.me> |
| In reply to | #16269 |
On 26-Jan-12 15:59, Avinash Sonawane wrote: > 1) Why I need to use -lm flag for math.h even if I had declared the > #include <math.h> in the code? You are confusing libraries and headers. A library, eg. "libm", contains the code for the function you want to call; A header file, eg. "math.h", contains the declaration of the function you want to call. You include a header file so the compiler knows about the function you want to call. However, you must separately tell the linker to include the library with the function itself; the compiler won't tell the linker that for you. (In programs with a single source file, you may not see the distinction between compiler and linker, but it's there--and understanding this is very important when you have multiple source files.) > 2) If it's all about linking the library then why I don't have to do > the same thing with stdio.h too? Most linkers are set up so that they automatically link your code against one or more libraries by default, eg. "libc". However, you still need to tell the compiler about the functions you want to call by including the relevant header file, eg. "stdio.h". > 3) Or we have to add the -l'library' switch for every library excluding > stdio.h? For every library that your linker doesn't include by default. Check your linker's documentation. > 4) In case if the -l'library' switch is used for some specific > libraries only then please direct me to the complete list of such > libraries. There is no complete list of libraries, nor could there be since new ones are created every day. However, the documentation for the library functions you use should specify what, if any, library you should link to. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web