Confusing language and behavior: block on read

[[Homosexual Pie Row]]

The blocking behavior on Xbus isn't what I expect.

It says in the manual "If a read or write is attempted without a corresponding operation on a connected device, the operation will block." So I have a microcontroller with a "MOV X1 P0" operation. I expect it to block until there is data on the Xbus. By block, I mean the UNIX definition of block -- sleep until there is I/O.

Instead, I get a pop-up "Part not sleeping (blocked on read)". That's the point of blocking on I/O. You sleep until there is data to read. In the context of the game, it seems to be that if you read or write on the Xbus, instead of blocking, it is a failure case.

Is my background different enough that blocking means something different to me than it does the rest of the target audience?

[Inari]

Well "blocking" here would likely just mean it tries to read over and over till there is something to read. At least since we got the "SLX" instruction to actually sleep till data is there (so like an interrupt?)

Also this is Microcontrollers, not UNIX :D

[uNiels 💗]

Well, it is blocking in the same sense you understand it. But blocking beyond one "cycle", "second", "frame" or however you wanna call it is not legal in this game. Every Microcontroller must sleep when the current cycle ends and the game transitions to the next cycle, be it with "slp" or with "slx".

[uNiels 💗]

To make it clearer what I mean consider 2 microcontrollers than want to communicate. The left one wants to send a number (say 55) to the right one.

Say you're using the P wires to communicate. The left one gets out of its "slp 1" and the right MC as well. The left one calculates a number to send. Say it wants to add 5 to the accumulator and then send it. So it has a "add 5" and a "mov acc p1". The right one has a "mov p0 dat". But it will not read the correct value, as it reads before the left MC sends the value. You need to sync that design with NOPs or otherwise.

On the other hand, if you use the X wires to communicate in the same situation, you can just mov the value onto X3 on the left one and read from X0 on the right one without thinking about which one is first. If the reading one is first, it will wait until a value gets written and then read it and continue (during the same time unit / cycle). If the writing one is first, it will block until someone on the wire is ready to read and only then will it send the value and continue (not beyond the same time unit / cycle).

[[Homosexual Pie Row]]

Originally posted by Inari:

Well "blocking" here would likely just mean it tries to read over and over till there is something to read. At least since we got the "SLX" instruction to actually sleep till data is there (so like an interrupt?)

[nod] I was hoping for power and instruction efficiency here. Having to allocate an extra instruction to achieve the expected blocking behavior (sleep until I/O is available) is unfortunate in the application I was using it for.

[[Homosexual Pie Row]]

Originally posted by blubberdiblub:

Well, it is blocking in the same sense you understand it. But blocking beyond one "cycle", "second", "frame" or however you wanna call it is not legal in this game. Every Microcontroller must sleep when the current cycle ends and the game transitions to the next cycle, be it with "slp" or with "slx".

Blocking on I/O can't last longer than the current cycle, got it. That probably should be worked into the manual?

[uNiels 💗]

Originally posted by Homosexual Pie Row:

Blocking on I/O can't last longer than the current cycle, got it. That probably should be worked into the manual?

Sure, if you think it's not perfectly clear from the manual, you should report it as a bug via email.

[[Homosexual Pie Row]]

Originally posted by blubberdiblub:

Sure, if you think it's not perfectly clear from the manual, you should report it as a bug via email.

Point taken. Taken to email, conversation referenced. Thanks!