Wrapper round x86 Assembler

[Peter Hansen]

Fuzzyman wrote:

> Peter Hansen <peter at engcorp.com> wrote in message news:<4dKdnQlIXMIXIevdRVn-gg at powergate.ca>...
> 
>>Fuzzyman wrote:
>>
>>>There might be a really good reason why this hasn't been done *or*
>>>someone might have done it and I just can't find it..... *but*
>>>
>>>what about a wrapper to an assembler (presumably for x86 assembly !)
>>>!!
>>>I just wrote some code doing binary operations which would have been
>>>about a zillion times faster in a few lines of assembly code.
>>
>>I refer you to "Pyrex"...
> 
> If I understand correctly (which is probably not likely) - Pyrex is a
> compiled language with some C syntax and some Python syntax.

Pretty much.

> Because the result is compiled, and  a step in the compile chain is
> assembly, you could include inline assembly in the same way that you
> could with C ??

Having assembly as one step in the compile chain is a somewhat
dated concept.  Many compilers go directly to object code.

> Never having done any C programming that stretches the limit of my
> knowledge.

Or exceeds it. <wink>

> *However* it's not quite what I had in mind. What I'd like to be able
> to do is to access machine code subroutines from within normal python.

Ah, you didn't say that.  You were asking about performance,
and certainly in any place where resorting to assembly would
give you that, you should be able to get it from Pyrex as well.

Pyrex might also let you interface with "machine code subroutines",
however, provided they support the standard C calling conventions
(with respect to passing args, saving registers and such).

My main reason for pushing Pyrex as opposed to discussing
options for assembly programming is that there's very little
reason for people to be doing assembly in the world these days.
C is higher level yet with an optimizing compiler allows better
performance in all but a few rare cases (meaning a few rare
problem domains and a few rare individuals).

Assembly is also the most platform-specific thing going, whereas
C is "quite" portable in comparison, whether we're talking about
the code itself or the technical knowledge of the programmer.

If you have specific code that exists and does not follow C
calling conventions, then if Pyrex won't let you call it (and
I'm guessing it won't) you could still whip up a C extension
that would, using some inline assembly there.  Or if you're
good enough at assembly to prefer it to C, you could probably
just write a Python extension in assembly directly. :-)

-Peter