• Daniel <murpsoft hotmail.com> Apr 03 2008
• BCS <BCS pathlink.com> Apr 03 2008
• "Neil Vice" <sardonicpresence gmail.com> Apr 03 2008
• Christopher Wright <dhasenan gmail.com> Apr 03 2008
• downs <default_357-line yahoo.de> Apr 04 2008
• Daniel <murpsoft hotmail.com> Apr 04 2008
• Fawzi Mohamed <fmohamed mac.com> Apr 04 2008
• Robert Fraser <fraserofthenight gmail.com> Apr 04 2008
• BCS <BCS pathlink.com> Apr 04 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Apr 04 2008
• e-t172 <e-t172 akegroup.org> Apr 04 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Apr 04 2008
• Lars Ivar Igesund <larsivar igesund.net> Apr 05 2008
• lutger <lutger.blijdestijn gmail.com> Apr 05 2008

Daniel <murpsoft hotmail.com> writes:

I don't mean to rain on anyone's parade, but I'm noticing a livelock priority
inversion in the forums.  Everyone's spending months arguing about constness,
when there are clear, simple, and higher priority issues to resolve.

1) The x86-32 platform is obsolete, and D still can't run x86-64, and only
supports SSE if you hand code it in assembler.  One step away from being
targetted to 16-bit x286.  x86-64 has been out for a 5 years now.

2) Compiling a program with extern (C) main(){ return 1; } still doesn't let
you cut the excess 80kb of fat.  I don't care what's in there, it needs to be
included "on use".

I can't use D at work, and don't use it at home, until these issues are
resolved.

BCS <BCS pathlink.com> writes:

Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock
 priority inversion in the forums.  Everyone's spending months arguing
 about constness, when there are clear, simple, and higher priority
 issues to resolve.


I've noticed the same thing, I long ago (back about the time 2.000 came 
out) stopped reading const threads because I realized, I don't care. 
I'll let other's trash it out and then use it when it's done.

 1) The x86-32 platform is obsolete, and D still can't run x86-64, 


x86-32 may be obsolete, but it's still fairly viable.

OTOH, your point is a good one, there are things that could use some TLC.

"Neil Vice" <sardonicpresence gmail.com> writes:

"Daniel" <murpsoft hotmail.com> wrote in message 
news:ft3rca$2se3$1 digitalmars.com...
 I don't mean to rain on anyone's parade, but I'm noticing a livelock 
 priority inversion in the forums.  Everyone's spending months arguing 
 about constness, when there are clear, simple, and higher priority issues 
 to resolve.

 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only 
 supports SSE if you hand code it in assembler.  One step away from being 
 targetted to 16-bit x286.  x86-64 has been out for a 5 years now.

 2) Compiling a program with extern (C) main(){ return 1; } still doesn't 
 let you cut the excess 80kb of fat.  I don't care what's in there, it 
 needs to be included "on use".

 I can't use D at work, and don't use it at home, until these issues are 
 resolved.


The thing is that these are features of the compiler and linker not the 
language. My impression is that the DMD back-end is legacy and fairly 
static, though I could well be wrong.

GDC is an obvious solution to this, but requires regular maintenance of the 
"glue" code. I'm honestly not sure what the status of GDC is though the 
sourceforge page hasn't had a news since 22/08/07 and the last front-end 
version refered to is 1.00.

This is a project I wouldn't mind working on myself, though I'm not used to 
open-source collaborative development and feel that the original GDC 
developer should certainly be involved in some way.

On another note, the usability of const is quite important to me and I don't 
think that discussion of ideas for future language features should be 
considered a bad thing. If Walter's direction is to further develop the 
language spec then perhaps it is up to others to take his open-source 
front-end and attach it to an existing back-end to fix these long-standard 
(and probably not trivial) issues. 

Christopher Wright <dhasenan gmail.com> writes:

Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock priority
inversion in the forums.  Everyone's spending months arguing about constness,
when there are clear, simple, and higher priority issues to resolve.
 
 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only
supports SSE if you hand code it in assembler.  One step away from being
targetted to 16-bit x286.  x86-64 has been out for a 5 years now.
 
 2) Compiling a program with extern (C) main(){ return 1; } still doesn't let
you cut the excess 80kb of fat.  I don't care what's in there, it needs to be
included "on use".
 
 I can't use D at work, and don't use it at home, until these issues are
resolved.


People are used to Java and .NET, with megabytes of overhead. Anyone 
considering D for x86 processors probably doesn't care about 80kb extra 
cruft. Or probably shouldn't.

If you're trying to use D on embedded devices, though, it's an issue. 
But these days, even embedded systems have 32MB of RAM.

downs <default_357-line yahoo.de> writes:

Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock priority
inversion in the forums.  Everyone's spending months arguing about constness,
when there are clear, simple, and higher priority issues to resolve.


Agreed.

 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only
supports SSE if you hand code it in assembler.  One step away from being
targetted to 16-bit x286.  x86-64 has been out for a 5 years now.


I've managed to make autovectorization (automatic SSE generation from loops)
work in a highly experimental version of GDC 4.2.3, with lots of help from IRC.

I'll post a patch in a while, with HUGE "experimental" stickers (want to get
the stress test results first), but it works in principle.

Also, all of tools should in theory work on 64-bit (even the assembler stuff) -
I'll test it in a few days on a new box I'm putting together.

GDC also generates faster code than DMD in many cases :)

 --feep

Daniel <murpsoft hotmail.com> writes:

downs Wrote:

 Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock priority
inversion in the forums.  Everyone's spending months arguing about constness,
when there are clear, simple, and higher priority issues to resolve.


 Agreed.
 
 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only
supports SSE if you hand code it in assembler.  One step away from being
targetted to 16-bit x286.  x86-64 has been out for a 5 years now.


 I've managed to make autovectorization (automatic SSE generation from loops)
work in a highly experimental version of GDC 4.2.3, with lots of help from IRC.
 
 I'll post a patch in a while, with HUGE "experimental" stickers (want to get
the stress test results first), but it works in principle.
 
 Also, all of tools should in theory work on 64-bit (even the assembler stuff)
- I'll test it in a few days on a new box I'm putting together.
 
 GDC also generates faster code than DMD in many cases :)
 
  --feep


Cool stuff, downs.  Looks like it'll be the GDC then for all my future
language-based programming.  Now I just need to throw together another x86-64
Linux again somewhere.

Fawzi Mohamed <fmohamed mac.com> writes:

On 2008-04-04 10:24:30 +0200, downs <default_357-line yahoo.de> said:

 Daniel wrote:
 I don't mean to rain on anyone's parade, but I'm noticing a livelock 
 priority inversion in the forums.  Everyone's spending months arguing 
 about constness, when there are clear, simple, and higher priority 
 issues to resolve.


 Agreed.


ok, that was my impression too, but I fear that in the end I also 
contribued to it :)

 1) The x86-32 platform is obsolete, and D still can't run x86-64, and 
 only supports SSE if you hand code it in assembler.  One step away from 
 being targetted to 16-bit x286.  x86-64 has been out for a 5 years now.




I use x86-64 with gdc and both phobos and tango.
I had some issues setting up everything, but using svn version 
everything (but SSE) should work

 I've managed to make autovectorization (automatic SSE generation from 
 loops) work in a highly experimental version of GDC 4.2.3, with lots of 
 help from IRC.


great news!

Fawzi

 I'll post a patch in a while, with HUGE "experimental" stickers (want 
 to get the stress test results first), but it works in principle.
 
 Also, all of tools should in theory work on 64-bit (even the assembler 
 stuff) - I'll test it in a few days on a new box I'm putting together.
 
 GDC also generates faster code than DMD in many cases :)
 
  --feep

Robert Fraser <fraserofthenight gmail.com> writes:

downs wrote:
 GDC also generates faster code than DMD in many cases :)


There are a fair few cases where the opposite is true, too.

BCS <BCS pathlink.com> writes:

Robert Fraser wrote:
 downs wrote:
 
 GDC also generates faster code than DMD in many cases :)


 
 There are a fair few cases where the opposite is true, too.


are the calling conventions compatible? Could the app be compiled twice 
and then pick and choose what object file to pull each function from? 
(Yes I know this is "a bad idea" but it would be kinda "fun")

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Daniel" wrote
 I don't mean to rain on anyone's parade, but I'm noticing a livelock 
 priority inversion in the forums.  Everyone's spending months arguing 
 about constness, when there are clear, simple, and higher priority issues 
 to resolve.


It all depends on your priorities :)  Mine is to make sure D2 will be 
adopted by Tango, and for that, const needs to be reasonable.

 1) The x86-32 platform is obsolete, and D still can't run x86-64, and only 
 supports SSE if you hand code it in assembler.  One step away from being 
 targetted to 16-bit x286.  x86-64 has been out for a 5 years now.


I'd hazard to guess that 90% of software developers couldn't care less.  If 
I have an x86-64 platform, I have no idea, I just know the compiler makes 
code and it runs :)  And my computer is only a year old, so it probably is 
an x86-64.  IMO, this should be a low priority item, as it has nothing to do 
with the language, it's a compiler issue.

 2) Compiling a program with extern (C) main(){ return 1; } still doesn't 
 let you cut the excess 80kb of fat.  I don't care what's in there, it 
 needs to be included "on use".


Again, compiler not language.  But I think this one is really important, as 
nobody likes bloat, and really, OS's have been using dynamic loading code 
for over a decade...

-Steve 

e-t172 <e-t172 akegroup.org> writes:

Steven Schveighoffer a écrit :
 I'd hazard to guess that 90% of software developers couldn't care less.  If 
 I have an x86-64 platform, I have no idea, I just know the compiler makes 
 code and it runs :)  And my computer is only a year old, so it probably is 


Imagine you want to compile a program for a Debian x86_64 (or any other 
64bit distribution). Problem is, you can't link a 32bit program to 64bit 
libraries. So if you want to link your D program to third party C 
libraries, you're basically screwed. Therefore, I think they care, actually.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"e-t172" wrote
 Steven Schveighoffer a écrit :
 I'd hazard to guess that 90% of software developers couldn't care less. 
 If I have an x86-64 platform, I have no idea, I just know the compiler 
 makes code and it runs :)  And my computer is only a year old, so it 
 probably is


 Imagine you want to compile a program for a Debian x86_64 (or any other 
 64bit distribution). Problem is, you can't link a 32bit program to 64bit 
 libraries. So if you want to link your D program to third party C 
 libraries, you're basically screwed. Therefore, I think they care, 
 actually.


I didn't realize this was the case, so it's not as much a non-issue as I 
thought.  But I think you might be in the minority, there are still plenty 
of actively developed 32-bit OSes for Intel processors, so the suggestion 
that D is focusing on a platform as dead as 286s is grossly false.

Besides that point, there is no reason that we can't have discussions on the 
NG about language features AND have other people port the D compiler to 
x86_64.  AFAIK, gdc is open source and you are welcome to try and port it.

-Steve 

Lars Ivar Igesund <larsivar igesund.net> writes:

Steven Schveighoffer wrote:

 "e-t172" wrote
 Steven Schveighoffer a écrit :
 I'd hazard to guess that 90% of software developers couldn't care less.
 If I have an x86-64 platform, I have no idea, I just know the compiler
 makes code and it runs :)  And my computer is only a year old, so it
 probably is


 Imagine you want to compile a program for a Debian x86_64 (or any other
 64bit distribution). Problem is, you can't link a 32bit program to 64bit
 libraries. So if you want to link your D program to third party C
 libraries, you're basically screwed. Therefore, I think they care,
 actually.


 I didn't realize this was the case, so it's not as much a non-issue as I
 thought.  But I think you might be in the minority, there are still plenty
 of actively developed 32-bit OSes for Intel processors, so the suggestion
 that D is focusing on a platform as dead as 286s is grossly false.
 
 Besides that point, there is no reason that we can't have discussions on
 the NG about language features AND have other people port the D compiler
 to
 x86_64.  AFAIK, gdc is open source and you are welcome to try and port it.


And as far as I know, GDC is pretty stable on x86_64, although not 100%
conforming with the D spec.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

lutger <lutger.blijdestijn gmail.com> writes:

e-t172 wrote:

 Steven Schveighoffer a écrit :
 I'd hazard to guess that 90% of software developers couldn't care less. 
 If I have an x86-64 platform, I have no idea, I just know the compiler
 makes
 code and it runs :)  And my computer is only a year old, so it probably
 is


 Imagine you want to compile a program for a Debian x86_64 (or any other
 64bit distribution). Problem is, you can't link a 32bit program to 64bit
 libraries. So if you want to link your D program to third party C
 libraries, you're basically screwed. Therefore, I think they care,
 actually.


You can link a 32-bit program to 32-bit libraries and run them on a 64-bit
operating system. I develop on a 64-bit OS with dmd and while it's
sometimes a bit funny to locate and install 32-bit development libraries,
it is quite  doable. For making true 64-bit binaries, GDC is there. The
only bummer I think is that the inline assembler is still stuck on 32-bit
even with GDC?

Well this is with linux, I suppose it is possible for windows too?

Though I think everybody would like to see a 64-bit dmd and a rewrite of
optlink especially, I don't see how this could take priority above the
development of the D language. And const currently is the main thing,
saying it is not a high-priority is like saying 'stop Walter, you're done'.
You can disagree with the const design, but that's a different argument
altogether.