December 27, 2008
Nick Sabalausky wrote:
> "Nick Sabalausky" <a@a.a> wrote in message news:gj1olu$1390$1@digitalmars.com...
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gj0qht$2lc1$1@digitalmars.com...
>>> What platforms for dmd would you be most interested in using?
>>>
>>> .net
>>> jvm
>>> mac osx 32 bit intel
>>> mac osx 64 bit intel
>>> linux 64 bit
>>> windows 64 bit
>>> freebsd 32 bit
>>> netbsd 32 bit
>>>
>>> other?
>> - ARM7/ARM9
>> - Other misc microcontrollers, like Parallax's Propeller
>> - Mac osx 32 bit intel
>> - *maybe* bsd 32-bit, .net and jvm (and with .net and jvm I'd want to still be able to use tango and phobos, and not be forced to switch to the .net and jvm standard libs)
> 
> To elaborate:
> 
> 1. A "systems language" that doesn't compile to any embedded microcontroller seems more than a little bit silly to me. (Sad as it is to say, I don't think GDC counts anymore.)
> 
> 2. I have absolutely zero interest in 64-bit. To the people annoyed at the limitations of the 32-bit address space: What in the world are you working on? Non-linear video editors and 3D modeling packages?

I have to say I'm appalled by this, particularly coming from someone who ought to know better. Should we really settle our ambitions with computers to glorified typewriters, networking tools, and the such?

Andrei
December 27, 2008
Michel Fortin wrote:
> (Not that I expect to see DMD generate PowerPC code in a near future.)

There was a ppc code generator at one time, but it got lost.
December 27, 2008
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gj5r9e$dom$1@digitalmars.com...
> Nick Sabalausky wrote:
>> "Nick Sabalausky" <a@a.a> wrote in message news:gj1olu$1390$1@digitalmars.com...
>>> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:gj0qht$2lc1$1@digitalmars.com...
>>>> What platforms for dmd would you be most interested in using?
>>>>
>>>> .net
>>>> jvm
>>>> mac osx 32 bit intel
>>>> mac osx 64 bit intel
>>>> linux 64 bit
>>>> windows 64 bit
>>>> freebsd 32 bit
>>>> netbsd 32 bit
>>>>
>>>> other?
>>> - ARM7/ARM9
>>> - Other misc microcontrollers, like Parallax's Propeller
>>> - Mac osx 32 bit intel
>>> - *maybe* bsd 32-bit, .net and jvm (and with .net and jvm I'd want to
>>> still be able to use tango and phobos, and not be forced to switch to
>>> the .net and jvm standard libs)
>>
>> To elaborate:
>>
>> 1. A "systems language" that doesn't compile to any embedded microcontroller seems more than a little bit silly to me. (Sad as it is to say, I don't think GDC counts anymore.)
>>
>> 2. I have absolutely zero interest in 64-bit. To the people annoyed at the limitations of the 32-bit address space: What in the world are you working on? Non-linear video editors and 3D modeling packages?
>
> I have to say I'm appalled by this, particularly coming from someone who ought to know better. Should we really settle our ambitions with computers to glorified typewriters, networking tools, and the such?
>

I never said D shouldn't have 64-bit support, I just don't personally have any interest in it. I've done a lot of work on "low-end" systems and older platforms, and frankly *I'm* appalled by how much a lot of developers underestimate a piece of hardware just because it isn't the latest and greatest (and most expensive). Like I indicated, I'm well aware that there are legitimate applications for 64-bit, such as non-linear video editing and 3D modeling (and DBs, servers, and *with caveats* certain types of gaming.) But first of all, I haven't been working on such things, hence my lack of personal interest. And secondly, judging by number of people here asking for 64-bit, I find it highly unlikely that most of them have plans to work on such things either.


December 27, 2008
On Sat, 27 Dec 2008 15:45:57 -0500, Nick Sabalausky wrote:

> ... judging by number of people here asking for 64-bit, I find it highly unlikely that most of them have plans to work on such things either.

My interest in 64-bit hardware support is based on the belief that before too long, buying a new 32-bit platform might be a difficult thing to do. Five years from now, I don't want to be forced into finding a good second-hand machine just so I can work with D.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
December 27, 2008
"Derek Parnell" <derek@psych.ward> wrote in message news:nkr1wyvyj3vv$.qr1gd1h779fx.dlg@40tude.net...
> On Sat, 27 Dec 2008 15:45:57 -0500, Nick Sabalausky wrote:
>
>> ... judging by number of people here asking for
>> 64-bit, I find it highly unlikely that most of them have plans to work on
>> such things either.
>
> My interest in 64-bit hardware support is based on the belief that before too long, buying a new 32-bit platform might be a difficult thing to do. Five years from now, I don't want to be forced into finding a good second-hand machine just so I can work with D.
>

I don't want to be forced into buying a new 64-bit machine just because a whole bunch of "gotta have the faciest stuff out there" people have deemed 32-bit insufficient for all computing needs. Besides, can't 64-bit machines run 32-bit code?


December 27, 2008
Nick Sabalausky wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:nkr1wyvyj3vv$.qr1gd1h779fx.dlg@40tude.net...
>> On Sat, 27 Dec 2008 15:45:57 -0500, Nick Sabalausky wrote:
>>
>>> ... judging by number of people here asking for
>>> 64-bit, I find it highly unlikely that most of them have plans to work on
>>> such things either.
>> My interest in 64-bit hardware support is based on the belief that before
>> too long, buying a new 32-bit platform might be a difficult thing to do.
>> Five years from now, I don't want to be forced into finding a good
>> second-hand machine just so I can work with D.
>>
> 
> I don't want to be forced into buying a new 64-bit machine just because a whole bunch of "gotta have the faciest stuff out there" people have deemed 32-bit insufficient for all computing needs. Besides, can't 64-bit machines run 32-bit code? 

Related: a rant of Knuth to be found at http://www-cs-faculty.stanford.edu/~knuth/news.html.

===============================
A Flame About 64-bit Pointers

It is absolutely idiotic to have 64-bit pointers when I compile a program that uses less than 4 gigabytes of RAM. When such pointer values appear inside a struct, they not only waste half the memory, they effectively throw away half of the cache.

The gcc manpage advertises an option "-mlong32" that sounds like what I want. Namely, I think it would compile code for my x86-64 architecture, taking advantage of the extra registers etc., but it would also know that my program is going to live inside a 32-bit virtual address space.

Unfortunately, the -mlong32 option was introduced only for MIPS computers, years ago. Nobody has yet adopted such conventions for today's most popular architecture. Probably that happens because programs compiled with this convention will need to be loaded with a special version of libc.

Please, somebody, make that possible.
===============================

In my opinion, it's not application pressure that drives 64-bit machine adoption, now or in the near future. It's RAM price, availability, and usefulness. A 32-bit machine cannot gainfully have more than 4GB of RAM, period. That's an awful limitation in wake of increased OS and application demands and falling RAM prices. So people don't migrate to 64 bits just because a whole bunch of "gotta have the fanciest stuff out there". They migrate (often without even knowing it) just because they want more RAM. And they want more RAM because machines with more RAM often run smoother and faster.


Andrei
December 27, 2008
Nick Sabalausky wrote:
> "Derek Parnell"<derek@psych.ward>  wrote in message
> news:nkr1wyvyj3vv$.qr1gd1h779fx.dlg@40tude.net...
>> On Sat, 27 Dec 2008 15:45:57 -0500, Nick Sabalausky wrote:
>>
>>> ... judging by number of people here asking for
>>> 64-bit, I find it highly unlikely that most of them have plans to work on
>>> such things either.
>> My interest in 64-bit hardware support is based on the belief that before
>> too long, buying a new 32-bit platform might be a difficult thing to do.
>> Five years from now, I don't want to be forced into finding a good
>> second-hand machine just so I can work with D.
>>
>
> I don't want to be forced into buying a new 64-bit machine just because a
> whole bunch of "gotta have the faciest stuff out there" people have deemed
> 32-bit insufficient for all computing needs. Besides, can't 64-bit machines
> run 32-bit code?
>
>
two things:
a) current hardware is 64bit (if you go and buy a PC), so supporting 64bit is just supporting the current technology. it's not about fancy servers or anything like that, just supporting the current standards. that's a minimun that should be expected from any compiler implementation nowadays.
b) even though for now there is a compatability mode in most OSes, why would I want to limit the performance and abilities of my PC to old technology which is being faded away?
64bit machines can run old *legacy* software which is 32bit, but that doesn't mean *new* software should be written as 32 bit.

no one forcing you to buy a new PC and DMD will continue to support 32bit for a long time, I presume. but you cannot force people who did buy a new PC in the last few *years* to be limited to your old ancient hardware.

One last thing, you can always continue using an older version of the compiler even if Walter drops support for 32bit in later versions. In any case, you don't have any valid reason to object to 64bit support.
December 27, 2008
Reply to Andrei,

> In my opinion, it's not application pressure that drives 64-bit
> machine adoption, now or in the near future. It's RAM price,
> availability, and usefulness. A 32-bit machine cannot gainfully have
> more than 4GB of RAM, period.

IIRC 32 bit Intel chips can address more like 64GB of RAM (I can't find the ref but I seem to recall about 4 extra address bits). It's just virtual address spaces that are limited to 4GB (or 2-3GB after the OS takes it's pound of flesh) 

As pointed out, only a few apps need anything near 2GB of RAM per process.

> That's an awful limitation in wake of
> increased OS and application demands and falling RAM prices. So people
> don't migrate to 64 bits just because a whole bunch of "gotta have the
> fanciest stuff out there". They migrate (often without even knowing
> it) just because they want more RAM. And they want more RAM because
> machines with more RAM often run smoother and faster.
> 
> Andrei
> 


December 28, 2008
.NET

But *only* if D had a way to fully support RAII. Otherwise, I'd just as soon use C#. I don't know if there is some technical reason why this couldn't be done. But I think C# and Java missed the ball on that. To me, the biggest pain in C# is that I need to implement Dispose and remember to call it. So D might have an advantage if it could do this better.

I should add that maybe my vote shouldn't count as much because I don't regularly use D at the moment although I like the language and I follow the newsgroup. I normally use C# when I can and C++ when I have to, the latter being 85% of the time at work. For our core product, we need to support Windows 32 and 64-bit, Linux, Mac, WinCE (x86 and ARM). And we need to export a C API. The only choice really is C++. I have to be honest, using D there would be a hard sell.:-( But for our peripheral projects, like utility apps and stuff, almost anything could be used. It's then a matter of getting fellow coworkers to agree to use a different language, which they usually would rather not do unfortunately.

If implementing D on .NET does nothing but increase its visibility as a legitimate language choice, then maybe it's a good thing.

Jim


December 28, 2008
"Yigal Chripun" <yigal100@gmail.com> wrote in message news:gj6e3m$1ilv$1@digitalmars.com...
> Nick Sabalausky wrote:
>> "Derek Parnell"<derek@psych.ward>  wrote in message news:nkr1wyvyj3vv$.qr1gd1h779fx.dlg@40tude.net...
>>> On Sat, 27 Dec 2008 15:45:57 -0500, Nick Sabalausky wrote:
>>>
>>>> ... judging by number of people here asking for
>>>> 64-bit, I find it highly unlikely that most of them have plans to work
>>>> on
>>>> such things either.
>>> My interest in 64-bit hardware support is based on the belief that
>>> before
>>> too long, buying a new 32-bit platform might be a difficult thing to do.
>>> Five years from now, I don't want to be forced into finding a good
>>> second-hand machine just so I can work with D.
>>>
>>
>> I don't want to be forced into buying a new 64-bit machine just because a
>> whole bunch of "gotta have the faciest stuff out there" people have
>> deemed
>> 32-bit insufficient for all computing needs. Besides, can't 64-bit
>> machines
>> run 32-bit code?
>>
>>
> two things:
> a) current hardware is 64bit (if you go and buy a PC),

Ah ha, there's that usual "if you go and buy a PC" catch. Which begs the question, why would I? My existing system does everything I need it to do perfectly fine. And since I'm not petty enough to allow anyone to shame me into buying a new system just by calling my *current* system "legacy", that leaves no real reason for me to buy a new one.

Saying that "most of the ones being sold are 64-bit" is completely different from saying "most of the ones *in use* (ie *current*) are 64-bit". People constantly misuse "this is what you would get if you went out and bought a new system today" as a meaningful assessment of the current state of computing. "What the stores are carrying" could only be an accurate indicator of "current systems" if everyone was going out and buying new systems every single time anyone used that overplayed "if you go and buy a PC" argument.

> so supporting 64bit is just supporting the current technology. it's not
> about fancy servers or anything like that, just supporting the current
> standards. that's a minimun that should be expected from any compiler
> implementation nowadays.
> b) even though for now there is a compatability mode in most OSes, why
> would I want to limit the performance and abilities of my PC to old
> technology which is being faded away?
>

Even in 32-bit "legacy" mode, 64-bit systems are absurdly fast anyway. I mean, what's the slowest 64-bit x86 out there? A chip that's still pretty damn fast, that's what. It's pretty difficult to be sympathetic about an overkill system being rendered "still overkill, but only *slightly* less-so". If you're going to try to wring every bit of performance out of a system, it's ridiculous to be focusing that effort on the higher-end. That's just pure wasted effort.

And as for people who whine "But I paid big bucks for this high-end system! I deserve to get full-performance out of it!": If they feel that not enough of that system's full potential is getting utilized, then it was pretty stupid for them buy it in the first place. If they were buying it as a future-proofing measure, then they need to learn patience.

> 64bit machines can run old *legacy* software which is 32bit, but that doesn't mean *new* software should be written as 32 bit.

No, you're right, it doesn't. But what *does* mean that new software should be written as 32-bit is that there are still a hell of a lot of 32-bit systems in regular use. If you want to toss a 64-bit version out there too, fine. But don't go leaving people out in the cold just because they haven't hopped onto your bandwagon.

> no one forcing you to buy a new PC and DMD will continue to support 32bit for a long time, I presume. but you cannot force people who did buy a new PC in the last few *years* to be limited to your old ancient hardware.
>

A *few* years is not nearly a long as most people in the tech sector would like to believe (And one hell of a far cry from "ancient"). Something that's only a few years old is still very useful, as well it *should* be. If you feel like you have to replace a machine every couple of years, you're wasting your money. (I'm using the general "you" here, not *you* specifically.) It's just an example of this society's rampant over-consumerism (ie, the so-called "consumer whore") and ever-decreasing pragmatism.

> One last thing, you can always continue using an older version of the compiler even if Walter drops support for 32bit in later versions. In any case, you don't have any valid reason to object to 64bit support.

I never said D shouldn't support 64-bit. Obviously it should. I'm saying it shouldn't be such a high priority.