X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <4701C96B.8050708@cwilson.fastmail.fm>
Date: Tue, 02 Oct 2007 00:30:35 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: llrint implementation in Cygwin
References: <fd68u2$geo$1 AT sea DOT gmane DOT org> <46F6C151 DOT 3070301 AT computer DOT org>   <fdif1q$efv$1 AT sea DOT gmane DOT org> <Pine DOT GSO DOT 4 DOT 63 DOT 0709280802020 DOT 16275 AT access1 DOT cims DOT nyu DOT edu>  <fdm873$2oj$1 AT sea DOT gmane DOT org> <Pine DOT GSO DOT 4 DOT 63 DOT 0709291533000 DOT 27776 AT access1 DOT cims DOT nyu DOT edu> <fdmc2b$con$1 AT sea DOT gmane DOT org> <46FEC886 DOT 7020007 AT cwilson DOT fastmail DOT fm> <fdrb6n$qo1$1 AT sea DOT gmane DOT org>
In-Reply-To: <fdrb6n$qo1$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Diego Biurrun wrote:

> Next time you call shenanigans, get your facts straight first please.  I 
> never claimed that we do not *have* OS-specific workarounds, I said we 
> do not *add* them.

That's a verrrry fine distinction and was not at all clear from the 
foregoing conversation.

>  > The libavcodec directory has entirely separate
>> subdirs for different processors -- platform specificity is BUILT IN 
>> to the ffmpeg source tree.
> 
> Nonsense.  These are assembler optimizations for speed-critical 
> functions (and the reason why you can watch movies without GHz CPUs). 
> These are, by their very nature, processor-specific, but they are not 
> workarounds.  Nothing could be further from the truth.

It's an example of special purpose (blocks of) code, where a given block 
is compiled only under particular circumstances -- e.g. for a specific 
target cpu -- in pursuit of a particular goal.  In this case: speed. 
Control flow (whether a particular file or block of code is actually 
compiled for a given target) is determined by...for lack of a better 
term, "makefile magic".

>  > That file ALSO contains a
>> half-dozen implementations of read_time depending on which 
>> microprocessor architecture is in use.
> 
> What does this have to do with a workaround?  read_time is internally 
> used in some benchmarking macros, it is not an OS function.

It's an exampleof special purpose (blocks of) code, where a given block 
is compiled only under particular circumstances -- e.g. for a specific 
target cpu -- in pursuit of a particular goal.  In this case: high res 
benchmarking. Control flow (whether a particular file or block of code 
is actually compiled for a given target) is determined by...using the 
earlier nomenclature, "ifdef magic".

> 
>> Oh, and lookee here, in the same file:
>>
>> #ifndef HAVE_LRINTF
>> /* XXX: add ISOC specific test to avoid specific BSD testing. */
>> /* better than nothing implementation. */
>> /* btw, rintf() is existing on fbsd too -- alex */
>> static av_always_inline long int lrintf(float x)
>> {
>>     return (int)(rint(x));
>> }
>> #endif /* HAVE_LRINTF */
> 
> Good catch, this is cruft from ages ago.  I will look into nuking this 
> very soon.

So, I find an example of EXACTLY the sort of feature-dependent 
workaround under discussion, and your response is "no, that's not a 
valid example...and if it is, we'll get rid of it?"

Look, the point is: there are many platforms out there that do not 
support the entire panoply of C99 functions. Or even all POSIX (1b? 1c? 
1e? 2?) functions.  If the FFMpeg team cares about portability, the 
correct answer is not to climb upon a high horse, declaim "we do not 
[use|add] platform-specific workarounds" and deliberately release code 
that is /not/ portable to the disdained platform -- and then blame that 
platform for not updating their runtime library according to /your/ 
project's release schedule. "Well, cygwin will just have to be broken"

If you do /not/ care about portability, then the response above is 
perfectly fine.

> So all in all you have refuted some points I never made, while bungling 
> some of the research used to substantiate your claims.  What is the 
> point you are trying to prove here?

No, you missed the point of the three examples. They demonstrate a 
plethora of special-purpose code: whether (the control flow determining 
if a particular hunk of code is compiled) is in the Makefile magic 
(build the i386 subdir, don't build the ppc subdir, etc) or is in the 
ifdef magic (#ifdef HAVE_I386_CPU, etc) is immaterial.

And is no different than:

#ifndef HAVE_LLRINTF
replacement code for llrintf()
#endif

(which is feature-based, not platform-based, anyway!)

It was just disappointing to see a simple replacement function -- no 
different in principle than any of the three examples I provided, and 
practically identical to the last example, rejected with a blase' "we 
don't add platform-specific workarounds -- cygwin will just have to be 
broken". WTH?

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/