... for x86-based platforms.

The thing is that the standard implementation (found in frame.h) is
drastically inefficient on Intel processors, which have the special "fabs"
floating point instruction. Good compilers always recognize calls to fabs()
and replace them with a single instruction, but they can do nothing with
your macro. Consider this example (the comparison itself currently takes 5
instructions instead of a single one it should take; not to say one of them
is an infamous conditional jump...):

------- test.c -------

#define fabs(x) ((x) < 0.0 ? -(x) : (x))

double func( double x )
{
  return fabs( x );
}

------- command -------

cl /Ox /Fa /c /nologo test.c

------- result -------

CONST SEGMENT
__real@8@00000000000000000000 DQ 00000000000000000r ; 0
CONST ENDS
_TEXT SEGMENT
_x$ = 8
_func PROC NEAR
; File test.c
; Line 6
 fld QWORD PTR _x$[esp-4]
 fcom QWORD PTR __real@8@00000000000000000000
 fnstsw ax
 test ah, 1
 je SHORT $L94
 fchs
$L94:
; Line 7
 ret 0

----- if #define is commented out, we get: -----

_TEXT SEGMENT
_x$ = 8
_func PROC NEAR
; File test.c
; Line 6
 fld QWORD PTR _x$[esp-4]
 fabs
; Line 7
 ret 0
_func ENDP
_TEXT ENDS
END

Post a reply to this message

The fabs in 3.1 and before exists because some old C libraries do not have it.
If your library has it the library version will be used as the #define is
conditional!  So there is no problem as long as you have a library that has
fabs...

As far as POV-Ray 3.5 is concerned, it requires a C++ compiler anyway and all
legacy C support has been removed.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote:
> If your library has it the library version will be used as the
> #define is conditional!

I know it's conditional, that is why I asked to put "#define fabs fabs" into
config.h (say, in the _MSC_VER branch of the windows/config.c) rather than
to remove "#define fabs..." from the frame.h...

> So there is no problem as long as
> you have a library that has fabs...

...and frame.h does not always re-define it, as it currently does (as you
surely know, function prototypes cannot be detected with #ifdef...).

> As far as POV-Ray 3.5 is concerned, it requires a
> C++ compiler anyway and all legacy C support has
> been removed.

Wow!... Does that mean that methods are now virtual functions, CSG_Struct
derived from Object_Struct, etc?

Post a reply to this message

> > As far as POV-Ray 3.5 is concerned, it requires a
> > C++ compiler anyway and all legacy C support has
> > been removed.
>
> Wow!... Does that mean that methods are now virtual functions, CSG_Struct
> derived from Object_Struct, etc?

Well, the code snippet (OBJECT_FIELDS and INIT_OBJECT_FIELDS macros) that
Nathan Kopp has kindly sent me, suggests that that could hardly be the
case... Can't quite get then... What else for?

Post a reply to this message

In article <3cf38f5f@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

>> So there is no problem as long as
>> you have a library that has fabs...
>
> ...and frame.h does not always re-define it, as it currently does (as you
> surely know, function prototypes cannot be detected with #ifdef...).

Well, C libraries implement this as macro rather than function, otherwise you
would be seeing compiler errors if the library is defining an appropriate
function prototype because the macro would be applied to that function
prototype as well!

>> As far as POV-Ray 3.5 is concerned, it requires a
>> C++ compiler anyway and all legacy C support has
>> been removed.
>
> Wow!... Does that mean that methods are now virtual functions, CSG_Struct
> derived from Object_Struct, etc?

Where did I say or even imply that?  I said it "requires a C++ compiler"!

I did not say nor imply nor suggest nor in any other way say anything like
that!  To the contrary, I made is explicit that "***legacy*** C support has
been removed".  Even more important, didn't you receive a reply from Nathan
about Object_Struct yesterday that already answered this question...?


    Thorsten

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote:
> Well, C libraries implement this as macro rather than function,
> otherwise you would be seeing compiler errors if the library is
> defining an appropriate function prototype because the macro
> would be applied to that function prototype as well!

Similarly, you would be seeing compiler errors if you wrote, say
  #define strcpy(s1,s2) memcpy((s1),(s2),strlen(s2)+1)
  #include <string.h>

But that would be *your* problems, right? :-) Once again, not all C
libraries define fabs() as a macro, since often there are more efficient way
to do the job. And I was talking about those other C libraries.

> Even more important, didn't you receive a reply from Nathan
> about Object_Struct yesterday that already answered this question...?

Please see my previous message.

Post a reply to this message

In article <3cf3bf56$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> Similarly, you would be seeing compiler errors if you wrote, say
>   #define strcpy(s1,s2) memcpy((s1),(s2),strlen(s2)+1)
>   #include <string.h>

Exactly, and that is pretty much what happens with some compiler-library
combinations when trying to compile POV-Ray 3.1 as C++ code because those
libraries switch from macro versions to (demanded by the C++ standard)
function versions of those macros.  Hence a C++ compiler is required for
POV-Ray 3.5 because it avoids all those problems and we can expect function
versions (or at least some version) of all kinds of former frame.h macros, for
example min and max.

> But that would be *your* problems, right? :-) Once again, not all C
> libraries define fabs() as a macro, since often there are more efficient way
> to do the job. And I was talking about those other C libraries.

Well, the POV-Team only guarantees that POV-Ray compiles on our systems with
our configurations.  All adjustments you need to make are your problem.  That
way we avoid the hundreds of emails we would be getting asking for help to
compile POV-Ray from people who never used a C compiler before :-)

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> ...not all C
> libraries define fabs() as a macro, since often there are more efficient
way
> to do the job. And I was talking about those other C libraries.

Specifically, windows/config.h contains the following code:

  #ifdef _MSC_VER            /* Microsoft Visual C++ */ /* [LSK] */
    #define COMPILER_VER            ".msvc"
    #define IFF_SWITCH_CAST       (long)
    ...

I thought it would be perfectly appropriate to augment that with:

    #define fabs fabs

that would force the use of intrinsic fabs() generating a single
instruction -- just for the particular development system with known
features.

Post a reply to this message