On Jul 31, 2008, at 9:57 AM, Dale Johannesen wrote:> > On Jul 31, 2008, at 4:52 AMPDT, Richard Pennington wrote: > >> Any code that I generate for the Sparc fails at assembly time using a >> gas assembler built for the Sparc. >> >> I get code like the following from the code generator: >> >> save -96, %o6, %o6 >> >> and get a syntax error on the save instruction. >> >> I think sparc syntax should be: >> >> main: >> save %o6, -96, %o6 >> >> Is that correct? Should I file a bug report? > > save %o6, -96, %o6 > > is the usual syntax for Sparc assemblers. But this instruction is so > fundamental nothing could ever have worked if it's broken, so there > may be something deeper going on.This is probably a difference between the sun and GNU assemblers. There is no current sparc maintainer, so feel free to change it if one way works better for you. -Chris
Chris Lattner wrote:> This is probably a difference between the sun and GNU assemblers. > There is no current sparc maintainer, so feel free to change it if one > way works better for you.Hi Chris, Here's the fix: Index: SparcRegisterInfo.cpp ==================================================================--- SparcRegisterInfo.cpp (revision 700) +++ SparcRegisterInfo.cpp (working copy) @@ -137,7 +137,7 @@ if (NumBytes >= -4096) { BuildMI(MBB, MBB.begin(), TII.get(SP::SAVEri), - SP::O6).addImm(NumBytes).addReg(SP::O6); + SP::O6).addReg(SP::O6).addImm(NumBytes); } else { MachineBasicBlock::iterator InsertPt = MBB.begin(); // Emit this the hard way. This clobbers G1 which we always know is Should I file a bug report? -Rich
OK, so the next thing I found in Sparc world is that sparc-elf-as
doesn't understand .bss as a directive for some reason.
I modified the Sparc code generator to output .section ".bss" and that
works just fine. My (temporary) solution is a hack, however:
=================================================================---
SparcAsmPrinter.cpp (revision 720)
+++ SparcAsmPrinter.cpp (working copy)
@@ -263,7 +263,7 @@
// FALL THROUGH
case GlobalValue::InternalLinkage:
if (C->isNullValue())
- SwitchToDataSection(".bss", I);
+ SwitchToDataSection("\t.section\t\".bss\"", I);
else
SwitchToDataSection(".data", I);
break;
My question is: What is the "right" way to do this? I looked at the
Mips
code generator a little bit and it feels a little more modern. Is that
correct?
Which code generator(s) are the best to look at for a template to do
asm/ELF output?
I've started work on a Nios2 code generator, which I originally based on
Mips because its architecture is similar. Is there a better starting point?
Thanks for any suggestions.
-Rich
On 01/08/2008, at 3:18 AM, Chris Lattner wrote:> > On Jul 31, 2008, at 9:57 AM, Dale Johannesen wrote: > >> >> On Jul 31, 2008, at 4:52 AMPDT, Richard Pennington wrote: >> >>> Any code that I generate for the Sparc fails at assembly time >>> using a >>> gas assembler built for the Sparc. >>> >>> I get code like the following from the code generator: >>> >>> save -96, %o6, %o6 >>> >>> and get a syntax error on the save instruction. >>> >>> I think sparc syntax should be: >>> >>> main: >>> save %o6, -96, %o6 >>> >>> Is that correct? Should I file a bug report? >> >> save %o6, -96, %o6 >> >> is the usual syntax for Sparc assemblers. But this instruction is so >> fundamental nothing could ever have worked if it's broken, so there >> may be something deeper going on. > > This is probably a difference between the sun and GNU assemblers. > There is no current sparc maintainer, so feel free to change it if one > way works better for you.Pretty much yes, Sun as will accept either form (with the same meaning), but GNU gas will only accept 'save %o6, -96, %o6'. Cheers, Nathan
On Jul 31, 2008, at 4:47 PM, Richard Pennington wrote:> Chris Lattner wrote: >> This is probably a difference between the sun and GNU assemblers. >> There is no current sparc maintainer, so feel free to change it if >> one >> way works better for you. > > Hi Chris, > > Here's the fix:After refreshing my memory on how the sparc backend works, it turns out that this was a serious bug and that your patch is absolutely the right fix. The .td description was expecting the operands in the order the assembler was expecting, and we happened to get lucky that nothing downstream looked at the .td operand info. Thanks Richard, I applied your patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080728/065608.html -Chris