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 next 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
prev sibling parent Heinz <billgates microsoft.com> 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.


Great lib. Anyway, thanks for everyone who reply me, i'm now really in the
right direction, i was so confused hahahaha(writing addresses). I implemented
in my program simple read()/write() from the stream class and runs like a
wonder!

Bye :)
Jan 20 2007