On 3/26/13 3:49 PM, "Luís.Marques" <[email protected]>" 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
