www.digitalmars.com         C & C++   DMDScript  

D.gnu - x32-abi with D?

reply "Franz" <franz.sass gmx.de> writes:
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
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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
parent reply Trass3r <un known.com> writes:
 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
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 26 May 2012 13:59, Alex R=F8nne Petersen <alex lycus.org> wrote:

 On 26-05-2012 14:06, Alex R=F8nne 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.


--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
May 26 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
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
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
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
parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
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 26 2012
parent Jacob Carlborg <doob me.com> writes:
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
May 27 2012