Wrapper round x86 Assembler

[Fuzzyman]

[snip..]

> 
> > 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.
> 
Right ? I got confused by the mention that they could handle inline
assembler.... so many of the compilers include an assembler as well...
purely for 'inline assembly'.... ??

> > Never having done any C programming that stretches the limit of my
> > knowledge.
> 
> Or exceeds it. <wink>
> 
*ahem* - well yeah.
I've never coded in C, but I've done some assembly language
programming for the Amiga (the 68000 series processor - great to
program). I had to learn  a little bit about C because I had to build
C structures to pass to the operating system which was written in C
(well, written in B first, and then recoded in C ). That was all a
while ago though.

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

No... but I said something similar ;-)

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

Right - if I was to pursue this I would certainly need to use
something to build a wrapper interface.

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

However, I was *hoping* for a more dynamic solution than the 'compiler
chain' one.

I recently did some coding that involved classic 'bit-twiddling' (for
want of a better expression). One textbook I found showed a similar
example and said 'this is a good example of code that would be much
better written in assembly'.

My past experience of assembly was using an operating system that
handled multitasking 'behind the scenes' (pre-emptive multitasking) -
so there was no performance hit on the rest of your system from
writing crappy assembly - and the internal architecture of the
processor was useful enough to make coding fun.....

> 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

Hmmm..... oh well. Maybe my idea of dynamically assembled 'assembly
subroutines' for high speed number crunching is a pipe-dream. It
seemed like a good idea.

It does occur to me that for a certain subset of a 'pseudo assembly
language' a 'cross-platform assembler' could work (dynamically
assemble directly to machine code - easy enough to build binaries per
platform) and include the alogrithms mentioned by the other
posters.... :-) Nice idea - well beyond me though. It's easy enough to
have ideas that other people ought to do.

Regards,

Fuzzy

http://www.voidspace.org.uk/atlantibots/pythonutils.html