So, what would you call studying the code for the fast inverse square root[1] in the Quake source code so you truly understand it, to the point you can explain what it does to someone else without invoking words like "magic" or similar?
Because I'm pretty sure most devs would not just read the code and go "ah yes, of course".
I'd argue that understanding disassembled assembly could be considered reverse engineering, which would logically extend to source code unless we draw the line at compilation
Reductively, software engineering means taking an idea and mapping it into code. So one form of "reverse" engineering would be taking the code and extracting the ideas. That's what we did here.
Because the source is public, there's quite a lot to work with from the start -- the warp specializations are named and there are helpful comments in many places.
But for many components, we didn't have much. Maybe the clearest case of "reverse engineering" explained in the post is with the cubic approximation for the rational part of the exponentiation. That required staring at some inline assembly and doing math.
I've never heard of this definition of reverse engineering -- when one has the unobfuscated actual source code I'd usually call it: reading the code, or something like summarization.
Not trying to be uncharitable, I found your article informative. Reverse engineering has historically been reserved for cases where there is an adversial aspect, as in binaries or server APIs. Anyhow, Cheers and thank you, sincerely.
Reading the source code is one thing, understanding it is another. Reverse engineering source code can be as simple as figuring out the original meaning/intent behind the code when it isn't immediately obvious or documented.
Is reading the source code reverse engineering?
So, what would you call studying the code for the fast inverse square root[1] in the Quake source code so you truly understand it, to the point you can explain what it does to someone else without invoking words like "magic" or similar?
Because I'm pretty sure most devs would not just read the code and go "ah yes, of course".
[1]: https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...
The content is good. I’m glad i ignored a similar negative reaction to the reverse engineering framing.
I'd argue that understanding disassembled assembly could be considered reverse engineering, which would logically extend to source code unless we draw the line at compilation
I'm pretty sure it's called "reading the code". That said, it is difficult enough in its own right.
Hey, one of the authors here!
Reductively, software engineering means taking an idea and mapping it into code. So one form of "reverse" engineering would be taking the code and extracting the ideas. That's what we did here.
Because the source is public, there's quite a lot to work with from the start -- the warp specializations are named and there are helpful comments in many places.
But for many components, we didn't have much. Maybe the clearest case of "reverse engineering" explained in the post is with the cubic approximation for the rational part of the exponentiation. That required staring at some inline assembly and doing math.
I've never heard of this definition of reverse engineering -- when one has the unobfuscated actual source code I'd usually call it: reading the code, or something like summarization.
Not trying to be uncharitable, I found your article informative. Reverse engineering has historically been reserved for cases where there is an adversial aspect, as in binaries or server APIs. Anyhow, Cheers and thank you, sincerely.
That time when I reverse engineered JRR Tolkien‘s Lord of the rings from symbols engraved on dead trees. Took me three summers…
I reverse engineered above comment by reading it and extracting the idea.
Reading the source code is one thing, understanding it is another. Reverse engineering source code can be as simple as figuring out the original meaning/intent behind the code when it isn't immediately obvious or documented.