It's an interesting idea that pops up here every now and again. It's fairly useless as anything other than a toy/educational system though.
I wrote a little OISC virtual machine and assembler a while back. I got as far as adding interrupts to the system for keyboard input and console output before I stopped.
Minimal architectures are interesting in their own right even if they don't have an immediate practical application, though I can think of some fields where they may be useful rather than merely a curiosity or a teaching aid.
I'll download your vm code and mess around with it some, thank you very much for posting the links.
You can define the Y combinator, and therefore recursion quite happily (if not very efficiently) using S and K.
I believe there are also approaches that use as single universal combinator - but I can't find any good references to these - I'd be quite interested to see definitions of S and K in terms of a single universal combinator.
They recover the S and K by applying U to itself in interesting ways, but that's like saying 'this tool is so universal, you can use it as a hammer and a chisel by banging one instance of the tool with another tool just like it'.
That's not a very mathematical way of putting it I guess but I believe that is more or less the spirit of it.
More of the same kind of amusement can be found on the esoteric languages page, which explains:
A Turing tarpit is a Turing-complete programming language whose number of commands, operators, or equivalent objects is very small. These include brainfuck (8 commands, all with 0 operands), OISC (1 command, 3 operands), and Thue (1 command, 2 operands).
Arguably, Rule 110 [1] fits the bill. Once you have your data, you just apply Rule 110 endlessly.
One could argue that one has merely embedded the actual operands into the data fed to Rule 110, and I would then observe that in the context of Turing completeness, there is a fundamental fuzziness between data and code that goes "all the way down". All your no-operands single-instruction can really be is "do it", with "it" specified by the data.
Right, this is very interesting, you are effectively running the data and code intermingled instead of in different separate memory areas.
A fascinating thing about computing with rule 110 seems to be that it is inherently parallel, the "instruction" is applied to the entire memory area in lockstep. There is no control flow of any kind. So if you have static data you need to encode it as "idle" instructions.
I wrote a little OISC virtual machine and assembler a while back. I got as far as adding interrupts to the system for keyboard input and console output before I stopped.
http://simonpstevens.com/projects/oiscvm
Source code is on githib:
https://github.com/simonpstevens/oiscvm