[RFC v2] Towards an assembler parser for PowerPC

[Bill Schmidt]

On Tue, 2013-03-19 at 10:54 -0700, Kevin Enderby wrote:
> On Mar 19, 2013, at 7:32 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote:
> 
> > On Mon, 2013-03-18 at 12:08 -0700, Kevin Enderby wrote:
> >> Hi Ulrich,
> >> 
> >> One comment below which I previously emailed David on.
> >> 
> >> Kev
> >> 
> >> On Mar 18, 2013, at 11:55 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:
> >> 
> >>> David Fang <fang at csl.cornell.edu> wrote on 14.03.2013 00:32:56:
> >>> 
> >>>>   Just wanted to ping and ask how close we are to seeing
> >>>> PPCAsmParser.  I've made good progress on the mach-o/PPC backend, but
> >>> have
> >>>> run into a few blocks.
> >>> 
> >>> I've been out sick for the past two weeks and didn't make any progress,
> >>> sorry.  But I'm back working on the asm parser now ...
> >>> 
> >>> One piece of good news is that Jakob has been looking at some of the
> >>> common TableGen changes, and it looks like this is close to getting in.
> >>> 
> >>>> 1) lib/Target/PowerPC/PPCAsmPrinter.cpp:PPCDarwinAsmPrinter emits a
> >>>> bcl instruction in the stub for dynamically linked functions.
> >>>> Would it be easy to MC-ize the bcl (branch-conditional-link) instruction?
> >>> 
> >>> Well, at some point we'll have to add the full set of branch instructions
> >>> anyway to support the complete instruction set in the parser; I've
> >>> considered
> >>> that to be a follow-on step after the first instance of the parser gets
> >>> committed ...
> >>> 
> >>> In any case, adding a new pattern (with isCodeGenOnly = 1) to be
> >>> generated by PPCDarwinAsmPrinter ought to be straightforward for now.
> >>> 
> >>> For my curiosity:
> >>> 
> >>>     OutStreamer.EmitRawText("\tbcl 20, 31, " + Twine(AnonSymbol->getName
> >>> ()));
> >>> 
> >>> bcl 20 ... seems to imply an unconditional branch after all.  Do you
> >>> know why this can't just use a plain bl?
> >> 
> >> Basically it is a branch and link instruction but causes the processor to not put the return address in the link register stack.  As this is the pic code that is branching to itself to get the pc into a general register.  And thus will never return to that address.
> > 
> > Hi Kevin,
> > 
> > Sorry to poke my nose in, but I wonder whether this is correct.  There's
> > no documentation in the ISA to indicate this is expected behavior.  I
> > suppose it's possible that there is a specific hardware implementation
> > for G5 that I'm not aware of, but from an ISA standpoint "bl" and "bcl
> > 20" are equivalent.
> > 
> > There is support for avoiding polluting the link cache with return
> > instructions in the bclr[l] and bcctr[l] instructions, by specifying
> > particular values in the BO field.  But I can't find any reference to
> > such hints for bcl.  If you have some documentation on this behavior, I
> > would certainly be interested.
> 
> Hi Bill,
> 
> I have paper documentation on this (sorry it was a long time ago when I did this work and we didn't have pdf's).  In my book:
> 
> PowerPC Microprocessor Family: The Programming Environments
> MPRPPCFE-01 MPCFPE/AD 9/94
> 
> on page 4-54 it says:
> 
> Some processors may keep a stack of the link register values most recently set by branch and link instructions, with the possible exception of the form shown below for obtaining the address of the next instruction.
> …
> Obtaining the address of the next instruction - use the following form of the branch and link:
> bcl 20,32,$+4
> 
> I do recall having to point this out the IBM guys as there was a bug in the first 750 ppc silicon that did not honor this (which I think was the first cpu to have a link register stack).  I'm sure I kept that email from almost 20 years ago but it would take me a lot of work to find it. If you REALLY REALLY nee d that let me know and I may be able to dig it up.
> 

Kevin, thanks, that clears it up.  I appreciate it!

This language does appear in the IBM PowerPC ISA document, but only in
the 2.06 version.  I missed the sentence about the exception for this
form when I was looking back through the various versions.  Since this
was a Darwin issue I was concentrating on v.2.03.

It sounds like from what you're saying that this form has been expected
to be used in this manner for quite a while, but apparently this only
made it into the official Power documentation during the Power7
timeframe...interesting.

Thanks again for the information!

Bill

> > 
> > Could you please double-check whether this works as you intend?  If not,
> > it would be simplest to just replace the bcl with a bl.
> 
> Again that was my suggestion too to get things going.
> 
> > 
> > Thanks,
> > Bill
> > 
> >> 
> >>> 
> >>>> 2) Some of the system C++ headers (4.0.1) have inline asm, so I'm unable
> >>>> to compile an <iostream> hello-world using the integrated-assembler.
> >>>> 
> >>>> clang gripes:
> >>>> fatal error: error in backend: Inline asm not supported by this streamer
> >>>> because we don't have an asm parser for this target
> >>>> 
> >>>> (A <stdio.h> version in C works though.)
> >>>> I assume the PPC asm parser will solve this?
> >>> 
> >>> Yes, this should be supported with the asm parser.  (Of course, assuming
> >>> that the particular instructions used in those inline asm statements are
> >>> already supported.)
> >>> 
> >>> Bye,
> >>> Ulrich
> >>> 
> >>> _______________________________________________
> >>> llvm-commits mailing list
> >>> llvm-commits at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> 
> >> _______________________________________________
> >> llvm-commits mailing list
> >> llvm-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> 
> > 
>