Wrapper round x86 Assembler

[Fuzzyman]

paddy3118 at netscape.net (Paddy McCarthy) wrote in message news:<2ae25c6b.0404100840.10668dca at posting.google.com>...
> michael at foord.net (Fuzzyman) wrote in message news:<8089854e.0404082353.7bf163a2 at posting.google.com>...
> > 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 also have fond memories of programming in BBC Basic which had an
> > inline assembler - so you could wrap your assembly program in Basic.
> > It meant some commercial games started with Basic !
> > 
> > Anyway - it would be easy to reserve some memory with a string like
> > object to pass to an 'assembly object' and allow some really nifty
> > (and fast) stuff ?? For simple algorithms it would be very neat.
> > Avoiding memory overflow etc would be up to the assembly code 'chunk'
> > of course.
> > 
> > Regards,
> > 
> > 
> > Fuzzy
> > 
> > http://www.voidspace.org.uk/atlantibots/pythonutils.html
> I.m sure that what I am about to suggest isn't as high tech as you
> were expecting ,
> but I thought that Python already has a way of accessing functions in
> a Unix
> shared library, or Windows DLL.
> If you cancompile Python on the platform than you no doubt have an
> assembler handy too.
> So, you could put your assemble language in a string; write the string
> to a file;
> assemble the file to create a shered library or DLL, then call the
> function from Python!
> 
> I don't think I'd do it that way though :-)
> 
> Cheers, Pad.



Ha - in someways this is more like what I envisioned. What would have
been nice would have been to have kept the string in memory and called
it directly....(a nice dynamic solution - for a nice dynamic language)
-  but if modern OS / processor combinations have real issues with
jumping directly into 'unoptimized' code - then it may remain a
pipe-dream... *sigh*

Regards,


Fuzzy