>>>> I think the decompilers are also called REVERSE COMPILERS
>>> They are simply called "compilers".
>>> A compiler is a program for translating a program written in one
>>> language into the same program written in another language. That the
>>> source language happens to be x86 machine code (or whatever) and the
>>> target language C or C++ or whatever really makes no difference at
>> If you're being serious I don't think I agree, although I'm having a
>> hard time coming up with a cogent argument. Maybe it has something to
>> do with the x86 m/c input not really being (directly) "written" by a
>> user. I wonder, too, if "compile" doesn't imply going from high-level
>> source **text** (of some kind) to low-level **binary** (of some kind).
> "Simply stated, a compiler is a program that reads a program written in
> one language - the /source/ language - and translates it into an
> equivalent program in another language - the /target/ language." - Aho,
> Sethi, and Ullman, "Compilers: Principles, Techniques, and Tools".
> Nothing in there about "levels". :-)
Pretty authoritative source, too!
Nevertheless, I persist (in fun). Question: how many pieces of software
which *call* themselves "compilers" do you know that translate a low-
level source to a high-level source?
Also consider that compilers (almost always) take *text* files as input,
but de-compilation takes binary object code and emits text.
And I wonder if I can thrown in the idea that that object code isn't
"written" in the usual sense meant wrt source code.
Shooting off on a tangent, hey, how about an "assembler" that takes
*written* assembly and translates that to a high-level language?... ;-\
At least you'd have all the object names handy!
Wonder what the "optimizing" version would be like!
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
Opinions expressed herein are my own and may not represent those of my employer.