View mode: basic / threaded / horizontal-split · Log in · Help
May 26, 2012
x32-abi with D?
I was planning to install FreeBSD, but I was wondering if 
x32-abi(i.e. x86-64 but using fast 32bit pointers) is a supported 
configuration together with D in linux using the D gnu compiler, 
then it would be the incentive to go linux instead.

if not supported, is it planned to be supported?
May 26, 2012
Re: x32-abi with D?
On 26 May 2012 11:00, Franz <franz.sass@gmx.de> wrote:
> I was planning to install FreeBSD, but I was wondering if x32-abi(i.e.
> x86-64 but using fast 32bit pointers) is a supported configuration together
> with D in linux using the D gnu compiler, then it would be the incentive to
> go linux instead.
>
> if not supported, is it planned to be supported?
>


The compiler is able to cope.  Have made some updates to the D runtime
and Phobos library to weed out any issues relating to such platforms
(NaCL is another system which uses 32bit pointers on x86_64 arch),
though I'm not aware of the current working state.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
May 26, 2012
Re: x32-abi with D?
> The compiler is able to cope.  Have made some updates to the D runtime
> and Phobos library to weed out any issues relating to such platforms
> (NaCL is another system which uses 32bit pointers on x86_64 arch),

Should go into upstream druntime shouldn't it?
May 26, 2012
Re: x32-abi with D?
On 26-05-2012 14:03, Trass3r wrote:
>> The compiler is able to cope. Have made some updates to the D runtime
>> and Phobos library to weed out any issues relating to such platforms
>> (NaCL is another system which uses 32bit pointers on x86_64 arch),
>
> Should go into upstream druntime shouldn't it?

No, druntime is compiler-specific. Phobos is a different story.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 26, 2012
Re: x32-abi with D?
On 26-05-2012 14:06, Alex Rønne Petersen wrote:
> On 26-05-2012 14:03, Trass3r wrote:
>>> The compiler is able to cope. Have made some updates to the D runtime
>>> and Phobos library to weed out any issues relating to such platforms
>>> (NaCL is another system which uses 32bit pointers on x86_64 arch),
>>
>> Should go into upstream druntime shouldn't it?
>
> No, druntime is compiler-specific. Phobos is a different story.
>

Speaking of which, Iain, any way we could upstream all of GDC's Phobos 
changes? (Perhaps same way you did it with DMD?)

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 26, 2012
Re: x32-abi with D?
On 26 May 2012 13:59, Alex Rønne Petersen <alex@lycus.org> wrote:
> On 26-05-2012 14:06, Alex Rønne Petersen wrote:
>>
>> On 26-05-2012 14:03, Trass3r wrote:
>>>>
>>>> The compiler is able to cope. Have made some updates to the D runtime
>>>> and Phobos library to weed out any issues relating to such platforms
>>>> (NaCL is another system which uses 32bit pointers on x86_64 arch),
>>>
>>>
>>> Should go into upstream druntime shouldn't it?
>>
>>
>> No, druntime is compiler-specific. Phobos is a different story.
>>
>
> Speaking of which, Iain, any way we could upstream all of GDC's Phobos
> changes? (Perhaps same way you did it with DMD?)
>
>

You could try, but I can't think of any changes that would be
considered suitable for upstreaming. To list notable differences off
the top of my head:

- void* is replaced with va_list where appropriate.
- some version code to whom's identifiers are only emitted from the
gdc compiler.
- some functions in std.math call the long double rather than double
math lib functions.
- std.format.doFormat has some difference for consideration that the
va_list varies on differing architectures.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
May 26, 2012
Re: x32-abi with D?
On 26-05-2012 15:43, Iain Buclaw wrote:
> On 26 May 2012 13:59, Alex Rønne Petersen<alex@lycus.org>  wrote:
>> On 26-05-2012 14:06, Alex Rønne Petersen wrote:
>>>
>>> On 26-05-2012 14:03, Trass3r wrote:
>>>>>
>>>>> The compiler is able to cope. Have made some updates to the D runtime
>>>>> and Phobos library to weed out any issues relating to such platforms
>>>>> (NaCL is another system which uses 32bit pointers on x86_64 arch),
>>>>
>>>>
>>>> Should go into upstream druntime shouldn't it?
>>>
>>>
>>> No, druntime is compiler-specific. Phobos is a different story.
>>>
>>
>> Speaking of which, Iain, any way we could upstream all of GDC's Phobos
>> changes? (Perhaps same way you did it with DMD?)
>>
>>
>
> You could try, but I can't think of any changes that would be
> considered suitable for upstreaming. To list notable differences off
> the top of my head:
>
> - void* is replaced with va_list where appropriate.
> - some version code to whom's identifiers are only emitted from the
> gdc compiler.
> - some functions in std.math call the long double rather than double
> math lib functions.
> - std.format.doFormat has some difference for consideration that the
> va_list varies on differing architectures.
>
>

Well, I'm just asking because recently in the Phobos pull request where 
I wanted to *remove* compiler-specific code, everyone was against this. 
But at the same time, we seem to have this weird situation where 
everyone has their own Phobos fork *anyway*. The situation is just 
messy... we need to clean up the confusion somehow.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 26, 2012
Re: x32-abi with D?
On 5/26/2012 5:06 AM, Alex Rønne Petersen wrote:
> On 26-05-2012 14:03, Trass3r wrote:
>>> The compiler is able to cope. Have made some updates to the D runtime
>>> and Phobos library to weed out any issues relating to such platforms
>>> (NaCL is another system which uses 32bit pointers on x86_64 arch),
>>
>> Should go into upstream druntime shouldn't it?
> 
> No, druntime is compiler-specific. Phobos is a different story.

I've always disagreed with this stance.  _parts_ of druntime are specific to the compiler/runtime interface, but MOST of
it isn't and shouldn't be compiler specific.  The closer the various compilers' runtime's are to the same the better the
ecosystem will be, imho.

So, I encourage pushing changes upstream.

Later,
Brad
May 26, 2012
Re: x32-abi with D?
On 26-05-2012 21:05, Brad Roberts wrote:
> On 5/26/2012 5:06 AM, Alex Rønne Petersen wrote:
>> On 26-05-2012 14:03, Trass3r wrote:
>>>> The compiler is able to cope. Have made some updates to the D runtime
>>>> and Phobos library to weed out any issues relating to such platforms
>>>> (NaCL is another system which uses 32bit pointers on x86_64 arch),
>>>
>>> Should go into upstream druntime shouldn't it?
>>
>> No, druntime is compiler-specific. Phobos is a different story.
>
> I've always disagreed with this stance.  _parts_ of druntime are specific to the compiler/runtime interface, but MOST of
> it isn't and shouldn't be compiler specific.  The closer the various compilers' runtime's are to the same the better the
> ecosystem will be, imho.
>
> So, I encourage pushing changes upstream.
>
> Later,
> Brad
>
>

The result is that contributors won't have a clue where to go with their 
compiler- or arch-specific patches because upstream and downstream are 
almost constantly out of sync. And it's unlikely that anyone wants to 
actually spend the time on upstreaming the downstream druntime changes 
in the first place...

Besides, upstreaming the downstream changes doesn't seem to have any 
obvious gain: Upstream druntime is really only for DMD (x86-32/64) and a 
few operating systems running on that architecture, and any downstream 
changes are usually to support either the GDC compiler (think 
__builtin_*) or to support architectures or operating systems that DMD 
doesn't.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 27, 2012
Re: x32-abi with D?
On 2012-05-26 21:20, Alex Rønne Petersen wrote:

> The result is that contributors won't have a clue where to go with their
> compiler- or arch-specific patches because upstream and downstream are
> almost constantly out of sync. And it's unlikely that anyone wants to
> actually spend the time on upstreaming the downstream druntime changes
> in the first place...
>
> Besides, upstreaming the downstream changes doesn't seem to have any
> obvious gain: Upstream druntime is really only for DMD (x86-32/64) and a
> few operating systems running on that architecture, and any downstream
> changes are usually to support either the GDC compiler (think
> __builtin_*) or to support architectures or operating systems that DMD
> doesn't.

If something is pushed upstream other compilers (GDC, LDC) can 
potentially share it.

I think that anything that isn't compiler specific but is for a platform 
DMD doesn't support should be pushed upstream. It will help other compilers.

-- 
/Jacob Carlborg
Top | Discussion index | About this forum | D home