Re: patch to add #pushdef, #popdef to cccp,cpplib

[Andi Kleen <ak at muc dot de>]

Jeffrey A Law <law@cygnus.com> writes:

>   In message <35AD5BA1.5B32@tssc.co.nz>you write:
>   > Jeffrey A Law wrote:
>   > > Often they do not have a choice -- consider what's happened with asms
>   > > that have drifted into system include files.  And in the process of
>   > > getting wider exposure, they have uncovered fundamental flaws in the
>   > > design of the asm extensions.
>   > 
>   > This is pure curiosity: is an example of these flaws the problem with
>   > (eg) `asm ("foo %1,%0"::"r","r");' in C++ (parse error from the `::')?
> I hadn't thought of that one :-)

C++ already has these problems on it own, just try to write

	list<list<int>> x;

Fortunately there is a easy workaround that works with asm too.

Maybe it could be fixed by some scanner hacks, but I'm not sure if it 
is worth it. 

> 
> There's no clean way to say things like:
> 
>   * I need to clobber a register of a certain class (we can only clobber
>     explicit registers).
> 
>   * I need a particular value to appear in an input register at the
>     start of the asm, then the register is available as a scratch
>     register for the asm.  You can fake this with a dummy output
>     operand, but there should be a cleaner way to describe this since
>     it's a very common operation.
>    
>   * Fundamental incompatabilities between SMALL_REGISTER_CLASS machines
>     and clobbering specific registers.
> 
>   * No way to expose what register classes correspond to constraint
>     letters for input/output operands.
> 
>   * How do you describe to an asm-user how many registers they are
>     allowed to use in an asm.    Sometimes it is not obvious that
>     a particular operand may need multiple registers (to satisfy
>     reloading).  Thus it is hard for a user to write a correct asms.

    * No way to use the condition code generated by the inline assembly.

    * (ok: really hard stuff, probably impossible to do in a completely 
	general	way, but might be still needed for things like Merced):
	No way to schedule inline assembly 

    * Poor support for using lots of registers, and complete states of parts
      of the CPU. I discovered this while trying to port MMX functions from
      VC++ to gcc inline assembly. gcc nearly always breaks down whe the 
      inline function needs lots of registers; I ended up with having to
      move them to a separate, pure-assembler function and take the overhead
      of the function call. 

      Also on x86 it seems to be impossible to tell gcc that inline functions
      clobbered the FPU stack (like MMX functions do), it was always needed
      to write the saving explicitely and pray that the compiler does not 
      insert any Floating point inbetween.   	 		 	
	     	
	
-Andi