On 07/17/2013 11:09 AM, wolfrage8...@gmail.com wrote:
On Wed, Jul 17, 2013 at 8:42 AM, Dave Angel <da...@davea.name> wrote:
<SNIP>
I could continue, randomly attacking other aspects of a development
environment. The point is that there are traps everywhere, and beautiful
symmetries everywhere. Learn how to recognize the former, and learn to
appreciate the latter. Learn what to do when the docs fall short (eg. drop
to assembler to see what the language construct is really doing, reverse
engineer a file format, write some code to "do it by hand," etc.).
Dave, how do I "drop down to assembler" with Python? Can you expand
on this? Also do you think it is still of value to learn Assembly
Language, and if so which variant, as I understand it, there is a
unique set for each architecture, although they are usually similiar.
There aren't many places where it's worth your time to explicitly code
in assembler these days. But that's very different from whether it's
worth studying and understanding. That is VERY useful, and IMHO will
always be.
Having said that, I've never bothered with CPython, as CPython is two
levels removed from assembler. I did with Java, so CPython probably
wouldn't be any worse.
CPython is compiled into byte code, and that byte code is its assembly
language, for most purposes. You should get familiar with that
language, either by using dis.dis, or by reverse engineering the byte
code files. It can be very informative to see how a particular
expression or statement gets transformed into the VM.
I'd love to find a debugger that let you step into the byte-code
instructions the way a good C debugger lets you switch to assembly mode.
So far, I've only statically looked at (disassembled and examined)
selected parts of the code to understand why certain constructs work
more efficiently or just differently than others.
As for "real" machine language, like the Pentium 32 bit architecture,
that's useful for understanding a traditional compiled language like C.
Notice that you usually have to turn off the compiler optimizations,
as the optimized code gets totally convoluted, and very hard to
understand. Again, you can use the shortcut provided by most compilers
where you ask it for a listing of mixed C and assembly code. That's
analogous to the dis.dis approach in CPython.
Nowhere am I recommending that everyone should WRITE in assembler. Gain
a reading knowledge of it, and it'll stand you in good stead. Step into
such code with a good debugger, and see where registers are pointing,
and try to figure out why. For example, in Microsoft's MSC compiler in
C++ mode (32bit), the 'this' pointer of C++ is almost always in EBX
register. And a call to a virtual function is done with a strange
addressing mode on that register where the machine takes the register
value, adds a constant offset to it, dereferences 32bits from ram at
that location, and does a call to that final location. And if the class
involved is virtually derived from another, there will be another
indirection or two.
--
DaveA
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
