Proposal for Fast(er) Bitwise Operations

Is it possible, through the return bug, to turn an integer into a string using the same bits? Then, manipulate that string using natives to perform operations such as xor, and, or, etc, via lookup tables? Optimally 16 would be used to have a smaller lookup table, or create a function that will fill the table on startup.

I was just thinking that if, instead of costly slowly parsed math functions which must be executed over and over, the string manipulation natives could be used.

Although it may be faster just to convert the integer to base-16 and manipulate it from there. Then, by using string manipulation, many of the functions of which are natives, it may be possible to do faster bitwise arithmatic than previously possible. This would allow more advanced encryption and hashing functions to be utilized to protect and save map data for keys.

Return bug casting strings returns their index in the internal string array, at least that's what we think. So casting an integer to a string will either return some random string (if it's on the array) or a pointer to a not existing string which might very well be a null-string, empty string or maybe even crash the game.

Anyway the string you will get, won't have much to do with the actual value.

Ok then, what about quickly translating a string into Base-16 and performing the operations with lookup tables? I mean, arithmatically the method used currently (just from seeing the JASS Vault) is as fast or the fastest possible. But obviously this could be sped up from the use of lookup tables. The code would increase in size but overall you might get a lot faster performance. It may simply be faster because it would take fewer function calls, eh?

Edit: What I meant was, as far as logical functions go, that's as fast as it could purely mathematically. But since JASS is so slow every line, every function call slows down the equation. I believe it would be faster if we performed a fast Integer -> Hexadecimal operation and then used lookup tables, with corresponding table for Hexadecimal -> Integer. Despite the added steps at the beginning and end it could be faster.