You're right that there's a bug. Thanks for bringing it to my attention!
My original intent was to have writes to @IN be ignored, but it looks like I never actually implemented that behavior. I'm inclined to fix the bug (someday...), but I want to see if anyone's existing solutions depend on the current behavior.
just to confirm, with the bug fixed, `subleq @IN, something, something` would perform a read from the queue, and branch according to the subtraction result, then discard the result? (that's what my expectation would be, at least)
If you wanted to do something more special/possibly useful, you could make this read not advance the queue, acting as a kind of 'peek' operation. depending on the (theoretical) underlying hardware, this could be either a kludgy special case, or rather elegant to add. just an idea i had because of the current behavior which doesn't actually touch the queue at all (for a while i was wondering if it was acting as a peek for some reason, before realizing it was interacting with memory), meaning that as long as no solution relies on @IN acting as memory, choosing whether to advance the queue or not in this case is a decision left up to the designer (i.e. you).
Just published an update that addresses this. "@IN" is now supported in either (or both) of the first two address slots:
