[dmd-concurrency] real

[Andrei Alexandrescu]

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