I want the compiler to use my floating point multiply function

The direct solution would be to remove the supplied fmult() or whatever its called from the run time library and replace it with yours. Mostly depends on how the supplied fmult is supplied and whether you can delete and add functions to the library.

Without waiting for wiser heads to speak, I can't think of any other solution than using a macro or a direct function call for your multiply.

double your_mult(double x, double y);

#define MULT(x,y) your_mult(x,y);

a = 1.34; b = 6.75;

c = MULT(a, b); /* multiplication */

You might also try the comp.lang.c newsqroup.

Scott

... snip ...

If (and it is a fairly large if) the multiplications are performed by a library routine, and the calling conventions are the same as what you are generating, all you should need to do is link the new multiplication routines before the library search. That requires you duplicate the link time name exactly. Then the requirement is satisfied, and that module will not be loaded from the library. That also assumes the library is properly modularized so that you can replace the single routine, which may well not be so.

When you start messing with the run-time, many nasty things can happen. You don't know what else in the library depends on that original routine being unchanged. You really need to have the complete run-time library source available.

... snip ...

Please don't. Implementation specific problems are off-topic there. This is not a language problem. This is the appropriate forum, or one dedicated to the OPs actual system, whatever that may be.

Please do not top-post. Please do snip quoted portions that are not germane to any of your reply.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

Your post lacks details, most importantly the name of the beast you're fighting against, i.e. the name of the actual compiler.

Only your compiler maker can really give you this kind of information. If it's not in their manual, your best bet may well be to just go and ask them directly.

Writing your own routine with the exact same name as the one in the runtime lib, as described by CB Falconer, may work. But only if that function is an ordinary function with the usual ABI in the first, which it just might fail to be.

And that's before we begin worrying about the possibility that the compiler might use inlined code to implement floating point multiplies, instead of a call to some runtime library routine, or not just one, but several different functions for different purposes. E.g. one for constant*variable, another for variable * function return value, yet another for complicated expressions multiplied with each other.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

The only certain way is to rewrite the code as

c = mymult(a,b);

Paul Burke

The 'official' way is to compile your library, and make sure the functions have the same name as the original library functions. You then place the resulting object file in the onbect file list before the system libs. That way, the linker will resolve the symbols and use yours instead of the original ones.

Meindert

dear guys,

thanks a lot for your answers!

In order to clarify what I'm doing, let me just explain the whole thing with a sequence of questions and answers.

1. what are you doing?

I'm porting the Minix library which is ANSI 1989 compliant to the M16C microcontroller platform. The compiler I'm using is Renesas-Mitsubishi NC30WA.

1. are you using a filesystem?

yes, the filesystem I'm using is FAT16 and comes from

The media is ATMEL's at45db011 (128 kbyte)

1. what is the status of your porting?

I got everythingh working on my board just fine. Except I can't "printf()" floating points numbers, beacuse each platform has its own floating point representation.

The Minix floating point library was written in a smart way: it give the user two chances:

a. compile and use the floating point package. In this way, I might be able to "printf()" floating numbers.

b. compile only the floating point hook (3 or 4 functions) and use the floating point library of you want. This contract works perfectly on some platforms (example x86) but doesn't on others (M16C or M32C).

Why that? I don't know.

Meindert clarified me that point 3.a is the toughest one because, for each embedded platform I should guess the names that the compiler calls and adapt the floating point library. Therefore, I'm gonna work on point 3.b

I'm going open source with all this work as soon as I solve 3.b problem.

thanks Enrico

its

depends

For some reason my asnwer didn't make it to the group. Reposting...

In general that part of the run-time library (rather compiler-support library - this is lib-gcc for GCC for example) and the compiler are in a very intimate relationship with one another. Usually it's very hard to replace those library calls with your implementation. In some cases the compiler can decide not to use the library function but provide a highly optimized intrisic for the function, or can have special assumptions about the functions in the library (register usage, stack usage, code size, exceptions thrown, etc.). If you don't have full source of the compiler

*and* the original run-time library I would be surprised if you could realiably (under all optimization and compiler settings) implement your own solution.

Just one example:

const double Pi = 3.141592654; const double e = 2.718281828;

double ePi = e*Pi;

The compiler can deduce that e*Pi is a constant expression, calculate the value at compile time, and not generate any call to multiply at the third assignment at all. However it will do the compile-time math with the original 'fmult' library implementation in mind, with that precision, etc. If you replace that function with your implementation at run-time you might expect a different value at ePi (due to rounding) than what it actually contains.

One reliable solution would be to implement your own C++ class (MyDouble) with all the operators, conversions, etc. and use that where appropriate instead of double. A define, like this:

#define double MyDouble

Would probably result in hundreds of linker errors if compile at all. Also, don't expect the compiler to be as clever in optimization with your doubles as it would be with it's native type.

Regards, Andras Tantos

Enrico,

you do not have to guess.

Simply create a test wrapper that calls the compiler's floating point lib.

Store the assembly output and have a look at the subroutines that are called. The same method can be used for any compiler I've seen so far. BTW: The NC30 documentation is pretty precise about the use of loating point (see section D.1.2). Be it IEEE754 single precision or double precision. The source code is also available in the NC30WA/src30/lib directory.

Why in the world would you invest the work and DIY ?

As for a generalized MINIX library version for all available MCU on this planet:

The calls to the floating point mechanisms are highly compiler specific. NC30WA does it differently from the IAR compiler which in turn has a different detail implementation than the TASKING compiler which again differs from a (seen that yet ? ) hypothetical GNU compiler for the M16C. Use another platform and there you are again: C166/C167: TASKING uses a different method than Keil, than does GNU and so forth.

BTW: TASKING , IAR and Keil claim to be ANSI compliant. This not only describes ANSI compliance to specifica of the source code parsing but also the runtime libraries and header files.

NC30( Renesas), TASKING, Keil and of course GNU provide the ANSI and runtime library sources and with a minimum effort the low level I/O can be tailored towards the target's needs.

success & kind regards

/jan

Enrico Migliore schrieb in im Newsbeitrag: snipped-for-privacy@fatti.com...

Renesas-Mitsubishi

functions

That

Hi again Jan!

I got it!! Thanks!!!

yes I know. The problem is that the MINIX printf() function, when I use %e or %f

I want to have an ANSI library complete with fopen(), fclose()... asctime(), clock() et cetera.

ok.

I don't discuss that Renesas's library isn't ANSI compliant: I want a filesystem on my embedded system. Yet, to make an embedded application portable and debuggeable on my Microsoft Visual C compiler, I wrapped all I/O and Timer access with functions like:

fd = port_open("P4_3",O_RDRW)

and port_ctl(fd,PORT_SET,NULL);

thanks for your time Jan Enrico