[damien morton] > Its arguable which is more obscure, the x86 assembly instruction "jo" > (jump if overflow), or the xor trickery in C. <wink> It's not just the assembler, it's also the world of delicate assumptions about how the compiler interleaves generated C code with the forced inline assembler, how that affects optimization in general (see Chris Tismer's post about that), and how brittle that all is. One example of the latter: an idea that resurfaces from time to time is to make Python "short ints" the platform spelling of a 64-bit int. The C overflow-checking code wouldn't be affected by that (part of the reason it's obscure is that it makes no assumption about the size of a Python int). With the inline assembler, though, it would just break -- jo would pick up some accidental setting of the overflow flag under MSVC, or we'd have to arrange to generate __int64 addition code that set the flag the way the macro expects. For a little speedup on the sole operation(s) it targets, it's just not worth the ongoing puzzles. BTW, I'm not sure it's possible to buy a PC anymore less than twice as fast as the one I'm using right now <wink>. > I take your point, though, about there being no assembly in python now. There's one place I wish there were: I wish Jeremy had time to fold in his bit of assembler to read the Pentium's clock register. That's a wonderful facility we can't get at now, and the assembler would be limited to a tiny and isolated function.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4