translating Python to Assembler
usenet-mail-0306.20.chr0n0ss at spamgourmet.com
Mon Jan 28 16:00:25 CET 2008
over at thepond.com wrote:
> Bjoern Schliessmann wrote:
>> over at thepond.com wrote:
>>> That's not the point, however. I'm trying to say that a
>>> processor cannot read a Python script, and since the Python
>>> interpreter as stored on disk is essentially an assembler file,
>> It isn't; it's an executable.
> I appreciated the intelligent response I received from you
> earlier, now we're splitting hairs. :-)
Not at all. Assembly source is ASCII text. An executable commonly
consists of a binary header (which contains various information
=> man elf) as well as code and data segments. Normally, you're only
guaranteed to find machine language inside the code segments.
> Assembler, like any other higher level language
Assembler is _no_ high level language, though there are some
assembly languages striving for resembling HLLs.
> is written as a source file and is compiled to a binary.
BMPs are binaries, too. Assembly code is compiled to object code
> An executable is one form of a binary, as is a dll. When you view
> the disassembly of a binary, there is a distinct difference
> between C, C++, Delphi, Visual Basic, DOS,
I don't think so. How a HLL source is translated to machine code
depends on the compiler, and there are cross compilers.
> or even between the different file types like PE, NE, MZ, etc.
> But they all decompile to assembler.
No. They all _contain_ code segments (which contain machine code),
but also different data.
> While they are in the binary format, they are exactly
> Who would want to interpret a long string of 1's and 0's. Binaries
> are not stored in hexadecimal on disk nor are they in hexadecimal
> in memory. But, all the 1's and 0's are in codes when they are
> instructions or ASCII strings.
No -- they're voltages or magnetic fields. (I never saw "0"s or "1"s
in a memory chip or on a hard disk.) The representation of this
data is up to the viewing human being to choose.
> No other high level language has the one to one relationship that
> assembler has to machine code, the actual language of the
Yes. That's why Assembly language is not "high level", but "low
> All the ASCIi strings end with 0x74 in the disassembly.
> I have noted that Python uses a newline as a line feed/carriage
(The means of line separation is not chosen just like this by Python
users. It's convention depending on the OS and the application.)
> Now I'm getting it. It could all be disassembled with a hex
> editor, but a disassembler is better for getting things in order.
Argl. A hex editor just displays a binary file as hexadecimal
numbers, it does _not_ disassemble.
"Disassembly" refers to _interpreting_ a file as machine
instructions of one particular architecture. This, of course, only
makes sense if this binary file actually contains machine
instructions that make sense, not if it's really a picture or a
BOFH excuse #130:
More information about the Python-list