Initial SPARC compilation test
doug.simon at oracle.com
Sat May 25 14:07:14 PDT 2013
On May 25, 2013, at 3:57 PM, Morris Meyer <morris.meyer at oracle.com> wrote:
> Christian suggested that we use Fmt superclasses to contain the various SPARC instruction modes. I think his preference would be to generate the assembler w annotations but this is as far as we pushed it.
As part of the Maxine project, we had a system for generating assemblers (with which we generated assemblers for SPARC and x64). This system also allowed for easy construction of disassemblers. There might something there worth leveraging if we want to pursue the generated assembler idea further. I know Christian is already aware of this work - I'm just bringing it up in case others aren't.
> I started w static methods like the PTX and AMD64 assemblers but this pattern is sort of growing on me as makes asserting things easier.
The assertions I see in SPARCAssembler could just as easily be placed in helper methods as opposed to super class constructors right?
> The warning is handled in the lir.sparc package with a JDT prefs change.
Unfortunately this doesn't help anyone using mx to create the Eclipse project configurations. The next time anyone runs 'mx eclipseinit' (which most of us do after a pull when we new projects added), your changes to graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs will be overwritten.
For now, could you please add @SuppressWarnings("unused") where necessary and hg delete graal/com.oracle.graal.lir.sparc/.settings/org.eclipse.jdt.core.prefs. At the same time, we should consider whether to disable the unusedObjectAllocation check globally. As of now, we use the same Eclipse settings for all projects and I'm not sure this current case is a strong enough reason to deviate from that policy. Especially since it's not yet clear (to me at least) why the pattern of separate
> On May 25, 2013, at 5:54 AM, Doug Simon <doug.simon at oracle.com> wrote:
>> Hi Morris, Christian,
>> Why is the SPARC assembler constructed as a set of classes, one for each instruction as opposed to a single assembler class with a bunch of methods (like AMD64Assembler)? I trust that escape analysis does the right thing so there's no overhead for the object construction but I don't see any real advantages to doing it this way. It's strange to have a constructor with a side effect. And of course, it means we need to suppress the Eclipse warnings somehow.
>> On May 25, 2013, at 5:24 AM, Morris Meyer <morris.meyer at oracle.com> wrote:
>>> I just pushed the initial SPARC compilation test for Graal.
>>> ./mx.sh --vm server unittest BasicSPARCTest
>>> will get you started.
More information about the graal-dev