I'm newbie in C language... Just want to ask how to enable linking floating point library in TurboC?
From the comp.os.msdos.programmer FAQ:
"Floating point formats not linked" is
a Borland run-time error (Borland C or
C++, Turbo C or C++). Borland's
compilers try to be smart and not link
in the floating- point (f-p) library
unless you need it. Alas, they all get
the decision wrong. One common case is
where you don't call any f-p
functions, but you have %f or other
f-p formats in scanf() or printf()
calls. The cure is to call an f-p
function, or at least force one to be
present in the link.
To do that, define this function
somewhere in a source file but don't
call it:
static void forcefloat(float *p)
{
float f = *p;
forcefloat(&f);
}
It doesn't have to be in the module
with the main program, as long as it's
in a module that will be included in
the link.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
There are around 50 built in functions in Python. The printf and scanf functions of C is comes under stdio.h library.
Are there any functions in C that are the part of language itself?
C has a few keywords, but no built-in functions. Every function you use comes from some other library. It is possible to compile a program even without the standard library using -nostdlib flag (for gcc).
It depends on what you mean by "part of the language". There are specifications that define what the C standard library should offer, so to that extent printf(), etc., are "part of the language".
However, a C compiler won't generate the code that implements these functions -- they are expected to be provided in a library of some kind. Most C compilers will know where/what the library is, and will be configured to link it automatically. You can almost certainly tell the compiler/linker not to do this, if you don't want to use the standard library. There are sometimes good reasons to.
Although there is a specification for a standard library, the language syntax itself has little-to-no coupling to the library. In Java, for example, if you add a String and an object, the compiler will generate code to call the object's toString() method. This method has to exist, because the Java language and the Java runtime library are closely related.
There's no real equivalent to this process in C -- C compilers can generate code in complete ignorance of what functions might be available. Those functions do need to be made available before runtime, but that's really the job of the linker, rather than the compiler.
However, gcc at least does have a notion of "built-in" functions. For example, if I try to compile this:
void printf (void)
{
}
I get a warning:
test.c:1:6: warning: conflicting types for built-in function
‘printf’; expected ‘int(const char *, ...)’ [-Wbuiltin-
declaration-mismatch]
even if I use the -nostdlib switch. Even with no standard library, gcc still thinks of printf() as being "built-in" even though it doesn't generate code for it.
I guess that notion of a "built-in function" isn't entirely clear-cut.
All C standard library functions are built into the language—they are part of the C language as defined by the C standard. C implementations (notably compilers) may implement these functions either as built-in functions implemented by the compiler or as object modules linked in by the linker. The C standard largely separates the rules that says how C programs must behave from rules about how C programs must be implemented.
In the sense of how a C program must behave, there is no difference between a built-in function or a linked-in function: The function behaves the same, and there is no way to describe an observable difference between the two implementations.
Compilers generally use a mix of built-in implementations and linked-in implementations. For example, in void foo(uint32_t u) { float f; memcpy(&f, &u, sizeof f); … }, a compiler may implement the memcpy by generating an instruction to move data from an integer register to a floating-point register and not by calling any external memcpy routine. For other memcpy calls, it might generate simple instructions to move bytes and again not call an external routine. For sqrt, it might generate a square-root instruction if the target machine has an appropriate one.
More complicated functions are more often implemented by calling external functions that are linked into the program after compilation. Even with many of these, the compiler may recognize special cases and provide calls to alternative functions (printf("Hello, world.\n") may be implemented as if it were puts("Hello, world."), instructions that perform the function without a call (pow(x, 2) may be implemented as a multiplication of x by itself), or results may be computed at compile time, by code built into the compiler (sin(.3) might be evaluated at at compile time).
The standard library function abs() is declared in stdlib.h, while fabs() is in math.h.
Why are they reside in different headers?
math.h first appears in 7th Research Unix. It is hard to tell how it got there. For example, [1] claims that bits of C library were merged from "PWB/Unix" which included troff and C compiler pcc, but I cannot prove it.
Another interesting piece of information is library manual from V7 Unix:
intro.3:
(3) These functions, together with those of section 2 and those marked (3S),
constitute library libc, which is automatically loaded by the C compiler
cc(1) and the Fortran compiler f77(1). The link editor ld(1) searches
this library under the `-lc' option. Declarations for some of these
functions may be obtained from include files indicated on the appropri-
ate pages.
<...>
(3M) These functions constitute the math library, libm. They are automati-
cally loaded as needed by the Fortran compiler f77(1). The link editor
searches this library under the `-lm' option. Declarations for these
functions may be obtained from the include file <math.h>.
If you look into V7 commands makefiles, only few C programs are linked with -lm flag. So my conclusion is speculative:
libm.a (and math.h) was primarily needed for FORTRAN programs mostly, so it was separated into library to reduce binary footprint (note that it was linked statically).
Not many machines had floating point support. For example, you would need to buy an optional FPP for PDP-11 [2], there is also libfpsim simulation library in Unix to mitigate that, so floating point can be hardly used in early C programs.
1. A History of UNIX before Berkeley: UNIX Evolution: 1975-1984
2. PDP-11 architecture
Most operators like + - / * are also math operators yet these are also readily available. When programming you use so much math, that developers have started to differentiate between math that is needed for everyday stuff and math that is more specialized that you only use some of the time. Abs is one of those functions that are just used to often. Like with pointer arithmetic when you just want to know the difference to calculate the size of a memory block. But you are not interested in knowing which is higher in memory and which is lower.
So to sum up: abs is used often because it calculates the difference of two integers. The difference between two pointers for instance is also an integer. And so it is in stdlib.h. fabs how ever is not something you will need much unless you are doing math specific stuff. Thus it is in math.h.
I'm new to C. I was traveling through math.h, looking for its mathematical algorithms, but encountered only this kind of lines:
_CRTIMP double __cdecl sin (double);
_CRTIMP double __cdecl cos (double);
...
Now, I couldn't find the algorithm itself. I know _CRTIMP is a kind of run-time library C uses, but I just can't figure out what the whole line means. Could you, please, explain?
Besides, I would like to know where these functions are defined at.
C headers typically contain only function prototype declarations, not definitions. Function prototypes specify what is called the "function signature": return value, arguments, and sometimes calling convention (when & where compilers support this). The function definitions are in a separate source file, that gets compiled separately from your own (including any headers your source file #include's). Definitions of library functions might be in C, they might also be in assembly, but that shouldn't matter to your code (only to your curiosity). But you probably don't compile those yourself anyway; instead, your development environment / operating system comes with a standard library (a binary object file) that contains many already-compiled functions. Your development environment simply links your code to that library.
C header files will only contain the declaration of functions, not their definitions.
You're looking for the source code of the functions declared in math.h, here's one implementation of sin: http://fxr.watson.org/fxr/source//arch/i386/math-emu/poly_sin.c?v=linux-2.4.22
The C header files that are included with your OS, compiler, or C runtime library are not really intended for human consumption. You can certainly read them, and you can learn quite a bit by trying to understand them, but they're primarily intended for use by the compiler. As you've seen in these examples, they tend to depend on a lot of compiler-specific features (a habit you should try to avoid in your own code).
They also tend to have a lot of #ifdefs, so the same headers can be used with different systems.
If you just want to know how to use the sin function, for example, you're better off reading your system's documentation. On my Ubuntu system, for example, man sin shows this (among other things):
SYNOPSIS
#include <math.h>
double sin(double x);
float sinf(float x);
long double sinl(long double x);
Link with -lm.
The _CRTIMP and __cdecl are probably important to the compiler, but as a programmer you can safely ignore them.
If you're looking for the source code that implements the sin function, that may or may not be available. It might be written in a language other than C; there have even been systems where it's implemented in hardware (though a small wrapper would still be required).
Another answer provides a link to one implementation, but that's probably not the one used on your system.
And you don't need to get too bogged down in how the sin function is implemented. It's certainly a good thing to know, but you don't need that information to write code that uses it. (I absolutely do not want to discourage curiosity.)
I read that the pow(double, double) function is defined in "math.h" but I can't find its declaration.
Does anybody know where this function declared? And where is it implemented in C?
Reference:
http://publications.gbdirect.co.uk/c_book/chapter9/maths_functions.html
Quite often, an include file such as <math.h> will include other header files that actually declare the functions you would expect to see in <math.h>. The idea is that the program gets what it expects when it includes <math.h>, even if the actual function definitions are in some other header file.
Finding the implementation of a standard library function such as pow() is quite another matter. You will have to dig up the source code to your C standard runtime library and find the implementation in there.
Where it's defined depends on your environment. The code is inside a compiled C standard library somewhere.
Its "definition" is in the source code for your c standard library distribution. One such distribution is eglibc. This is browsable online, or in a source distribution:
w_pow.c
math_private.h
Short answer: In the C standard library source code.
The actual implementation of pow may vary from compiler to compiler. Generally, math.h (or a vendor-specific file included by math.h) provides the prototype for pow (i.e., its declaration), but the implementation is buried in some library file such as libm.a. Depending on your compiler, the actual source code for pow or any other library function may not be available.
declared: in the include directory of your system/SDK (e.g.: /usr/include;/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/architecture/arm/math.h)
defined (implemented):
as library (compiled, binary code): in the library directory of your system/SDK (e.g.: /usr/lib (in case of the math library it's libm.dylib)
as source (program code): this is the interesting part. I work on a Mac OS X 10.6.x right now. The sources for the functions declared in math.h (e.g.: extern double pow ( double, double ); ) are not shipped with the installation (at least I couldn't find it). You are likely to find those sources in your system/SDK's C library. In my case the math library (libm) is a separate project, some of its sources are provided by Apple: http://www.opensource.apple.com/tarballs/Libm/Libm-315.tar.gz
The extern keyword in the function declaration of pow means, that it's defined somewhere else. Math functions are low-level high-performance implementations mostly done in assembly code (*.s). The assembly routines (taking the arguments/giving the parameters via registers/stack) are linked with the rest of the C library. The linking/exporting of the function/routine names is platform specific and doesn't really matter if ones goal is not dive into assembly coding.
I hope this helped,
Raphael
If you are seeking how the calculation is implemented, you can find it here:
http://fossies.org/dox/gcc-4.5.3/e__pow_8c_source.html
The name of the function is __ieee754_pow
which is called by pow function.
I’s really defined in math.h. Have you tried including math.h and simply using pow? What do you mean by “can't find it”?
Here's a C implementation for fdlibm: http://www.netlib.org/fdlibm/e_pow.c
For what it's worth, when v8 dropped its cos/sine tables, it pulled from fdlibm's implementation to do so: https://code.google.com/p/v8/source/detail?r=22918
From the change commit comments: "Implement trigonometric functions using a fdlibm port."
Mozilla on the other hand calls the cstdlib math functions, which will have variable performance by build and system (ex: may or may not invoke the chip-level implementations of transcendental functions). While C# bytecode seems to make explicit references to chip-level functions when it can. However, "pow" is not one of those, iirc (doesn't seem to have an chip-level function) and is implemented elsewhere.
See also: https://bugzilla.mozilla.org/show_bug.cgi?id=967709
For a cos/sine discussion in the Mozilla community, comparison of Mozilla's implementation vs old v8 implementation.
See also: How is Math.Pow() implemented in .NET Framework?
Intrinsic functions are chip-level, actually implemented on the processor. (We don't necessarily need lookup tables any more.)
Its here and also here.
Also go on wikipedia
You will find pow there.
I'm developing program for Cortex-M3. It doesn't have floating point coprocessor. Standard C library can emulate floating point operations, but I don't use it due to its size.
Is there any good and free c library, which can emulate floating point arithmetics, targeted on ARM processors?
Currently, when I use floating point operators I have such linkage errors:
undefined reference to `__adddf3'
undefined reference to `__subdf3'
undefined reference to `__divdf3'
undefined reference to `__extendsfdf2'
undefined reference to `__muldf3'
So probably such library should implement them.
Would you not be better off (performance and size wise) using fixed point? For simple arithmetic, this is trivial to implement either directly or with a function interface. If you could bare to use C++, using operator overloading could make the use of fixed almost seamless (at no runtime overhead compared to a C function interface).
If you have more complex requirements (trig, roots etc), a good fixed-point library is presented in this Dr. Dobb's Article.
If you want to perform your floating arithmetic using built in operators, then you'll need to provide the library routines that the compiler expects, so you'd end up with something that's likely to be as large as the library that came with the compiler.
You likely have the source code to the compiler's floating support routines, so if you want to look at them to see if you can improve them that's probably your best chance. If you don't think that'll work for whatever reason, you should talk to your compiler vendor about the requirements the compiler expects of the floating support routines and the best way to replace the vendor's library.
If you want to circumvent the compiler's requirements, you'll probably need to avoid using the built in operators and perform you arithmetic using explicit function calls. I have no experience with 3rd party floating point library routines, so unfortunately I can't point you to an possible good alternatives.
Those should be defined in the runtime support library for your compiler. Those names look like the floating-point functions from libgcc (the support library for gcc), which is pretty small. You should be able to pull in those functions by setting your link flags appropriately.
Perhaps newlib would be useful here? It can be a pain to set up the toolchain, but I've had success in reducing embedded flash usage versus gcc and its standard library.
Any static linker worth its salt is going to remove unused calls. This is particularly true for embedded compilers.
gcc has all of those functions, there is gcc build voodoo (multilib, thumb, thumb2, and soft float) you can use to have that automatically have it show up. I have years ago given up and just go grab the files from the gcc sources trim them to a clean source and just build them into my projects. Years ago looking at a commercial compiler or two then looking at newlib and gcc, at least at the time they were all using pretty much the same math library. I want to say it was from Sun.
Assuming your using gcc try compiling with the -static-libgcc flag and checking the final binary size. I don't know if the linker will optimize out the unused calls but I think it will.
All the below message represent some arithmetic operation
undefined reference to __adddf3'
undefined reference to__subdf3'
undefined reference to __divdf3'
undefined reference to__extendsfdf2'
undefined reference to `__muldf3'
So while linking compiler will give linking error if you are doing some arthamatic operation in two different data type. For example:
Float x;
float y;
y = x * 0.45;
So if you compile this code while linking it will give you below message
undefined reference to `__muldf3'
To resolve this specify the "0.45" explicitly to float
y = x * 0.45F;
Most of the time this type of linking error comes when you are using c++ compiler to compile c file.