Sorry about the horrible formatting. I don't know how to turn off the html stuff (\<PRE\>\</PRE\> don't seem to work). <br<br>
> While > we're on the subject, some stuff I could use some > assistance with understanding:<br><br>As I've > begun more testing, I'm getting damned confused > about which instructions are allowed for which flags > (DIS_SPARC_V8/DIS_SPARC_V9/DIS_SPARC_V9_SGI). <br><br> Note that SGI should have been converted to VIS. (SGI was the code name for VIS many moons ago). <br<br> And since there are so many extentions subsequent to VIS, it might simplify things to call it V9 extended. <br<br> > <br>I've been using the Sparc V8 manual from (<a > href="http://www.sparc.com/standards/V8.pdf";>http://ww > w.sparc.com/standards/V8.pdf</a>) as well as <a > href="http://opensparc-t1.sunsource.net/specs/UA2005-c > urrent-draft-P-EXT.pdf"> > http://opensparc-t1.sunsource.net/specs/UA2005-current > -draft-P-EXT.pdf</a> <br>for my reference.<br><br>- I > assumed (perhaps incorrectly) that (for example) if > DIS_SPARC_V8 is set in the call to dis_disassemble, > that it implies that any non-v8 instructions would > come back as invalid. In other words, if it > doesn't show up in the V8 manual, return > -1. <br<br> I'm not sure what the intent is. One possibility is that there are some opcodes that were changed going from V8 to V9, and so in V8 mode they could be disassembled differently. <br<br> I would think you always want to disassemble any recognizable instruction, but perhaps note if it was unexpected. <br<br> > But then, I tested against /usr/bin/apm > (b63). It contains a large number of branch > instructions with prediction. However, those do > not appear (from the information I can find) to be > valid V8 instructions. <br<br> This is not surprising, as the default for the Sun Studio compilers is -xarch=v8plus. That means it's OK to use the V9 instructions that will work within the 32-bit ABI. <br<br> You can use "file" or look in the ELF file to see what kinds of instructions to expect. The ELF header has an e_flags field that describes what kind of code is within. Newer binaries might also have a .HW_cap section that specifies what extensions were used. <br<br> > <br><br>So, is my understanding of the meaning of the > disassembler flags correct? If not, can someone > clarify this for me.<br>Does anyone have any better > references than what I've found to help me > understand which instructions are valid for which > disassembler flags? <br<br> I might be able to dig up some old discussions about the interfaces. But that would be work... <br<br> > <br><br>More minor stuff, but thought I mention:<br>- > The closed version seems to not use the proper > floating point registers > in all cases. Specifically, it apparently never > uses the > double-precision (%d0 - %d4, etc.) or quad-precision > (%q0 , %q4, etc) > names, even when the instruction is explicitly > dealing with double or > quad precision floats. My preference is to use > the names that best > make sense with the instruction.<br> <br<br> That seems fine to me. I don't know why the assembler accepts the abiguity. <br<br> > <br>- Certain floating point instructions (for > example fcmp) do not output the %fcc0 when that is > appropriate (ex: 0x81898a4e). Unless there is a > strong objection otherwise, I would prefer to have it > print out (otherwise I'll need to write in > support explicitly for it). <br<br> This is a case where V8 and V9 differ. In V8, there was only a single implied %fcc register. In V9, there were 3 more added, and so specifying the name became important. Thus you might want to disassemble differently for the two cases. I would tend to think one of those flags would control whether abbreviations/synthetic instructions are used. <br<br> Peter. This message posted from opensolaris.org _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
