The ABI changed in 0.176 to reflect an accumulation of fixes. It's apparent that it needs to change at least once more. So I wouldn't waste too much time shipping precompiled libraries for 0.176, but it is worth compiling and checking for dmd bugs that need fixing.

Hopefully soon we'll have an ABI we can live with for a while.

Walter Bright wrote:
> The ABI changed in 0.176 to reflect an accumulation of fixes. It's apparent that it needs to change at least once more.

FWIW, I wouldn't mind an ABI change with each and every release before 1.0, for right now is the time for these changes.

Georg Wrede wrote:
> Walter Bright wrote:
>> The ABI changed in 0.176 to reflect an accumulation of fixes. It's apparent that it needs to change at least once more.
> 
> FWIW, I wouldn't mind an ABI change with each and every release before 1.0, for right now is the time for these changes.

I'll second that. :)

-- 
- EricAnderton at yahoo

Walter Bright wrote:
> The ABI changed in 0.176 to reflect an accumulation of fixes. It's apparent that it needs to change at least once more. So I wouldn't waste too much time shipping precompiled libraries for 0.176, but it is worth compiling and checking for dmd bugs that need fixing.
> 
> Hopefully soon we'll have an ABI we can live with for a while.

The name mangling for complex template parameters is also using the old
order (little endian between bytes, big endian within bytes), while for
real template params it uses the new one (big endian). I think that's
probably my fault.

Line 1498.

	for (int i = 0; i < REALSIZE-REALPAD; i++)
	    buf->printf("%02x", p[i]);

should be

    for (int i = REALSIZE-REALPAD-1; i >=0; i--)
 buf->printf("%02x", p[i]);


However, even better would be to make this aspect of the ABI
CPU-independent.

Define format to be:
e HexExponent HexSignificand  for real and imaginary FP literals.
c HexExponent HexSignificand HexExponent HexSignificand for complex FP
literals.

where

HexExponent 4HexDigits
HexSignificand 16HexDigits

Hex digits are encoded as the first ten bytes of the binary
representation of the number in quadruple floating point BigEndian
format, with no implicit significand bit. Only the first 64 significand
bits are stored.
(This means that the first four characters are the biased exponent, and
the next 16 characters are the first 64 significand bits, in the same
form that is used by hexadecimal floating point literals).
Example:
The template argument 0x1.12345678ABCDp+0
is encoded as:
Sde3FFF12345678ABCD0000

This means that on systems where real is identical to double, the last
three characters will always be "000", and the third character will
either be 'F' or '0'.

I'll post a patch to do this when I get a chance.

Georg Wrede wrote:
> Walter Bright wrote:
>> The ABI changed in 0.176 to reflect an accumulation of fixes. It's apparent that it needs to change at least once more.
> 
> FWIW, I wouldn't mind an ABI change with each and every release before 1.0, for right now is the time for these changes.

How about getting more of the ABI documented in the first place with each and every release?

Stewart.

Don Clugston wrote:
> However, even better would be to make this aspect of the ABI
> CPU-independent.
> 
> Define format to be:
> e HexExponent HexSignificand  for real and imaginary FP literals.
> c HexExponent HexSignificand HexExponent HexSignificand for complex FP
> literals.

You've given me a great idea. Why not just use the %A format? It portably formats the value into a machine independent hex format. All that needs to be done is to massage it to elide the non-identifier characters.

> I'll post a patch to do this when I get a chance. 

Not necessary, I've already done it.

Walter Bright wrote:
> Don Clugston wrote:
>> However, even better would be to make this aspect of the ABI
>> CPU-independent.
>>
>> Define format to be:
>> e HexExponent HexSignificand  for real and imaginary FP literals.
>> c HexExponent HexSignificand HexExponent HexSignificand for complex FP
>> literals.
> 
> You've given me a great idea. Why not just use the %A format? It portably formats the value into a machine independent hex format. All that needs to be done is to massage it to elide the non-identifier characters.

That's brilliant. It means you have automatic compression of trailing zero bits. I guess if you strip off the "0x1.", you get rid of the problem with the formats which use another character like "0xA." instead.
I presume it will have either the length at the front like an Lname, or else some character as a delimiter?

Don Clugston wrote:
> That's brilliant. It means you have automatic compression of trailing zero bits. I guess if you strip off the "0x1.", you get rid of the problem with the formats which use another character like "0xA." instead.
> I presume it will have either the length at the front like an Lname, or else some character as a delimiter?

It doesn't need a delimiter, as it ends in a P followed by the exponent in decimal.

Walter Bright wrote:
> Don Clugston wrote:
>> That's brilliant. It means you have automatic compression of trailing zero bits. I guess if you strip off the "0x1.", you get rid of the problem with the formats which use another character like "0xA." instead.
>> I presume it will have either the length at the front like an Lname, or else some character as a delimiter?
> 
> It doesn't need a delimiter, as it ends in a P followed by the exponent in decimal.

How can you tell when the exponent has ended? At least for complex arguments, the next thing after the exponent will be the mantissa of the next number, which could look exactly like a decimal number, so it's not enough to just check for a non-digit character.
(If the next thing was an Lname, there'd also be consecutive ASCII digits, but that seems to be impossible, so maybe complex numbers are the only problem case).

Don Clugston wrote:
> Walter Bright wrote:
>> Don Clugston wrote:
>>> That's brilliant. It means you have automatic compression of trailing zero bits. I guess if you strip off the "0x1.", you get rid of the problem with the formats which use another character like "0xA." instead.
>>> I presume it will have either the length at the front like an Lname, or else some character as a delimiter?
>>
>> It doesn't need a delimiter, as it ends in a P followed by the exponent in decimal.
> 
> How can you tell when the exponent has ended? At least for complex arguments, the next thing after the exponent will be the mantissa of the next number, which could look exactly like a decimal number, so it's not enough to just check for a non-digit character.

It just inserts another 'c'.

> (If the next thing was an Lname, there'd also be consecutive ASCII digits, but that seems to be impossible, so maybe complex numbers are the only problem case).

The next character has to be a non-digit.