[dmd-concurrency] real

Walter Bright walter at digitalmars.com
Thu Jan 28 15:59:04 PST 2010


You say the 2 word atomics lead to an entirely different design than 1 
word atomics. I agree and think that is pretty clear. My point was that 
in trying to make 16 <=> 32 bit portability, the problems with 
allocating 100,000 byte arrays led one inevitably to using entirely 
different designs between the two, even if the language tried to make 
such code portable. You couldn't hide those design changes behind a 
simple macro.

But very few people advocated forcing 32 bit designs to be coded as if 
they were 16 bit ones. Similarly, I can't see disabling support for 128 
bit atomics just because they don't work on some CPUs.

The user does have a choice - he can program it using 32 bit 
constraints, and it will work successfully on 64 bit machines. Or he can 
code to 64 bit CPU advantages and accept that he's going to have to 
redesign some of it for 32 bit systems. We shouldn't make that decision 
for him, as he quite possibly has no intention of trying to port it to 
32 bits, and instead wants to exploit the machine he bought.

Andrei Alexandrescu wrote:
> That's a very different topic than shared arrays, and you tend to 
> conflate the two.
>
> I find the availability or lack thereof of certain types on certain 
> platforms quite reasonable. Assume "cent" were still in the language - 
> I'd have no trouble saying that in D cent-based code may or may not 
> work depending on the machine.
>
> Also, I find it reasonable to leave the length of certain types to the 
> implementation, as long as we don't fall in C's mistake of making a 
> hash of everything. For example, it's entirely reasonable to say that 
> real is 80 bit on Intel but 64 bit on other machines or 128 bit on 
> other machines. It's also reasonable to say that the size of size_t, 
> ptrdiff_t, and void* depends on the platform.
>
> The issue with atomic assignment of shared arrays is a different beast 
> entirely, and no amount of eloquent rhetoric, historical examples, 
> comparisons, and metaphors will counter that. The problem is that 
> using two-word atomics (assignment and CAS) leads to _entirely_ 
> different designs than using one-word atomics. It turns out that the 
> power of the two is the same, but two-word atomics simplify design a 
> fair amount.
>
> So we're at a crossroad. We could say: D offers two-word atomics, go 
> ahead and design with it. Or we could say: D offers one-word atomics, 
> go ahead and design with it. That is it.
>
> What is entirely unreasonable is: whatever machine you're on, we're 
> allowing maximum possible without warning you of any portability 
> issue. It's not acceptable! Again: D is not assembly language with 
> different instructions for different machines!!!
>
> The maximum we could do is to offer certain intrinsics a la 
> assignDword() and clarify that they are nonportable. Then people look 
> up its documentation, grep for it, etc. But throwing such a basic 
> feature as assignment into the fray is very wrong.
>
>
> Andrei
>
> Walter Bright wrote:
>> I'm still ticked that many languages and compilers dropped support 
>> for 80 bit long doubles on x86 in the 90's because non-x86 CPUs 
>> didn't have it.
>>
>> Don Clugston wrote:
>>> 2010/1/28 Steve Schveighoffer <schveiguy at yahoo.com>:
>>>  
>>>> By that logic, shared arrays must be usable on 32-bit systems and 
>>>> not on 64 bit.  I think this is a huge portability issue, and an 
>>>> unacceptable inconsistency.
>>>>
>>>> Reals are not the same however, there the capabilities of the 
>>>> processor are specifically targeted.
>>>>     
>>>
>>> Agreed. The IEEE describes 80-bit extended real as a non-interchange
>>> format. I think it's perfectly acceptable to make its sharing
>>> behaviour processor-specific. (It could be defined as an ABI issue).
>>> In general, 'real' does not support atomic operations -- certainly not
>>> for SPARC 128-bit reals, which are implemented via hardware
>>> interrupts.
>>>   
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> dmd-concurrency mailing list
>> dmd-concurrency at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>
>


More information about the dmd-concurrency mailing list