You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introducing an OP_BRANCHUNLESS <offset> instruction (inspired by Ruby).
Pseudo bytecode:
<condition> <= evaled condition is on stack
OP_BRANCHUNLESS 2 <= jump +2 bytes unless stack_pop
<2 bytes of body>
<end if>
To keep things simple at first, we could compile only the if/unless without any else branches.
This would be the first jump type instruction. if is the simplest one, so it's a good starting point. After this, porting for, case, and, or to instructions will be possible.
However, I think this is where the const_ptr pointer breaks. Any instruction using the const_ptr inside a loop/jump will cause it to be out of sync w/ ip. This should be fixed first.
The text was updated successfully, but these errors were encountered:
However, I think this is where the const_ptr pointer breaks. Any instruction using the const_ptr inside a loop/jump will cause it to be out of sync w/ ip. This should be fixed first.
I would say the benefits of it start to break, since it would essentially rely on fat pointers, which include an offset for both the ip and const_ptr. I agree that we should move away from the constant pointer before implementing the control flow tags.
Introducing an
OP_BRANCHUNLESS <offset>
instruction (inspired by Ruby).Pseudo bytecode:
To keep things simple at first, we could compile only the
if
/unless
without anyelse
branches.This would be the first jump type instruction.
if
is the simplest one, so it's a good starting point. After this, portingfor
,case
,and
,or
to instructions will be possible.However, I think this is where the
const_ptr
pointer breaks. Any instruction using theconst_ptr
inside a loop/jump will cause it to be out of sync w/ip
. This should be fixed first.The text was updated successfully, but these errors were encountered: