illustrate removing UF flag

[patricksurry]

Validate the idea of removing the UF flag in #101 with compile, checking directly for jsr underflow_1...4. This means most native words have header flags = 0. It's also slightly quicker in the default no stripping case since we check whether the user cares before checking if there's an underflow check.

[patricksurry]

updated the check for calling xt+3 to skip underflow without the UF flag. tested as below, where it correctly identifies xt_drop+3 skipping underflow, but not xt_zero+3 which has no underflow test

0 nc-limit !  ok
hex  ok
' drop 3 + u. 86A3  ok
' 0 3 + u. 9E58  ok
\ SEE should label drop+3 (skipping underflow) but not zero+3 (no underflow)
: fubar 0 [ 20 c, 58 c, 9e c, ] drop [ 20 c, a3 c, 86 c, ] ;  
see fubar 
nt: 800  xt: 80D 
flags (CO AN IM NN HC): 0 0 0 1 1 
size (decimal): 12 

080D  20 55 9E 20 58 9E 20 A0  86 20 A3 86   U. X. . . ..

80D   9E55 jsr     0
810   9E58 jsr     
813   86A0 jsr     drop
816   86A3 jsr     drop

[SamCoVT]

Playing devil's advocate here, I think your double-check can defeated by having an unnamed word that is simply a JSR that doesn't expect to return and no JSR after it. This is an extremely contrived example - but if you wanted to fix it, you might consider factoring out your code that detects if it's a JSR to the range of addresses the underflow checks live in so you can reuse it here.

I think that's contrived enough that your check for a JSR three bytes earlier is probably safe enough.

Interestingly, 64tass 1.57 crashed on me while trying to assemble this PR. I upgraded to 1.59 and it assembles fine. We should put that in the docs as a minimum version if I pull this.

[patricksurry]

yup, i wondered about that too. Probably better to have one shared subroutine than two similar but different code blocks in different places. I can make that change.

[patricksurry]

I made that change you suggested and did some doc tweaks. Should be good to go.

[SamCoVT]

I think this looks good. I should have some time in the next few days to test it out and merge it.

[patricksurry]

Do you think the same idea is relevant for HC? All the CFA helper routines like dovar, doconst etc are consecutive in the source so >body could just do similar check for jsr <address range> and avoid this flag altogether. It only seems used by create and >body at the moment.

[SamCoVT]

That's certainly something to consider. I do believe it's just CREATE and >BODY that deal with that, so I don't think it would be too difficult to handle that the same way. If you do go that route, I'd just ask for a comment around the CFA routines noting that they need to stay together.

[SamCoVT]

Is that something you want to play with in this PR, or issue a new PR for?

[patricksurry]

I can do a new PR for that, easier if anyone is reconsidering later.