[dmd-concurrency] real

[Steve Schveighoffer]

May I suggest that Walter you might not be understanding one important thing (and Andrei isn't helping by skirting the obvious):

Under your rule Walter, on a 32-bit machine you will be able to use shared arrays.  Arrays are 64 bits on 32 bit machines.  32-bit machines have 64-bit atomic operations.

But on a 64 bit machine you will not.  Arrays are 128 bit items on 64 bit machines.  There are not 128-bit atomic operations on a 64 bit machine.

So the transition is backwards -- 64 bit will be in turn *less* capable than 32 bit.  This does not analogize with your examples of trying to emulate 32 bits in 16.  It's more like refusing to emulate 32-bit behavior in 64 bits.  D will be saying "we have full support for shared arrays in 32-bit processors, but no support for them in 64 bit."  In essence it will be saying, don't use shared arrays if you want your code to survive the future, or at least the immediate future where 64-bit architectures do not have 128-bit atomic operations.

So you might as well disable shared array operations until you can get them to work on all platforms.

BUT, I think it still will be possible to use shared array operations in 32-bit land because you can always use casting :)

i.e.:

shared int[] arr;
void updateArr()
{
   // this only works for 32-bit code
   shared(int)[] localcopy = cast(shared(int)[]) *(cast(shared(long)*) &arr);

   localcopy[2] = 1;
}

-Steve



----- Original Message ----
> From: Walter Bright <walter at digitalmars.com>
> 
> 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 :
> >>>  
> >>>> 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
> > 
> > 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency