I've added some programs to my Subleq OISC webpage, for anyone interested. Included is this quine (not elegant, but it works!):
[67,67,3,68,68,6,65,68,9,67,66,12,36,36,15,66,36,18, 64,36,21,63,36,27,66,66,-1,36,36,30,66,36,33,66,66, 36,36,66,39,36,36,42,68,36,45,52,52,48,36,52,51,66, 120,54,63,67,57,63,68,60,66,66,9,-1,69,-69,0,67,137]
Renaming/moving article content?
The content of this article is written as though OISCs must use Subleq according to one person's (Mazonka's?) extensions to the concept. But Subleq OISCs have been called by that name for many years, and the term would seem to refer to any OISC that uses Subleq ("Subtract and Branch if Less-than-or-Equal" to zero) as its only instruction — and there are even variants of how Subleq works, aside from from various useful "extensions" like i/o. So, I suggest that either the present extensive version-specific content be moved to an article more appropriately named, or that it be edited to identify the version-specific content, allowing equal status for other versions of Subleq OISC. I'd like some feedback before I do either of these. --r.e.s. (Talk) 22:17, 31 December 2007 (UTC)
As I commented above two years ago, subleq is the name of a type of OISC, as described at this Wikipedia page. The name should not be appropriated for someone's special version of it together with their special-version assembler. The article should be edited to reflect this. --r.e.s. (Talk) 15:20, 7 September 2009 (UTC)
It appears that the dialect of subleq described here is Turing complete only if the value of each memory location is unbounded. This would allow an unbounded code space (the convention that a previously undefined memory location be initialized to 0 seems natural) which would fulfill the Turing Completeness criterion of arbitrarily large memory (since data shares the same space with code). However, even a bounded code space with unbounded memory values would almost assuredly be enough for TC, as one could construct a Minsky machine.
On the other hand, bounded memory values in an unbounded code space - a la many brainfuck dialects - would not be sufficient, because only a finite portion of the code space is accessible.
A logical follow-on question is this: What about relative rather than absolute branching? Using this variation on subleq an unbounded code space would be accessible even with bounded memory values, and should be Turing Complete.
So, I propose the following information be added to the main page: "Absolute addressing dialects of Subleq are Turing Complete only if the memory values are unbounded. Relative addressing dialects of Subleq are Turing Complete even with bounded memory values." --Nthern 18:22, 15 September 2008 (UTC)
- I am not convinced that this is sufficient, since the branch distance would still be bounded, and so the more significant bits of your program counter would behave similarly to a single integer that can only be incremented and decremented, which seems like a serious limit on how you can branch. I don't recall that this is enough for TC. It is of course complicated by the fact that the code could vary arbitrarily dependent on this program counter, but my immediate intuition is that this is not enough. --Ørjan 14:15, 16 September 2008 (UTC)
- Wait, of course it should be enough, since you can simulate a universal turing machine with this layout. --Ørjan 14:28, 16 September 2008 (UTC)
Hey r.e.s., where'd your web page go? I went there a couple of times, but hadn't yet downloaded your python Subleq interpreters. Now I'm wishing I had. I also liked the info you had on the different mark i vs. mark ii and absolute vs. relative dialects. Hope you show up again soon. --Nthern 17:42, 2 October 2008 (UTC)
- Sorry -- I've been away for a long while and only just noticed your message here; thanks for the kind words. Unfortunately, I've lost most of the content of my personal website, including the Subleq pages and the pages on BCT. Needless to say, I would appreciate hearing from anyone who has copies of any of those pages. (r.e.s.0001 [at] gmail.com) --r.e.s. (Talk) 05:14, 12 February 2009 (UTC)