Dynamic arrays allocation size

Brad Roberts braddr at puremagic.com
Tue Mar 26 17:31:54 PDT 2013


On 3/26/13 3:49 PM, "Luís.Marques" <luismarques at 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




More information about the Digitalmars-d mailing list