translating Python to Assembler

[Bjoern Schliessmann]

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. 

http://webster.cs.ucr.edu/AsmTools/HLA/index.html

> is written as a source file and is compiled to a binary. 

BMPs are binaries, too. Assembly code is compiled to object code
files.

> 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. 

Yes.

> 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
> that...binary. 

http://en.wikipedia.org/wiki/Binary_data

> 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
> computer. 

Yes. That's why Assembly language is not "high level", but "low
level".
 
> All the ASCIi strings end with 0x74 in the disassembly. 

*sigh*

> I have noted that Python uses a newline as a line feed/carriage
> return.

(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
sound file.

Regards,


Björn

-- 
BOFH excuse #130:

new management