January 31, 2012
On 30/01/2012 16:00, Timon Gehr wrote:
> On 01/30/2012 03:59 AM, H. S. Teoh wrote:
>> On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
>>> On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
>>>> long double is 128-bit.
>>>
>>> Sort of. It's 80 bits of useful data with 48 bits of unused padding.
>>
>> Really?! Ugh. Hopefully D handles it better?
>>
>> T
>
> It is what the x86 hardware supports.

As I try it, real.sizeof == 10.  And by According to DMC 8.42n (where is 8.52?), sizeof(long double) == 10 as well.

Stewart.
January 31, 2012
On 29/01/2012 01:17, Alex Rønne Petersen wrote:
> Hi,
>
> Are there any current plans to implement cent and ucent?
<snip>

Whether it's implemented any time soon or not, it's high time the _syntax_ allowed their use as basic types for forward/backward compatibility's sake.
http://d.puremagic.com/issues/show_bug.cgi?id=785

Stewart.
January 31, 2012
Am 31.01.2012, 16:07 Uhr, schrieb Stewart Gordon <smjg_1998@yahoo.com>:

> On 30/01/2012 16:00, Timon Gehr wrote:
>> On 01/30/2012 03:59 AM, H. S. Teoh wrote:
>>> On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
>>>> On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
>>>>> long double is 128-bit.
>>>>
>>>> Sort of. It's 80 bits of useful data with 48 bits of unused padding.
>>>
>>> Really?! Ugh. Hopefully D handles it better?
>>>
>>> T
>>
>> It is what the x86 hardware supports.
>
> As I try it, real.sizeof == 10.  And by According to DMC 8.42n (where is 8.52?), sizeof(long double) == 10 as well.
>
> Stewart.

	pragma(msg, real.sizeof);

Prints the expected platform alignment for me:

DMD64 / GDC64: 16LU
DMD32:         12LU
February 01, 2012
On 31/01/2012 18:47, Marco Leise wrote:
<snip>
> pragma(msg, real.sizeof);

Prints 10u for me (2.057, Win32).

> Prints the expected platform alignment for me:
>
> DMD64 / GDC64: 16LU
> DMD32: 12LU

That isn't alignment, that's padding built into the type.  I assume you're testing on Linux.  I've heard before that long double/real is 12 bytes under Linux because it includes 2 bytes of padding.  I don't know why Linux does it that way, but there you go.

Stewart.
February 01, 2012
On 1/31/2012 4:28 PM, Stewart Gordon wrote:
> That isn't alignment, that's padding built into the type. I assume you're
> testing on Linux. I've heard before that long double/real is 12 bytes under
> Linux because it includes 2 bytes of padding. I don't know why Linux does it
> that way, but there you go.

Both the alignment and padding of reals changes from platform to platform.
February 01, 2012
On 1/30/2012 9:06 AM, Marco Leise wrote:
> "On the x86 architecture, most compilers implement long double as the 80-bit
> extended precision type supported by that hardware (sometimes stored as 12 or 16
> bytes to maintain data structure alignment)."
>
> That's all there is to know I think.

10 bytes on Windows.

Anyhow, as far as the C ABI goes (which is what this is),

"Ours is not to Reason Why, Ours is to Implement or Fail."
February 01, 2012
On 31 January 2012 18:47, Marco Leise <Marco.Leise@gmx.de> wrote:
> Am 31.01.2012, 16:07 Uhr, schrieb Stewart Gordon <smjg_1998@yahoo.com>:
>
>
>> On 30/01/2012 16:00, Timon Gehr wrote:
>>>
>>> On 01/30/2012 03:59 AM, H. S. Teoh wrote:
>>>>
>>>> On Sun, Jan 29, 2012 at 05:48:40PM -0800, Walter Bright wrote:
>>>>>
>>>>> On 1/29/2012 2:26 PM, Jonathan M Davis wrote:
>>>>>>
>>>>>> long double is 128-bit.
>>>>>
>>>>>
>>>>> Sort of. It's 80 bits of useful data with 48 bits of unused padding.
>>>>
>>>>
>>>> Really?! Ugh. Hopefully D handles it better?
>>>>
>>>> T
>>>
>>>
>>> It is what the x86 hardware supports.
>>
>>
>> As I try it, real.sizeof == 10.  And by According to DMC 8.42n (where is
>> 8.52?), sizeof(long double) == 10 as well.
>>
>> Stewart.
>
>
>        pragma(msg, real.sizeof);
>
> Prints the expected platform alignment for me:
>
> DMD64 / GDC64: 16LU

It varies from platform to platform, and depending on what target flags you pass to GDC.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
March 29, 2012
Le 29/01/2012 02:17, Alex Rønne Petersen a écrit :
>
> Are there any current plans to implement cent and ucent?
>

I implemented cent and ucent as a library, using division algorithm from Ian Kaplan.

https://github.com/p0nce/gfm/blob/master/math/softcent.d

Suggestions welcome.
1 2 3 4
Next ›   Last »