Kyle Furlong wrote:

> Solid reasoning.
> Does DMD have the ability to handle other assembler besides x86?

AFAIK, DMD doesn't even do code for anything but X86. Let alone asm.


GDC, on the other hand, does code for other architectures but needs
some work for non-X86 assembler (mapping arguments to registers, etc)
But GCC does inline assembler for several targets (only tried PowerPC)
Meanwhile; one can do separate assembler files, and link them with D ?

--anders

Kris,

Very good post... I think your thoughts are dead on.

-JJR

Kris wrote:
> "pragma" <pragma_member@pathlink.com> wrote..
> 
>> Wow.  The feedback to those D posts is.. erm.. brutal.
> 
> Hmmm ... I thought it was quite moderate :)
> 
> Sure, there's one fool jiving on Z80, but I thought the other comments were pretty accurate :: it's a step in the right direction, but with no realistic library (yet), and no *obvious* sign of the backing needed to make an notable impact.
> 
> These are realistic criticisms.
> 
> On the other hand, the whole topic is immediately flawed :: it's almost all about Ruby. Ruby is great for writing throw-away code. Has anyone here actually tried to use it with say, 20 developers, over a multi-year project? It's not as though Ruby is actually new ~ been around for years. It's really, really hard to write large-scale, maintainable code in *any* scripting language (yes, I know there's one or two household names who use it ~ but do you also know their pain?)
> 
> The point is that Ruby et.al. are designed for scripting ~ a whole different ballgame than a systems language. One might well argue the pro's and con's of late- vs early- binding. Instead, I'll just note that Ruby, Perl, Python, VB, and a slew of others address a conceptually different set of problems than D. For example, D would be a good language to write a Ruby engine in. Would Python be an appropriate choice to write a Ruby interpreter? D would probably be a good choice to write "yet another back-office suite" (think PeopleSoft, Oracle, SAP :: payroll processing, etc), yet Perl would probably not be ...
> 
> As the industry matures, there's a high likelihood for the balance to shift between around between different types of languages (between, say, 3G and 4 or 5G). Yet you still have to pick the right tool for the job. Throwaway code is apparently becoming more and more popular (there's much less emphasis on long-term maintenance than there used to be), and processors are bob-awful fast these days compared to what they used to be. Not to mention the amounts of memory available. Still, another set of killer-apps will eventually come along that squeezes the hardware once again, and D will be right there for when that happens (just as C and C++ will be). I mean, we ain't gonna see a speech-recognition engine written in Ruby ~ at least, not this decade!
> 
> One final thought :: I really think D has the wrong target in mind. Walter seems to be interested in the desktop/server arena, yet the best place for D is actually the embedded market instead. We're talking about the most prevalent computers on the planet ~ they're in washing machines, vaccum cleaners, cars, ships, TV's, mp3 players, iPod's, cell-phones, blah blah blah. People don't use C++ there because it's way too bloated. They use C (and some assembler) because it's lightweight and fits the devices nicely. It's a huge market, just crying out for an 'upgrade' in terms of a language as a tool.
> 
> This is why I have an interest in getting D running on PocketPC. There's an enormous potential in the land of cell-phones and, frankly, I rather suspect that's the general direction of future platforms (as opposed to desktops). Why bother competing with C++ and/or Java when you can sidestep them (and all the associated cronyism) completely?
> 
> 
> 

Kris wrote:

> This is why I have an interest in getting D running on PocketPC. There's an enormous potential in the land of cell-phones and, frankly, I rather suspect that's the general direction of future platforms (as opposed to desktops). Why bother competing with C++ and/or Java when you can sidestep them (and all the associated cronyism) completely?

I thought that the subsets "Embedded C++" and "MicroJava" targeted this,
but I might be wrong. ..(I don't know much if anything about handhelds)

-anders

In article <drrmca$2nds$2@digitaldaemon.com>, Kyle Furlong says...
>
>pragma wrote:
>> In article <drr6qr$25q6$1@digitaldaemon.com>, Kyle Furlong says...
>>> pragma wrote:
>>>> In article <pan.2006.02.01.20.06.12.251531@sneakemail.com>, =?iso-8859-1?q?Knud_S=F8rensen?= says...
>>>>> Slashdot have just posted a story called beyond Java
>>>>>
>>>>> http://books.slashdot.org/article.pl?sid=06/02/01/1455213
>>>> Wow.  The feedback to those D posts is.. erm.. brutal.
>>>>
>>>> Gotta love Slashdot.
>>>>
>>>> - Eric Anderton at yahoo
>>> The question for us is, what "killer app" are we going to produce as a community.
>> 
>> Good question.  For starters, such an app would have to be a non-toolchain kind of program; this would place it one tier above where most of us are concentrating right now.
>> 
>> D's advantage over its competitors, in the hands of the end user, is in terms of program quality, size and speed.  I think this is a viable niche for a D "killer app" that could attract people to the technology.
>> 
>> I read something on digg the other day about "microtorrent" which was warmly received even though it had pretty much the same feature set its competition.  I distinguished itself by being more responsive, smaller and faster than just about every other torrent tracker out there.  I'd like to think that particular software author managed to tap into something that users actually want.
>> 
>> 
>> An idle thought: has anyone around here given any thought to an automated bug reporting service for D apps?  Maybe we can set up something that plugs into dsource.org's Trac system?
>> 
>> - Eric Anderton at yahoo
>
>What about a killer web stack? Arent Mango and DSP half the way there already? Wouldnt Kris's http server beat out a java one in terms of speed and memory footprint?

Can't say in terms of memory footprint (I know DDL has *some* potential to pack on the KB if you don't stack your libraries right), but in terms of performance: you bet.

As for DSP itself, I'm also taking advantage of its "back burner" status for now and considering what can be done to level it against Rails and such.

- Eric Anderton at yahoo

In article <drsfap$7bk$1@digitaldaemon.com>, kris says...
>
>b) The embedded market is stuck in C/assembler land. C++ is typically scorned in such environments, well deserved or not. Thus, it's a ripe market to address with D ~ a low overhead, efficient, robust language. One with a small learning curve, fast compiler, and a small library. The best of Java and C together. Sure, I may not use D for a micro-controller with 4KB; but that's fast becoming the exception for everyday devices. Combine D with cell-phones and a gazillion other new gadgets ... Seems like a no-brainer.
>

This couldn't be more true.

It just so happens that I've been spending some of my free time looking into retro game console development (a personal soft spot of mine).  It is absolutely shocking how few options there are out there for hobby developers, let alone professionals, when it comes to languages for everything that isn't an x86 or PPC processor.  Its either C, Basic, ASM or some bastard combination of the above.  Hobbyist tools are of usually poor quality, or just poorly documented. Also that landscape is also the reason why code reuse and mobitiliy between architectures is non-existant.

I agree with Kris' sentiment about micros, but it might be an interesting experiment non the less.  But I am scratching my head as to how you'd get D to target an 8-bit or 16-bit embedded environment.  Perhaps that's just not possible?

- Eric Anderton at yahoo

kris wrote:
> Walter Bright wrote:
> 
>> I think you should post that on slashdot as well! 
> 
> 
> <g>
> 
> Actually, that was intended primarily for you to digest. Whilst it's just an opinion, I truly feel you should seriously consider the embedded market as the initial home for D. Here's some off-the-cuff reasoning:
> 
> a) Java & C++ have the desktop & server market sewn up for now (in non-scripting languages). Sure, you can try to challenge that from the basement level ~ but D needs some street cred to make it past the first stairwell. Java had a comparatively limitless budget, and there was a brand new hole needing to be plugged. What does D have to compete with? Good intentions alone are not enough to succeed.
> 
> b) The embedded market is stuck in C/assembler land. C++ is typically scorned in such environments, well deserved or not. Thus, it's a ripe market to address with D ~ a low overhead, efficient, robust language. One with a small learning curve, fast compiler, and a small library. The best of Java and C together. Sure, I may not use D for a micro-controller with 4KB; but that's fast becoming the exception for everyday devices. Combine D with cell-phones and a gazillion other new gadgets ... Seems like a no-brainer.
> 
> c) Believe it or not, you can still sell compilers to the embedded market. Four years ago, I paid over $2000 for a C compiler, questionable debugger, and emulator from Hitachi (t'was the only one available). You can probably still sell a good D compiler and debugger for $300 per seat. As you know, that kind of market disappeared long ago on the desktop ~ if it ain't free, forget it (how does the venerable Green-Hills stay in business these days? Is it the embedded market?)
> 
> Heck, GDC can apparently already compile targets for Arm/xscale devices. Yet there needs to be a full toolchain to make it worthy of more than a passing glance.
> 
> d) the embedded market is far more likely to give D "a go". Unlike the desktop/server world, there's generally far less investment into a particular or specific infrastructure. Often none. If an engineer can prove that D is faster to develop with and more robust, it's often a done deal. The environment is quite different than today's Java sweat-shops ~ in my humble experience it retains many of the good qualities from twenty years ago.
> 
> d) Building up some credibility in the embedded market also provides time to construct a decent (and robust) library set for other arenas. We all know there's an ocean missing there in terms of the desktop/server space (compared to C, C++, Java, Ruby, Python, VB etc). The embedded market prefers to get by without such fancy jewelry. They prefer just a solid toolchain with a language that exposes assembler, and can bind to C libs if necessary. Eliminating bugs early in the cycle is *the key* thing in that environment. It's just not economically feasible to patch devices once they're out on the street, so you *have* to get it correct up front. Can you say 'contracts' and 'bounds-checking', 'exception handling' and 'optional garbage collection'?
> 
> 
> 
> There's that question that keeps coming up year after year: "what does D target"? I think Matthew grumbled about it again just the other day, and it's one that I've certainly asked myself a number of times. The embedded market is the one place I can think of that would potentially embrace the language. In contrast, it's quite clear that the C++/Java arena would prefer to dispense scorn instead. That's not exactly unexpected at this point, but D would stand a much better chance of success if it had some true street-cred under its belt. And you might even make a bundle selling compilers in the meantime <g>

Two observations:
(1) If D was well received in the embedded market, it could gain coverage in publications like IEEE Spectrum, where its support for floating point is another huge selling point. (Good for D).

(2) Other than for embedded x86 CPUs, I can't see how Walter could implement this without massive rewrites to his compiler backend to generate code for the other architectures. If he did that, his C++ compiler would also work on those systems. And I think his work on the front-end would virtually come to a halt. (Very bad for D).

"Don Clugston" <dac@nospam.com.au> wrote in message news:drt6aq$q0p$1@digitaldaemon.com...
> Two observations:
> (1) If D was well received in the embedded market, it could gain coverage
> in publications like IEEE Spectrum, where its support for floating point
> is another huge selling point. (Good for D).
>
> (2) Other than for embedded x86 CPUs, I can't see how Walter could implement this without massive rewrites to his compiler backend to generate code for the other architectures. If he did that, his C++ compiler would also work on those systems. And I think his work on the front-end would virtually come to a halt. (Very bad for D).

That's just the problem. If I worked on embedded systems, nothing else would happen.

But if anyone wants to set up a business doing D for embedded systems, I would be more than happy to supply the compiler.

"Walter Bright" <newshound@digitalmars.com> wrote

> That's just the problem. If I worked on embedded systems, nothing else would happen.

Ah yes; the "all or nothing" syndrome :)

This "embedded market" approach is just a notion; take it or leave it. Yet, I'm surprised to see you just "pooh pooh" it with a "well, I couldn't do anything else" type of response. That's indicative of a knee-jerk reaction rather than careful thought ~ of course, I could be completely mistaken. Still, you have to wonder why others feel it would be a sound approach. Thus, I do hope you give it some serious consideration.


> But if anyone wants to set up a business doing D for embedded systems, I would be more than happy to supply the compiler.

It's the entire tool-chain that's needed to gain traction ~ not a language front-end. Of all people, it may be you who's needed to get something off the ground. I'm sure there's plenty of capable individuals here who'd be willing to step up and help. What D *really* needs right now is a goal; a direction; some strategy. If you were to actually set something there, and commit to it, I think you'd be surprised how quickly others would join up. It would need to be something concrete ~ with a palatable end-point.

Of course, this whole topic is very much dependent upon how serious one is about the success of D.

"pragma" <pragma_member@pathlink.com> wrote ..
> In article <drsfap$7bk$1@digitaldaemon.com>, kris says...
>>
>>b) The embedded market is stuck in C/assembler land. C++ is typically scorned in such environments, well deserved or not. Thus, it's a ripe market to address with D ~ a low overhead, efficient, robust language. One with a small learning curve, fast compiler, and a small library. The best of Java and C together. Sure, I may not use D for a micro-controller with 4KB; but that's fast becoming the exception for everyday devices. Combine D with cell-phones and a gazillion other new gadgets ... Seems like a no-brainer.
>>
>
> This couldn't be more true.
>
> It just so happens that I've been spending some of my free time looking
> into
> retro game console development (a personal soft spot of mine).  It is
> absolutely
> shocking how few options there are out there for hobby developers, let
> alone
> professionals, when it comes to languages for everything that isn't an x86
> or
> PPC processor.  Its either C, Basic, ASM or some bastard combination of
> the
> above.  Hobbyist tools are of usually poor quality, or just poorly
> documented.
> Also that landscape is also the reason why code reuse and mobitiliy
> between
> architectures is non-existant.


Amem.


> I agree with Kris' sentiment about micros, but it might be an interesting
> experiment non the less.  But I am scratching my head as to how you'd get
> D to
> target an 8-bit or 16-bit embedded environment.  Perhaps that's just not
> possible?


I think that's a question of strategy. For example, it would make sense to initially target the ARM/XScale instruction set (those devices are now notably more capable than a "state of the art" PentiumII from not so long ago). On the flip-side, I'm don't think it would make much sense to target an 8-bit device. D is the wrong tool there.

On Thu, 2 Feb 2006 11:43:01 -0800, Kris <fu@bar.com> wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote
>
>> That's just the problem. If I worked on embedded systems, nothing else
>> would happen.
>
> Ah yes; the "all or nothing" syndrome :)
>
> This "embedded market" approach is just a notion; take it or leave it. Yet,
> I'm surprised to see you just "pooh pooh" it with a "well, I couldn't do
> anything else" type of response. That's indicative of a knee-jerk reaction rather than careful thought ~ of course, I could be completely mistaken.
> Still, you have to wonder why others feel it would be a sound approach.
> Thus, I do hope you give it some serious consideration.

I'm prepared to give Walter the benefit of the doubt.

As I know very little about the back end of compilers I have a few questions:

How many different architectures are there in embedded programming?

How long does it take to develop a code generator for another architecture? Or perhaps more importantly how long does it take to develop one which performs well enough, compared to existing C compilers, to make the switch from C to D viable for embedded programmers?*

*It would not necessarily have to outperform but rather perform well enough to make the other benefits of D outweigh any short fall in performance.

The C compilers presumably have years of optimisations behind them, won't DMD require the same time spent optimising in order to reach that threshold?

Or do embedded programmers "drop into" assembler so frequently as to make any optimisations in the compiler almost non-essential?

That said, a complier that could optimise especially well would allow programmers to forgo assembler completely, however, if C compilers have no managed this, is it even possible? can DMD achieve this?

> Of course, this whole topic is very much dependent upon how serious one is about the success of D.

I'm also going to assume that Walter is dead serious about the success of D.

Regan