Visual C++ style inline asms

Visual C++ style inline asms

[Mike Stump]

Any objections to adding Visual C++ style inline asms?

Re: Visual C++ style inline asms

[Andrew Pinski]

On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:

> Any objections to adding Visual C++ style inline asms?

Didn't RTH objected the last time?

-- Pinski

Re: Visual C++ style inline asms

[Daniel Jacobowitz]

On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote:
> 
> On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:
> 
> >Any objections to adding Visual C++ style inline asms?

Mike, you're going to get more useful feedback if you ask a question
with some details in it.  Not all of us use Microsoft compilers.

> Didn't RTH objected the last time?

You can find plenty of information about this in the archives.  I
recall Stan Shebs discussing it at length.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Visual C++ style inline asms

[Mike Stump]

On Tuesday, June 14, 2005, at 06:29  PM, Daniel Jacobowitz wrote:
> On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote:
>>
>> On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:
>>
>>> Any objections to adding Visual C++ style inline asms?
>
> Mike, you're going to get more useful feedback if you ask a question
> with some details in it.  Not all of us use Microsoft compilers.

:-)  Don't worry, so far, I am just consensus building to prep people 
for the idea, that, one day I suspect that we may well be doing it.  No 
one said over my dead body.  :-)

I don't know off-hand, how exactly MS asm differs from C asms, nor all 
the details of MS asms, so I can't give many details.  If people want 
to see what this type of support looks like, as CW asm support, they 
can check out the current apple branch.

If someone wanted to describe MS asms in detail, I'd be interested.  
Maybe the wiki would be a good place to home it.

Re: Visual C++ style inline asms

[Steven Bosscher]

On Thursday 16 June 2005 00:45, Mike Stump wrote:
> If someone wanted to describe MS asms in detail, I'd be interested.
> Maybe the wiki would be a good place to home it.

I'm interested too, but wouldn't that be something _you_ could do
to show what we're actually talking about? :-)  Putting the collected
wisdom of previous threads on CW/MS assembler syntax is also useful
I suppose, so we have a place to point people at when this question
comes up again of why GCC doesn't support this already...

Gr.
Steven

Re: Visual C++ style inline asms

[Richard Henderson]

On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote:
> On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:
> >Any objections to adding Visual C++ style inline asms?
> 
> Didn't RTH objected the last time?

One has to do a less gross job of it than Red Hat did.  I suppose
I could be prodded into pulling out the code so that you can see
where the bar is.

You'll need and EXTREMELY large testsuite.  You'll find that the MS
documentation is useless, and you'll have to deduce the desired
semantics from customer code bases.  Presumably Apple can find 
large customers who will want this kind of thing and can arrange
to code exchanges in some way, if only NDA.  But if NDA, I expect
reduced test cases to make their way into our testsuite.

Expect to want to implement "naked" functions as well, because MS
does, and quite a lot of VC++ inline asm code expects to use them.
Expect me to barf on your shoes.

I don't recall if Darwin uses %ebx for pic code like ELF.  If you
do, expect to find that lots of user code expects to be able to
clobber it, because Windows doesn't do pic code at all, and so
reserves no such register.

I suspect that one could get quite a lot of milage out of parsing
the assembly code and turning most of it into straight GIMPLE, rather
than into ASM_EXPRs.  A great many examples of VC++ inline asms that
I've seen were completely and utterly trivial; the compiler could have
done a better job.  Of course there will be cases that you either
can't understand, or use instructions that don't map to an EXPR or a
builtin.  But I expect that more often than not, you can reduce the
inline asm block to one such insn, and expose all the rest of the
data movement to the compiler.



r~

Re: Visual C++ style inline asms

[Graham Stott]

--- Richard Henderson <rth@redhat.com> wrote:

> On Tue, Jun 14, 2005 at 09:26:11PM -0400, Andrew Pinski wrote:
> > On Jun 14, 2005, at 9:25 PM, Mike Stump wrote:
> > >Any objections to adding Visual C++ style inline asms?
> > 
> > Didn't RTH objected the last time?
> 
> One has to do a less gross job of it than Red Hat did.  I suppose
> I could be prodded into pulling out the code so that you can see
> where the bar is.

It was a nightmare to get the large test apps working, they had inline asms
that spaned several pages of A4 with emmbeded labels, control flow, and
other cruff which was why it ended up being so gross.

Also when combined with C++ Templates even the upfront parsing of the
asm gets hairy very quickly.

Graham

Re: Visual C++ style inline asms

[Mike Stump]

On Wednesday, June 15, 2005, at 07:35  AM, Graham Stott wrote:
> they had inline asms that spaned several pages of A4 with emmbeded
> labels, control flow, and other cruff which was why it ended up being 
> so gross.
>
> Also when combined with C++ Templates even the upfront parsing of the
> asm gets hairy very quickly.

Been there done that, doesn't scare me.  :-(  You can check out the CW 
asm support in the apple branch if you want to compare/contrast 
implementations.

Re: Visual C++ style inline asms

[Mike Stump]

On Tuesday, June 14, 2005, at 10:08  PM, Richard Henderson wrote:
>> Didn't RTH objected the last time?
>
> One has to do a less gross job of it than Red Hat did.

I did go back and re-reread all the useful content you, and others 
gave.  I did expect that all past concerns raised remain and that we'd 
be expected to find some `reasonable' way to address all those, and all 
the ones that would come up during the development of the feature.  You 
and Mark I think raised the highest bars, but I remain hopeful that 
there is a solution that is low enough impact in other areas of the 
compiler, and yet adds the required functionality.  I think the CW asms 
stuff was a good learning experience for us.

> I suppose I could be prodded into pulling out the code

I don't want to so prode you right now.  If/when we start up a project 
to do it, I'd be interested in things like testsuite (testcases) and 
the description for how the parser was wired in for C++, if you liked 
the way it was done, as our CW version feels too duplicative and more 
invasive than ultimate I think I'd like.

> You'll need and EXTREMELY large testsuite.  You'll find that the MS
> documentation is useless, and you'll have to deduce the desired
> semantics from customer code bases.

Yeah, been there, done that.  Ultimately, I sure we'd miss some 
important bits in the first couple of versions, but as people pumped 
code through it, we'd get them in.  I am not confident that I could get 
enough help (enough testcases) fast enough to have it all done in the 
first stage.

> I don't recall if Darwin uses %ebx for pic code like ELF.  If you
> do, expect to find that lots of user code expects to be able to
> clobber it, because Windows doesn't do pic code at all, and so
> reserves no such register.

Ultimately, one just has to slowly and carefully describe it for the 
optimizer, in the existing language the optimizer uses.  The CW asms 
were done using use ASM_EXPRs, and we got a lot of milage out of that 
route. Fundamentally, if other constructs are a better match, it would 
be better to use them.  Take for example a __builtin_opcode_blabla and 
blabla r1, r2, n1, instead of generating asm ("blabla .... ), we'd call 
__builtin_opcode_blabla (r1, r2, n1), and then let it generate what 
ever it does.  If all instruction had  a gen_blabla () or 
__builtin_opcode_blabla(), trivially, one would avoid any ASM_EXPRs and 
just use them all.  The advantage to that style is then the optimizer 
can know what is going on, and that ultimately, I think is required.  
Also, I can see how to wire that style of support into the compiler 
cleanly.  The CW support didn't require invasive changes to the 
optimizer.  I'm hoping the worse case scenario for x86 support would be 
the i387 fp stack and the carry flags and other status bits, and not 
something like reload.

> I suspect that one could get quite a lot of milage out of parsing
> the assembly code and turning most of it into straight GIMPLE,

Yes, this is the direction I'd want to do.

Just so others have an idea of how invasive it might be, the CW asm are 
strapped in with 67 multiline hunks, and 33 single line changes.  I'd 
hope/expect that MS asms would similar.

Re: Visual C++ style inline asms

[Michael Meissner]

On Tue, Jun 14, 2005 at 10:08:16PM -0700, Richard Henderson wrote:
> I suspect that one could get quite a lot of milage out of parsing
> the assembly code and turning most of it into straight GIMPLE, rather
> than into ASM_EXPRs.  A great many examples of VC++ inline asms that
> I've seen were completely and utterly trivial; the compiler could have
> done a better job.  Of course there will be cases that you either
> can't understand, or use instructions that don't map to an EXPR or a
> builtin.  But I expect that more often than not, you can reduce the
> inline asm block to one such insn, and expose all the rest of the
> data movement to the compiler.

My previous employer (Metrowerks) did this when parsing GCC style asm
instructions, and it caused lots of complaints from users.  The main complaint
is users did not want the compiler mucking about with their precious hand
scheduled insns, and made it much harder to debug.

Another problem is when things like status registers or flags fields aren't
adequately handled by the compiler.  For example on the x86, if you change the
rounding mode, we currently don't have a (USE) of the flags field, so the
compiler doesn't know that it can't move the set rounding mode instruction
before other floating point instructions.  Obviously, the right solution is the
encode all of this hidden state information into the RTL, GIMPLE, etc. but it
is a large and mind numbing process.

Finally, for the x86/x86_64, there are a lot of instructions that need to be
handled, and it is an ongoing maintenance problem in that you now need to
modify GCC as well as binutils to add new instructions.

-- 
Michael Meissner
email: michael.meissner@amd.com

Re: Visual C++ style inline asms

[Andi Kleen]

Mike Stump <mrs@apple.com> writes:

> Any objections to adding Visual C++ style inline asms?

Doesn't that need support to parse assembly? (= essentially
a builtin assembler). How else would the compiler
know what registers are clobbered and where to put input/output
variables?

All compilers i've seen who supported that had builtin
assemblers. 

-Andi

Re: Visual C++ style inline asms

[Mike Stump]

On Tuesday, June 14, 2005, at 06:29  PM, Andi Kleen wrote:
> Doesn't that need support to parse assembly?

CW asm support needed this.  I'd expect that MS asms would too, but I'm 
not an expert, yet.  That support is substantially less support than 
gas.

RE: Visual C++ style inline asms

[Bobby McNulty]

>-----Original Message-----
>From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
>Mike Stump
>Sent: Tuesday, June 14, 2005 8:25 PM
>To: GCC Mailing List
>Subject: Visual C++ style inline asms

>Any objections to adding Visual C++ style inline asms?

This will greatly help us for those of us who want Visual C++ source to work
under GCC. I use both GCC and Visual Studio.

Re: Visual C++ style inline asms

[Ranjit Mathew]

Mike Stump wrote:
> Any objections to adding Visual C++ style inline asms?

Apart from what's been pointed out by RTH, you might
also want to read the messages from the previous
discussion on this subject initiated by Stan Shebs,
if you haven't already:

  http://gcc.gnu.org/ml/gcc/2004-05/msg00070.html

Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/