Re: -fasm=intel not always suppported

[Mike Stump <mrs at apple dot com>]

On Nov 15, 2005, at 12:23 PM, Andrew Pinski wrote:
> It will never work on for an example of s390, arm, hppa, ia64, etc.

Odd, it was designed to work on other architectures.  You must  
misunderstand something rather basic.

> Some of those are the primary targets so you are saying this feature
> will only work on two targets.

It will work on any target that cares to have it work.  Porting isn't  
zero work, but is as cheap as I can make it.

> Also this discussion should have take place in public as shown above
> it does not work for all targets.

What discussion?  I've been busy implementing...  I've yet to start  
up discussions, when I do, you all will notice, as it is a big barn,  
and there are lots of potential colors we all want to paint it.

> New instruction which I just made up:

Be sure to tell intel and AMD, as I don't think their chips support,  
anyway, I already support it:

mrs $ ./xgcc -B./ -fasm-blocks -x c++ s1.c -S -msse3
mrs $ cat s1.s
        .text
        .align 1,0x90
.globl __Z3foov
__Z3foov:
LFB2:
        pushl   %ebp
LCFI0:
        movl    %esp, %ebp
LCFI1:
        subl    $8, %esp
LCFI2:
        .file "s1.c"
        .line 2
        tsains %xmm3, %st
        leave
        ret
LFE2:
        .globl __Z3foov.eh
__Z3foov.eh = 0
.no_dead_strip __Z3foov.eh
        .constructor
        .destructor
        .align 1
        .subsections_via_symbols
mrs $ cat s1.c
void foo() {
  asm { tsains st(0), xmm3 }
}

?  What was your point exactly, as I think I'm just not getting it?

> tsains which takes two operands, one is the top of the fp stack and  
> another
> is a SSE register, there is no way currently in your model to  
> support this
> except to release a new GCC.

That isn't true, next.

> The correct way of implementing this would be create a file which  
> is read
> in for the targets at compile time.

Yup, exactly.  Trivial enough to do.

> This would make it easier to support more targets faster instead of  
> changing
> the target macros.  Also if I look at the Apple branch I notice a  
> lot of
> if TARGET_I386 inside stuff like c-decl.c and such which is just  
> wrong.

Yes, I know.  It is undergoing development still.