No, you've got it exactly backwards. I am saying that a more abstract language would be better, or at least a language which has a different set of core abstractions. You must have read enough of my posts to others on this forum to know I am no advocate of low-level programming; I am Lisp programmer, FFS! I am planning on using a Lisp-like language for my own OS, why would I recommend a low-level one for yours?Geri wrote:-what you are saying before, is that a more basic low-level language would suit the subleq better than actually a C compiled code. .
The purpose of the exercise was to show how dependent C is on the specifics of register machines, and more to the point, how efficient C programming requires you to be aware of how it targets the register usage. In a more abstract language, one not tied so directly to what the compiler emits, the compiler would be able to rearrange the code in a way that is efficient, without having to be told how to by the coder.
The problem is that C is assuming a very close match the the hardware, which isn't the case for OISC; it paints you into a corner regarding the possible optimizations. You need to use something that can be optimized for OISC, which C, with its register orientation, can't be.
I am saying that you should consider using a language which is sufficiently abstract that the compiler has enough freedom to choose its own optimizations rather that being forced into the ones assumed by the programmer and the language. For OISC, that probably means a dataflow language, something that incorporates a state transition as its core abstraction. TBH, that's a type of language we need more of anyway; even 'high-level languages' such as Java and C++ are still too focused on imperative programming rather than declarative programming, and for a state-transition system like OISC, a declarative language is a must.