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

[Bill Currie]

Jeffrey A Law wrote:
> 
>   In message < 35AD5BA1.5B32@tssc.co.nz >you write:
>   > 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 :-)

Haha, nice to inform (remind?) you of something for a change!

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

Yeah, that *would* be nice.  I think I wanted that a couple of times
myself.

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

Hmm, I wander if a define_expand derived syntax might help.  Maybe
something like:

asm ([ ("insn" : "output" : "input" : "clobber") /* init insn */
       ("" : : : "clobber") /* clober some regs, allowing them to be
used for
                               scratch regs*/
       ("another insn" : "output" : "input" : "clobber") ]); /* final
outptu */

Some sort of mechanism would be needed for specifying the migration of
outputs of previous insns to the inputs of following ones (possibly just
the existing mechanism for input/output register overlap will suffice).  

This might help with the spill (?) problem you mention below.  It could
also allow the asm statement to be optimised a little (eg deleting
redundant operations, I can think of some x86 specific examples).  As to
the clobbering of classes, I guess a new clobber syntax is needed, but
then with a new asm format, new constraints/clobbers syntaxes aren't a
problem.

The nice thing is, the old extended asm syntax is not broken with this. 
I guess this could be the uber-asm syntax :).

One thing I had thought of a while ago that would be nice: the ability
to write rtxen in C.  However, this may be totally irrellevant,
especially with a halfway decent asm syntax.

>   * Fundamental incompatabilities between SMALL_REGISTER_CLASS machines
>     and clobbering specific registers.

Ouch.  I take it the x86 is one of these.  Isn't this is a problem with
internal rtxen as well?

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

Wouldn't these just need complete machine specific documentation?  Mind
you, it would be nice if these details could be machine independent, but
I suppose that's mostly impossible.

> asms are probably the best designed & implemented extension in the
> compiler, yet we still have major problems with them.

Oh!  Actually, can't that be said about the entire C++ language?:)

> Most of those problems can be fixed.  We'll probably end up doing it
> at some point.

Hope I can help!

Bill
-- 
Leave others their otherness