This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A patch for linux 2.1.127



I let me say up front that I've never done assembly language under Linux,
I'm mostly a C++/Java guy.  I've done 80x86 ... actually 8086, if we must
date it .. under DOS.  Don't want to do it, that's what c is for.

My comment about speed was really about control, my understanding was that
gas syntax was not tailored to the 80x86, and therefore there were some
problems with dropped registers and such.  This was inferred from reading
this thread, and may have been incorrectly inferred ... my understanding
is that gcc pipes the same thing to gas regardless of platform, and gas
has to figure out from that which registers to allocate where ... which
barring magic would have to effect the code somewhere.

The point I was trying to make, though, was that gas was a tool that
speaks one language, and rather than railing against that tool for not
speaking the language you want it to speak, one should use a tool that
does speak that language, or write a translator, or hack the tool you've
got.

--------
Where do you want to crash, toady?
On Thu, 12 Nov 1998, Joe Buck wrote:

> 
> > It seems to me like that tool exists, but it's not gas.  gas can't be all
> > things to all people, and I think it is intented to speak a pseudo
> > assembly language which is portable.  As always, portable code is not
> > nessisarily what you want, sometimes speed is more important.
> 
> I am puzzled by such remarks.  gas is real, not pseudo, assembly language;
> one gas instruction becomes one machine instruction.  There is absolutely
> no effect on speed.  There are only two differences between Intel's
> assembler and gas:
> 
> * Intel has a macro preprocessor.  Unix folks use the C preprocessor or m4
>   to get the same effect, but since the main use of the assembler is as a
>   target for the compiler, a basic assembler that just does what it's told
>   is considered desirable.
> 
> * Intel has different syntax for the instructions.  This is purely a
>   matter of syntax; a 1-1 translation is possible.
>  
> Given this, anyone who has the idea that there is any kind of speed
> sacrifice imposed by using gas is simply misinformed.  gas turns one
> assembly instruction into one machine instruction; the input to gas
> exactly specifies what instruction is used.
> 
> The only reason you should care is if you have existing code in Intel
> assembly syntax that you want to use.  What's needed, as someone else
> said, is a tool that takes Intel syntax, does the macro processing and
> syntax conversion, and produces gas-format output.  If this tool existed,
> it would impose a zero-cycle time penalty and a zero-word space
> penalty: the exact same object code would be produced.
> 
> The folks out there who are in love with Intel syntax are invited to
> contribute code.  That's how the Linux and GNU communities work:
> people who aren't satisfied write new code to make things better.
> 
> 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]