[Python-ideas] Re: Automatic translation of Python to assembly language

[Chris Angelico]

On Mon, Sep 9, 2019 at 4:12 AM Mark @pysoniq <mark at pysoniq.com> wrote:
>
> "I don't think the ctypes wrapper in itself is very interesting."
>
> Well, we disagree on that!  I think that automatic generation of a ctypes wrapper to connect Python to assembly is interesting and a huge timesaver.
>
> "I don't know where to find those blog entries."
>
> The blogs can be reached directly at:  https://pysoniq.com/text_16.htm and there is a link "Blog" on the home page.  That link should light up when you go to the link I've just provided.
>
> If you read the 3rd & 4th entries -- Assembly Optimizations in Complex Calculations — Part 1 of 2 and Assembly Optimizations in Complex Calculations — Part 2 of 2, those blog posts contain a step-by-step breakdown of translating Python source to assembly language.  And the NASM source is linked there and is also available at the Resources link, so you can follow along between the Python source and the assembly listing.
>
> Your questions are helpful!
>

Redirecting this to python-list as this is not discussing any actual
Python language or interpreter ideas. Please remove python-ideas from
cc for future replies.

Your blog breaks the browser's Back button. Please don't do that; if
you want people to read your content, make it easy for us to do so.

How does your assembly translation cope with the possibility that
"round(h, 2)" might not call the Python standard library round()
function? You go to great lengths to show how you can optimize a
specific type of calculation that appears to be specifically relating
to floating-point math, including a number of steps that are basically
the same as a peephole optimizer could do - or, for that matter, any
programmer could easily do manually (I don't see a lot of loops in the
real world that go "for a in n" and then "v0 = a" with no other use of
a). What would happen if integers were involved? Remember, Python's
integers can happily grow beyond any CPU register - will your
transformation maintain the semantics of Python, or will it assume
that everything is floating-point?

> This line is self-explanatory.  It takes the input array "n" and loops through each data point.  The input array "n" is 64-bit double-precision floating point.

How do you ensure that this is an array of 64-bit floating-point values?

ChrisA