Re: Atomic increment/decrement

I thought that Darwin works on x86 and PowerPC, and that Apple likes to 
create FAT binaries that contain both PowerPC and x86 instructions.

George Rhoten
IBM Globalization Center of Competency/ICU  San José, CA, USA



Andy Heninger <[email protected]> 
Sent by: [email protected]
11/18/2004 11:13 AM
Please respond to
andyh


To
Deborah Goldsmith <[email protected]>
cc
George Rhoten/San Jose/IBM@IBMUS, icu list 
<[email protected]>
Subject
Re: Atomic increment/decrement






Deborah Goldsmith wrote:
 >>> I'd like to have umutex.c take advantage of built-in atomic
 >>> increment/decrement functions on Darwin. The Darwin-specificity can
 >>> be

If Darwin has a dll/loader function to look up the address of a library 
entry point given its name (it probably does), you could use that at ICU 
mutex initialization time to find the atomic increment/decrement 
functions if they exist.  This would sidestep the undefined symbol 
problem at build time.

Another possibility is to just implement the functions yourself. 
PowerPC CPUs have had the necessary instructions since the beginning of 
time, the required assembly language can no doubt be cribbed from 
somewhere, and with only one compiler and processor family to worry 
about, a little inline assembly code may actually be simpler than 
dealing with operating system version dependencies.

> I verified that this can be done using weak linking, but you still have 
> to skip the reference if the function is not present on the system 
> you're building on (otherwise you get an undefined symbol). So you can 
> build it with backward compatibility, but not forward compatibility. 
> This works on any gcc-based system.
> 
> Deborah
> 
> On Nov 16, 2004, at 5:06 PM, Deborah Goldsmith wrote:
> 
>> I still think it could be automatic, but with a runtime test to make 
>> sure the feature is present. I'm looking into how to do that.
>>
>> Deborah
>>
>> On Nov 16, 2004, at 4:36 PM, George Rhoten wrote:
>>
>>> Hopefully, this e-mail will get through to the icu mailing list.  IBM
>>> e-mails don't seem to work with the mailing lists today.
>>>
>>> I do not agree with this proposal.  ICU should work on older versions 
of
>>> an operating system.  We try our very best to allow ICU binaries 
>>> built on
>>> a new version of an operating system to work on older operating 
systems
>>> too. This is mainly with regards to the core library code.  The test 
>>> code
>>> doesn't count.
>>>
>>> Some non-core Apple people do distribute ICU binaries to older 
>>> versions of
>>> Mac OS X.  Open Office and several other groups would have to know 
about
>>> this versioning problem, if this feature was added.  Most people want 
>>> ICU
>>> to work, and they don't want to know the details :-/
>>>
>>> The default should be to use all functions that are available to all
>>> recent versions of Darwin, and not the ones that may be occasionally
>>> there.  This doesn't mean that you can't turn on this feature.  It 
just
>>> means that the default is to use the standard way of doing things.
>>>
>>> If you want to add something like -DU_USE_MACOSX_ATOMIC_INCREMENT or
>>> something like that to Apple's build script to enable this in ICU, 
that
>>> would be fine to add.  Configure should not be used to detect this
>>> feature, since you really have to know what you're doing to use this
>>> feature (I believe this includes you).
>>>
>>> So to summarize...  It's okay to add this code to ICU, but it's not 
okay
>>> to use it by default.
>>>
>>> George Rhoten
>>> IBM Globalization Center of Competency/ICU  San José, CA, USA
>>>
>>>
>>>
>>> Deborah Goldsmith <[email protected]>
>>> Sent by: [email protected]
>>> 11/16/2004 04:11 PM
>>>
>>> To
>>> icu list <[email protected]>
>>> cc
>>>
>>> Subject
>>> Atomic increment/decrement
>>>
>>>
>>>
>>>
>>>
>>>
>>> I'd like to have umutex.c take advantage of built-in atomic
>>> increment/decrement functions on Darwin. The Darwin-specificity can be
>>> taken care of by using a U_DARWIN conditional compile. The sticky 
issue
>>> is that they are not available on all versions of Darwin (just as ICU
>>> has new functions added each release).
>>>
>>> On top of that, Darwin does not have a global "version of Darwin"
>>> preprocessor variable defined. So it looks like this will require
>>> adding something to configure_in to test for the presence of these
>>> particular functions, or ICU won't compile on a version of Darwin
>>> lacking these functions.
>>>
>>> Beyond that, does there need to be a runtime test, to allow a version
>>> of ICU built on a version of Darwin that has the functions, to run on 
a
>>> version of Darwin that doesn't have the functions? In general ICU
>>> doesn't seem to go that far in terms of testing for availability: it
>>> only checks for what's on the system you're building on. Apple doesn't
>>> particularly have a need for this, either: for us it's OK for a 
version
>>> of ICU built on Darwin version A to only run on A or later.
>>>
>>> I'd be curious to hear people's thoughts on the best way of doing 
this.
>>> I already had a private exchange with Steven about this.
>>>
>>> Deborah
>>>

--   Andy Heninger
      [email protected]

_______________________________________________
icu mailing list
[email protected]
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu