Most user words with conditionals end up as NN because they involve absolute jmp either literally or via zero_branch_runtime. which uses an absolute target rather than a 16-bit offset.
We could replace these with bra in many cases, and the others using a jsr farbra / .word offset construct so that we never generate an absolute jump target. I believe all code generation for jmp is routed through cmpl_jump, cmpl_jump_later, cmpl_jump_tos, cmpl_0branch_tos and cmpl_0branch_later so it shouldn't be too difficult to rewrite them.
Performance/code-size would improve a little for jmp -> bra but would be a bit worse for jsr farbra. On the other hand, small conditional words would potentially benefit from inlining.
A 16-bit offset would only allow jump up to +/- 32Kb so it would fail if you wrote a word that contained a conditional jump across say a 32K+ alloc'd block. It's hard to see that being a significant restriction in practice so could generate an error message?
(feel free to assign this to me)
Most user words with conditionals end up as NN because they involve absolute
jmpeither literally or viazero_branch_runtime. which uses an absolute target rather than a 16-bit offset.We could replace these with
brain many cases, and the others using ajsr farbra / .word offsetconstruct so that we never generate an absolute jump target. I believe all code generation for jmp is routed throughcmpl_jump,cmpl_jump_later,cmpl_jump_tos,cmpl_0branch_tosandcmpl_0branch_laterso it shouldn't be too difficult to rewrite them.Performance/code-size would improve a little for
jmp->brabut would be a bit worse forjsr farbra. On the other hand, small conditional words would potentially benefit from inlining.A 16-bit offset would only allow jump up to +/- 32Kb so it would fail if you wrote a word that contained a conditional jump across say a 32K+ alloc'd block. It's hard to see that being a significant restriction in practice so could generate an error message?
(feel free to assign this to me)