Subject: Re: RE: ACE/TAO under Cygwin (was: ORB)
From: "Martin" <[email-masked]>
To: "Timothy C Prince" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 7 Apr 2003 13:48:16 -0700

Gentlemen:

I found this function in hash_log2.c: from cygwin-1.3.22-1-src.tar.bz2
tarball

__uint32_t
__log2(num)
__uint32_t num;
{
__uint32_t i, limit;
limit = 1;
for (i = 0; limit < num; limit = limit << 1, i++);
return (i);
}

Is this the function you are speaking of??

-Martin

----- Original Message -----
From: "Timothy C Prince" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 07, 2003 12:36 PM
Subject: Re: RE: ACE/TAO under Cygwin (was: ORB)

-----Original Message-----
From: "Dawson, David W" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Mon, 07 Apr 2003 11:19:19 -0400
Subject: RE: ACE/TAO under Cygwin (was: ORB)

I am sorry that I was not clear:
in limits.h, I changed the definition of IOV_MAX to 1024
in math.h, I *commented-out* the macro definition of log2

So, there's not much to test.....

I poked around in the cygwin-1.3.22-1-src.tar.bz2 tarball for the definition
and implementation of log, thinking that log2 could be implemented in code
(versus preprocessor macro), but got quickly lost in the __MATHCALL stuff.

I guess that I was tossing this out for comment by the knowledgeable folks
that implemented/ported the math library from Linux, and why log2 was
implemented this way versus the Linux code way.  Like I said before, I got
quickly lost and certainly have no basis on which to form any
opinion/suggestion.

Thanks,
-David
---------------------
David Dawson
[email-masked]
703-367-3885

-----Original Message-----
From: Martin [mailto:[email-masked]]
Sent: Saturday, April 05, 2003 10:57 PM
To: [email-masked]
Subject: Re: ACE/TAO under Cygwin (was: ORB)

David-
can you show us the patch of code for #define so we can test the results
from the preprocessor output?
Regards,
Martin

----- Original Message -----
From: "Dawson, David W" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, April 05, 2003 8:17 PM
Subject: ACE/TAO under Cygwin (was: ORB)

> I have been moderately successful in compiling ACE/TAO under Cygwin (Some
> problems with cone of the Services, but my CORBA programs interoperate
with
> our Solaris-based TAO services (and other CORBA clients/servants) fine.
>
> I encountered two problems with a couple of the definitions in the Cygwin
> /usr/include files:
>
> 1) In limits.h, IOV_MAX is defined as (__INT_MAX__-1) (a *very* large
> number).
> The other UNIX systems I could examime set it to a much smaller value
(like
> 1024).
> The comment says this is the "/* Maximum number of iovcnt in a writev */".
> Does Cygwin really support this many? Or is this just a convenient
setting?
>
> The reason for the question is that ACE (and TAO) define arrays for the
full
> number of supported IOV entries, and g++ chokes on an array of size
> __INT_MAX__-1
>
> (To set ACE/TAO to compile, I patched this value to 1024)
>
> 2) As a convenience (I suppose), math.h has a macro definition for log2.
> This is not the case in any other math.h I have been able to examine and
> causes a real problem in the development of a platform-independent "log2"
> routine.
>
> The problem is that the pre-processor replaces the string "log2" with it's
> defined value without regard to context.  This means that while I can
write
> my own log() function (in my namespace, or course) I cannot write a log2
> function -- it won't compile.
>
> (To get ACE/TAO to compile, I patched math.h to remove this define.)
>
> The real questions in this post are:
> 1) Should there a better value for IOV_MAX in limits.h
> 2) Should the (as far as I can tell) non-standard define for log2 be
removed
> (or replaced with a real log2 function?)
> 3) Should I just go away and be quiet?
>
> Thanks,
> -David.
>
You make it unnecessarily hard to figure out this message, when you top post
after your respondents have starting bottom posting.

Did you forget the usual precautions, when implementing your own version of
a standard intrinsic?

# undef log2

double (log2)(double x){}

Using a preprocessor macro for log2() is a usual tactic for ia32.  It's a
standard function in C99, included in most libraries which implement (even
partly) gcc's c99 support.  You __must__ use the #undef if you want a "real"
log2() according to the current standard, whether you provide it yourself,
or hope for the library to have it already (cygwin/newlib doesn't).  The way
it's implemented in the default cygwin/newlib installation is unnecessarily
slow and inaccurate, but you're entitled to change that in your own
installation.  In case you don't feel like looking it up, here's the usual
glibc macro:
__inline_mathcode (log2, __x, \
  long double __value;       \
    __asm__ ("fyl2x" : "=t" (__value) : "0" (__x), "u" (1.0) : "st(1)");  \
  return __value)

Tim Prince

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/