~~(a+b)

since >> (and the other bitwise operators) convert to int32 first.

I prototyped adding an overflow check operator in TT’s forth that translated into checking the condition codes at the ISA level, and guarding on not overflowing. it generally works, and it worked well enough to pursue further.

i did hit a snag optimizing it because that deepdown branch can cause a tree branch where you dont want one. both sides of the branch will end up computing (a+b) after you optimize, but now you have two identical tree branches.

Without a technique like UCI’s tree folding, which would eliminate those branches, the penalty for too many branches was higher than the penalty for doing extraneous doubleToInt32()’s. crypto-md5() is a case that showed this behavior.

this was one of the factors that led us to introduce a static abc->IL translation step. in the case we’re talking about its soo easy to handle staticaly, and really tricky to handle dynamicaly.

I saw the email about Mike Pall’s experience. We were talking about that the other day and array accesses was the one probable exception that came up.

So if you speculate non-overflow on integer addition, and use an integer addition ISA instruction, does that mean you have to add a check for overflow afterward? If so, is that costly?

The cipher thing is interesting. I guess it would be a lot easier if int semantics are available. But I guess there is no int type even in ES4? So are you thinking language extensions, or some kind of pattern recognizer for ES that encodes wraparound semantics for Number?

: words ;

EXTERN: replaces : and marks the word as callable from C. fc.py only compiles words reachable from the EXTERN entry points. so EXTERN in a forth file is like the “extern” keyword in a C file.

TT habit of appending “vec” to name cases comes from the forth notion of vectorized execution. A CASE is basically a jump vector (table) definition – executing a case word is like “goto *vec[*sp--]“.

int(double(a)+double(b) used in an array index context is a hotspot in TT and would definitely benefit from statically optimizing out when possible, or adding an overflow check to dynamically keep things as ints as long as possible.

when doing int + int it is usually a win to speculate that the result doesnt overflow. in array index contexts, its always a win.

for cyphers that count on wraparound, you want to have a way to optimize out the int->double->int conversion that happens in the overflow case. (in other words cyphers want wraparound behavior).

outside of array index contexts, the jury is still out. Mike Pall made a good case for leaving everything as double.