I think we're going to see some clever optimizing DSLs (a la FFTW) -- restricted languages for the kinds of embedded programs you write on such an architecture will be easier to optimize than general purpose languages. Particularly if they have a clear cost model.

The Haskell embedding is very likely to head in that direction.

(See e.g. in this style : http://www.fftw.org/faq/section4.html#whyfast or this style : http://www.cse.unsw.edu.au/~chak/papers/polymer.pdf -- code generation + DSL + constraint solver for instruction level timings).

At least, that's what I'd do.

> I'd be curious to see what Notch can do to still encourage people to learn how the CPU works themselves.

Have some ship customisation stuff tied to assembly programming. People love changing the colour of carpets or wearing hats or collecting and displaying fossils.

Then allow the community to create simple how to guides - "This program will do $THIS_THING; here's how it works; now try to change it to do something slightly different."

I guess Codecademy should have a DCPU section too.

Yep, only thing I dislike is that the processor does not simulate the importance of cache. If the in-game processors allowed the selection of different cache-line sizes (both instruction cache and data cache) for different costs (paid via the in-game currency), it would add another level of depth to the game market. It would also mean getting into the nitty-gritty of optimization would be even more worth it.