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 <newshou...@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:newshou...@digitalmars.com">newshou...@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> >