> Check out:
> http://www.delorie.com/djgpp/v2faq/faq135.html#Syntax
> for differences in assembly syntax and tutorial references, and
> http://www.delorie.com/djgpp/v2faq/faq136.html#Converting ASM
> for some scripts and stuff for converting syntaxes, and references for
> NASM and JAS.
>
Lets change this subject to Linux-asm
> Contributions of code to support Intel syntax directly would be
> welcome. (Of course it has to be well-written, as much as that's
> possible in the gas code base, assigned to the FSF, etc., etc.) Or
> you may be able to pay someone already familiar with both syntaxes to
> do the work. But please don't spew complaints and insults just
> because no one has volunteered the time already.
>
I thank you for your response. I did not do anything by echo the
acid remarks emitted by the GAS Assembler.
I have been forgoing comment on Linux Assembly Language and the
available tools until my demonstration was complete. I have
written some Assembly code and come 'C' code to check its
correctness and execution speed.
I won't consume any more bandwidth on this list until some
interested programmers have reviewed my paper and checked out
the code.
Typical output from the test program, testing a procedure that
is essential in kernel programming (unnamed here) is:
Verifying ASM code
Counting C loops for 2 seconds
Counting ASM loops for 2 seconds
C routine : 44263
AS routine : 539274
Change : 12.18 times faster
AS clocks : 573 clocks/byte : 0.28
C clocks : 16017 clocks/byte : 7.82
A paper, source code, and examples are available via anonymous
ftp from:
boneserver.analogic.com pub/downloads/linux/linux-asm.tar.gz
(I'm expecting 1,000 hits per second ;)
> There are very strong reasons gas supports the AT&T syntax, namely its
> primary use as a back end to gcc and the predominance of that syntax
> on UNIX platforms. If you think that the change in syntax was a bad
> move, you could complain to AT&T, but it's years too late.
>
True -- but read on.
> There are obviously reasons why it would be nice to support Intel
> syntax too. But, equally obviously, those reasons haven't been
> important enough for anyone else to do yet. If it's important for
> you, then you're volunteered. :-)
>
It is important to me. I want you to read my paper and review my
assembly code. Then I want you to tell me if you think I should
write an Intel extension to GAS or if you think my talents would
be better served by writing some assembly-language for some Linux-
kernel procedures.
> And if you don't at least consider it, then apparently it's not that
> important to you either. (I mean, important for *gas* to support
> Intel syntax. Clearly finding *something* that will support it is
> important to you, and whether that thing needs to be gas is an
> entirely separate question.) Which would be fine too. Maybe someone
> else will do it someday. Maybe not. Free software is like that.
I __think__ Intel Assembly. There are others like me. If we could
put '.Intel' on the first line of a GAS source-script, I could make
some severe improvements in some kernel bottle-necks. If I have
to translate, it becomes very, very, hard. GAS's idea of a MACRO
is like C's idea. It just replaces text. A good MACRO Assembler
does much more than that. In my test program, I had to write a
'C' program to generate the instruction stream I required.
Also, check out the source, in particular the code-generator,
codestream.c, which generates codestream.S. There are GAS bugs
(features?) I had to work-around.
The last line in my Paper states Linux is not Unix. Unix is
a primative subset.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.127 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/