If I had my way

[Paulo Pinto]

Sure, I just am not connected to the Internet all the time.

Regarding the Cell processor, many game studios in Germany actually do code the SPE directly in assembly instead of C with intrinsics, as they even do code rewriting tricks.

But there is a research JVM for it, hence a GC enabled language
http://people.inf.ethz.ch/anoll/publications/cellvm.pdf

Larrabee is dead, however its sucessor "Manycore", has Haskell support, which
again means a GC enabled language,

http://software.intel.com/en-us/blogs/2010/10/14/prerelease-ghc-and-haskell-cnc-installed-on-intels-manycore-testing-lab-for-academic-use-2/

There are DSP boards that make use of .NET Micro Framework
http://www.analog.com/en/processors-dsp/blackfin/processors/bf518_fmc_dev-kit_ref-design/fca.html
http://www.ghielectronics.com/catalog/product/256/

The Propeller chip for embbeded solutions has the high level Spin
language as main development tool, besides Assembly.

And there is also a JVM available for it.
http://www.parallax.com/tabid/255/Default.aspx

French Radar systems are controlled with the Aonix Perc Ultra JVM. For sure you are aware of what a GC pause might cause on a missile guidance system if it wasn't properly implemented.
http://www.mtemag.com/ArticleItem.aspx?Cont_Title=Aonix+lands+Normandie+deal+with+Thales+

Regarding game engines targeting mobile devices and consoles we have Unity Engine and the upcoming Delta Engine. Both have GC enabled languages.

http://deltaengine.net/
http://unity3d.com/

--
Paulo


Manu Wrote:

> On 12 December 2011 05:58, Walter Bright <newshound2 at digitalmars.com> wrote:
> 
> > On 12/11/2011 10:34 AM, Paulo Pinto wrote:
> >
> >> In my experience programming embedded systems in highly constrained
> >> environments
> >> usually means assembly or at most a C compiler using lots
> >> of compiler specific extensions for the target environment.
> >>
> >> I fail to see how D without GC could be a better tool in such enviroments.
> >>
> >
> > For a system with a tiny amount of memory, D probably is the wrong tool.
> > My suggestion would be:
> >
> > 0..64K assembler
> > 64K..1M C
> > 1M+ D
> >
> > The larger your program is, the more D starts to pull ahead.
> >
> 
> I'd like to hear your comment on my last big email in this thread.
> 
> <div class="gmail_quote">On 12 December 2011 05:58, Walter Bright <span dir="ltr"><<a href="mailto:newshound2 at digitalmars.com">newshound2 at digitalmars.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> <div class="im">On 12/11/2011 10:34 AM, Paulo Pinto wrote:<br>
> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> In my experience programming embedded systems in highly constrained environments<br>
> usually means assembly or at most a C compiler using lots<br>
> of compiler specific extensions for the target environment.<br>
> <br>
> I fail to see how D without GC could be a better tool in such enviroments.<br>
> </blockquote>
> <br></div>
> For a system with a tiny amount of memory, D probably is the wrong tool. My suggestion would be:<br>
> <br>
> 0..64K assembler<br>
> 64K..1M C<br>
> 1M+ D<br>
> <br>
> The larger your program is, the more D starts to pull ahead.<br>
> </blockquote></div><br><div>I'd like to hear your comment on my last big email in this thread.</div>
>