On 3/26/13 12:01 PM, Andrei Alexandrescu wrote:
> On 3/26/13 2:53 PM, "Luís Marques" <luismarques@gmail.com>" wrote:
>> BTW, Andrei, what do you think the impact of this is for embedded
>> systems with unusual word lengths (combined with D's well-defined type
>> sizes)?
>
> I think we're a bit biased toward x86, but I also think C's cavalier
> approach to data sizes and operational semantics ain't better.
>
> Andrei

The bias towards x86 is less than the bias towards standard integer sizes.  D explicitly ignores platforms with odd sizes.  D does NOT support byte where byte is outside the range -127..128.  Etc.

Brad

On Tuesday, 26 March 2013 at 21:00:43 UTC, Brad Roberts wrote:
> The bias towards x86 is less than the bias towards standard integer sizes.  D explicitly ignores platforms with odd sizes.  D does NOT support byte where byte is outside the range -127..128.  Etc.

Brad, if the overflow/underflow was undefined behavior you could easily map D types into the machine's weird native types with little performance loss. So, in that sense, D would support "platforms with odd sizes".  Even as is I'm sure D *can*  support those unconventional platforms, it just has a performance penalty to assure that the exact semantics are followed, because there isn't a completely direct map between the native instructions/registers and D's type model.

Just because a D byte is mapped into a 10-bit register does not mean the language is supporting bytes outside of the [-128, +127] range. The question is if the compiler has to add extra instruction to ensure if the overflow behavior of the registers/CPU instructions matches the language overflow behavior. If the overflow behavior was undefined then the 10-bit register would be a direct implementation of D's byte. Since it isn't undefined, and the register presumably wraps at 10 bits, then the compiler has to emit extra code, to model the behavior of an 8-bit two's-complement variable in a 10-bit register.

BTW, in platforms (defined not just by the hardware, but the OS, etc) where at least one of the C types did not exactly match any of D's types then there would be an interesting problem. In core.stdc.config the C types are defined as aliases to D types, but if you had, say, a 256-bit long long then you'd be up for trouble :-). You couldn't do as is done currently with the aliases:

version( Windows )
{
    alias int   c_long;
    alias uint  c_ulong;
}
else
{
  static if( (void*).sizeof > int.sizeof )
  {
    alias long  c_long;
    alias ulong c_ulong;
  }
  else
  {
    alias int   c_long;
    alias uint  c_ulong;
  }
}

An interesting idea would be to have the standard types defined at the current sizes but allowing other sizes, other overflow / underflow behaviors (unspecified, exception, wrapping, saturation...), etc.

I don't expect that to happen, but just saying, it would be cool :-)

On 3/26/13 3:49 PM, "Luís.Marques" <luismarques@gmail.com>" wrote:
> On Tuesday, 26 March 2013 at 21:00:43 UTC, Brad Roberts wrote:
>> The bias towards x86 is less than the bias towards standard integer
>> sizes.  D explicitly ignores platforms with odd sizes. D does NOT
>> support byte where byte is outside the range -127..128.  Etc.
>
> Brad, if the overflow/underflow was undefined behavior you could easily
> map D types into the machine's weird native types with little
> performance loss. So, in that sense, D would support "platforms with odd
> sizes".  Even as is I'm sure D *can*  support those unconventional
> platforms, it just has a performance penalty to assure that the exact
> semantics are followed, because there isn't a completely direct map
> between the native instructions/registers and D's type model.
>
> Just because a D byte is mapped into a 10-bit register does not mean the
> language is supporting bytes outside of the [-128, +127] range. The
> question is if the compiler has to add extra instruction to ensure if
> the overflow behavior of the registers/CPU instructions matches the
> language overflow behavior. If the overflow behavior was undefined then
> the 10-bit register would be a direct implementation of D's byte. Since
> it isn't undefined, and the register presumably wraps at 10 bits, then
> the compiler has to emit extra code, to model the behavior of an 8-bit
> two's-complement variable in a 10-bit register.

If and could.  Yes, you're right.  However, that would be making a trade off in an odd direction.  It'd add undefind behavior to add a capability for integer sizes to vary on platforms that most developers don't use or test on.  The result is what you see in C, the chances of any given C app actually working correctly on these platforms is fairly close to 0.

So, D has explicitly defined the sizes on purpose, to make correct, working code, easier to create at the expense of making those extremely rare architectures have to do extra work if they want to support D.  I think it's the right tradeoff.  Either way, it's the trade off that's been made, and it's not likely to change.

Brad

On Wednesday, 27 March 2013 at 00:32:12 UTC, Brad Roberts wrote:
> Either way, it's the trade off that's been made, and it's not likely to change.

Sure, I was not arguing for changing that. I just wanted to clarify that when you say that "D explicitly ignores platforms with odd sizes" that does not mean that D cannot be implemented on these other machines, only that there might be a performance penalty (as had to be the case, given Turing et al...), depending on the exact circumstances.

What might actually be cooler would be being able to define your own types (though I don't expect that idea to be adopted soon, either), with their own properties, such as having ints that saturate instead of wrapping (like MMX), with different numbers of bits, etc. On a good compiler some of those alternative types would allow exploiting nice machine properties, and would complement the benefits of having the standard types, the same way pointers complement arrays. And you could actually define the C types on platforms where they don't match with the D types, as I pointed out earlier in this thread.