www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - More ABI changes

reply Walter Bright <newshound digitalmars.com> writes:
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.
Dec 04 2006
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
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.
Dec 04 2006
next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
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
Dec 04 2006
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Dec 05 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
Dec 04 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Dec 05 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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?
Dec 05 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Dec 06 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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).
Dec 06 2006
parent Walter Bright <newshound digitalmars.com> writes:
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.
Dec 06 2006