C would probably be fine. One interesting point seems to be the ease with which many parameters can be both passed and returned. So, languages that return multiple values from functions, and that allow for good, automatic software pipe lining.
C expects addressable registers. From what I can tell this doesn't have those!
It really does seem like a Lisp would map much better, with the whole caller/callee and those private data belts that looked like hardware level closures!
To elaborate on what knz42 said, C expects addressable memory but doesn't say anything about registers at all. In fact, the existence of registers is sort of vaguely awkward from the perspective of C's model of computing.
That "register" nowadays is just a sequence of characters that, to those familiar with CPU architecture, rings a bell. Modern C standards do not convey any links between the keyword and hardware registers. http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf, section 6.7.1:
"A declaration of an identifier for an object with storage-class specifier register suggests that access to the object be as fast as possible. The extent to which such suggestions are effective is implementation-defined."
And 'non-addressable' only applies to the C 'runtime'. The standard does not say anything about the hardware.
For example, a C compiler for the 6502 could attempt to store variables of storage class 'register' in the zero page. Such storage locations have an address, but you are not allowed to take it from standard C.
Comments
What would be the ideal language to compile to this?
C would probably be fine. One interesting point seems to be the ease with which many parameters can be both passed and returned. So, languages that return multiple values from functions, and that allow for good, automatic software pipe lining.
Fortran or numerical code in C. It seems best suited for statically unrollable loops with few data-dependent branches or random memory accesses.
C expects addressable registers. From what I can tell this doesn't have those!
It really does seem like a Lisp would map much better, with the whole caller/callee and those private data belts that looked like hardware level closures!
C does not expect addressable registers. This architecture seems quite appropriate for C!
To elaborate on what knz42 said, C expects addressable memory but doesn't say anything about registers at all. In fact, the existence of registers is sort of vaguely awkward from the perspective of C's model of computing.
Considering that C has a "register" storage-class specifier keyword, I don't see how you can make that claim. Granted, modern compilers ignore it.
Certainly, the C specification states that "register" storage is non-addressable, so it does say something.
That "register" nowadays is just a sequence of characters that, to those familiar with CPU architecture, rings a bell. Modern C standards do not convey any links between the keyword and hardware registers. http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf, section 6.7.1:
"A declaration of an identifier for an object with storage-class specifier register suggests that access to the object be as fast as possible. The extent to which such suggestions are effective is implementation-defined."
And 'non-addressable' only applies to the C 'runtime'. The standard does not say anything about the hardware.
For example, a C compiler for the 6502 could attempt to store variables of storage class 'register' in the zero page. Such storage locations have an address, but you are not allowed to take it from standard C.
For an even better example, look at http://en.wikipedia.org/wiki/TMS9900. That CPU stored all its general purpose registers in RAM.
My intuition says haskell or lisp. Don't take my word for it.