Google Assembly Language Books and you'll find a number of good books online for teaching the basics of Assembly language. With one of those and the spec, you can probably learn fairly well.
And for anyone really serious about programming the DCPU in assembler, I highly recommend The Art of Computer Programming, by Donald Knuth. The first three volumes of this book series were just about the most useful reference works ever written, and were required reading for programming in the 80s, especially if you were working in assembler. (And OMFG - I just noticed that volume 4A came out last year! Finally!)
It could very easily be in ASM. There have been many examples of very complete operating systems written completely in it. http://www.menuetos.net/ Is one of them. For a system of this size, hand optimized assembly may be the best way to belt out speed.
Alright, I haven't done anything like this before, so I'm not sure if I'm doing this right...
I uploaded the Mercurial-versioned code to bitbucket now, instead of single revisions to a web server.
You can check it out at
Project Euler is highly recommended for learning any new programming language. Take a look at the problem sets if you are looking for some code to write on the dcpu.
A quick glance at the code and I don't see anything that's linux/unix specific. So it should work on windows. On windows you have to install python and probably deal with the environment variables to get what i posted above to work.
Before even asking the question I knew that a byte could be (and used to) be different sizes, but I haven't seen a reference to a non-8-bit byte in decades. (Knuth's The Art of Computer Programming was written four decades ago.) I conceed that, on a system where data units aren't in a power of two number of bits, then byte may mean something different, but on all 8/16/32/64-bit CPUs I have worked on, a byte has always been 8 bits. I certainly wouldn't refer to DCPU's 16-bit units as "bytes", but rather "words".