4 ms·
To think of it... how viable such a "computer" would be? Would it be prohibitively inefficient? Or the other way around? What about parallelization - very easy,
by tandr 5y ago
To think of it... how viable such a "computer" would be? Would it be prohibitively inefficient? Or the other way around? What about parallelization - very easy, impossible at all, or something in between?
- qsort 5y agoThe "trick" of single-operation ISAs is that in order to achieve Turing completeness, they have to pick an instruction that effectively "encodes" multiple different instructions. So if you actually wanted to make and optimize one enough to be a "real" computer, you'd effectively end up with a conventional RISC architecture, where the only difference would be this weird way to encode instructions sprinkled on top of it. Once you're there, it's just Turing machines all the way up: build a compiler, build an interpreter, run nodejs, whatever. Processors are so fast these days you could probably live with the inefficiency, assuming sufficiently smart compilers are available for the architecture. It's just... not that different. Computers are weird like that.
- grishka 5y ago> What about parallelization If you mean multi-core, I guess you could do memory-mapped registers to control additional cores from the first one? In its simplest form, you write an address (reset vector) into a predetermined memory location, and that core starts executing from that address. IIRC real multi-core CPUs work something like that. If you mean multitasking on a single core, you should definitely be able to implement the cooperative kind. Preemptive multitasking requires timer interrupts.
- michrassena 5y agoThe major inefficiency I see at the hardware level is the lower amount of work per instruction. This would lead to more data being fetched by the CPU to execute (though with one instruction, I suppose you only need the parameters). I'm sure a large cache would mitigate this problem somewhat.
- compressedgas 5y agoNot prohibitively inefficient but fundamentally inefficient. SUBLEQ was designed to be a simple processor that could be implemented and programmed in a course. It was not designed to be practical or efficient, only demonstrative. From a processor design prospective, the problem with SUBLEQ as an instruction set is that its instruction is both an arithmetic operation and a branch. And some things have to be implemented using self-modifying code. These are impediments to branch prediction, instruction pipelining and reordering, and speculation. To make the fastest processor possible for SUBLEQ, one would have to basically have to recompile the code into a better instruction set. And that would be hard as it would require recovering the basic block structure which is hidden by the self-modifying code.