Talk:Pada

Instructions

 ? - if bit is true then prevent one command from entering the tree

As far as I can see, this wont really suffice for conditional modification of the bits as, in essence, it's a 'once off if', meaning that instead of "if Z then do a; b; c" you need to say "if Z then do a. if Z then do b ...", but in order to effect conditional changes to a bit (piece of data) based on another piece of data, you need to: 1. Set up the tree to point to the conditional bit 2. Send the ? 3. set up the tree to point to somewhere else 4. Operate on it. The problem is then that the ? only ignores the next command, meaning that 4 will happen anyway and operate on the condition bit iff. the condition fails. Also, you cant add another ? in between three and four as the tree is pointing to the wrong place. Now, there may well be a way to use that as part of the actual programme, and ignore the fact that indeterminably the condition bit may altered (perhaps copying it beforehand, I don't think that necessitates the use of the ?).

Also, as an open question; is it possible to redirect the tree from any arbitrary bit to any other in one command? (It should take three alterations, if this works as I suspect viz., a barrel shifter) If not, combing ? and any of OoQq. cant effect an arbitrary effect at an arbitrary position [due to the one command restr.]

 * - jump: read a signed byte like w and jump in that direction

Is this to say that the programme will jump via a user-input amount? If so, then very little needs to be done in terms of programme side logic to prove turing-completeness. In fact, O*o*.*Q*q*1~*v*^*#*** is a perfectly working BF interp ;-) Intentional or not, I like this idea .... {goes off to experiment :} - Hiato 14:32, 7 April 2010 (UTC)

I can see how the program's execution is a bit confusing, let me try to explain. Basically, you would send down a ? command, following it with some combination of one or to of OoQq. to switch the tree to point to the modified bit. When the ? command is executed the tree will be set up before the command that it removes is added or not added to the tree. You can make this one of ~01 for instance.

The way I see it is that the commands fall through the tree kind of like they would in plinko, and there are multiple instructions in the tree at once all following the tree. The commands are executed as they hit the bottom or become a . in the middle somewhere. So ? ends up skiping the third or fourth instruction after itself. I might have an interpreter soon to test this and show how they work.

By the way, * doesn't read from the user like r, it reads from the bits like w. I'm not sure how that would be a working BF interpreter... but it sounds interesting! --Revcompgeek 04:30, 15 April 2010 (UTC)

I need a bit of help on the jump instruction. How is the jump target determined?

Is the current word (as read from the bits) simply added to the current program counter / instruction pointer? If so, is that done after the PC increment (as on x86), or instead of it?

Suppose the bit word is currently 0. Will a jump result in an endless loop (pc += word), or will it have no effect (pc++; pc += word)?

--jn (77.181.56.186 23:47, 25 September 2014 (UTC))

Thoughts

User:Revcompgeek wrote:

There are several 2 command no-ops in this language ~~ v^ ## .. oo OO (not qq QQ) These are useful because both "?" and "*" don't touch the 3 commands already in the bit tree, so if you need nothing to happen then using those no-ops are good.

(Deleted from main article, so I reinstated it here --Ørjan (talk) 04:05, 13 October 2015 (UTC))