The ISA & encoding is documented in the comments and diagrams of lib/Target/Lanai/LanaiInstrFormats.td. If that makes sense I'll add a link to this tablegen in docs/CompilerWriterInfo.rst. Thanks, Jacques On Tue, Feb 9, 2016 at 2:12 PM, Sean Silva <chisophugis at gmail.com> wrote:> Do you have a psABI document? Or an ISA reference? Or an encoding > reference? > > I know at least the encoding reference is missing for AArch64, so it's not > a huge deal, but anything we can put in http://llvm.org/docs/ > CompilerWriterInfo.html (docs/CompilerWriterInfo.rst) would be > appreciated. > > -- Sean Silva > > On Tue, Feb 9, 2016 at 9:40 AM, Jacques Pienaar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> We would like to contribute a new backend for the Lanai processor >> (derived from the processor described in [1]). >> >> Lanai is a simple in-order 32-bit processor with: >> * 32 32-bit registers, including: >> * 2 registers with fixed values; >> * 4 used for program state tracking (PC, SP, FP, RCA); >> * 2 reserved for explicit usage by user (R10 and R11), used in >> threading library; >> * Up to 4 used for argument passing; >> * No callee-saved registers >> * No floating point support >> >> Backend development is focused primarily on compiling C99 code (no >> exception support). The patches implement all the parts required for code >> generation: >> >> * LLVM triple: http://reviews.llvm.org/D17003 >> * Clang support: http://reviews.llvm.org/D17002 >> * MCExpr & ELF: http://reviews.llvm.org/D17008 >> * Lanai backend (lib/Target/Lanai): http://reviews.llvm.org/D17011 >> >> We are still actively developing the backend and have many optimizations >> in mind. >> >> I'll be the maintainer of this backend. >> >> Please leave code comments on the Phab patches, while discussing >> high-level comments about the backend on this llvm-dev thread. >> >> Thanks, >> >> Jacques >> >> [1] David E. Culler, Anoop Gupta, and Jaswinder Pal Singh. 1997. Parallel >> Computer Architecture: A Hardware/Software Approach (1st ed.). Morgan >> Kaufmann Publishers Inc., San Francisco, CA, USA. >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/45164364/attachment.html>
On Wed, Feb 10, 2016 at 5:39 AM, Jacques Pienaar via llvm-dev <llvm-dev at lists.llvm.org> wrote:> The ISA & encoding is documented in the comments and diagrams of > lib/Target/Lanai/LanaiInstrFormats.td. If that makes sense I'll add a link > to this tablegen in docs/CompilerWriterInfo.rst.Some driveby comments - If the processor isn't encumbered and by this I mean any company could in theory make a "Lanai compatible" processor, then I personally would be supportive or middle path. If on the other hand the processor is highly proprietary or encumbered (patents?) then I'd more in the middle or slightly against. I can't always agree with all @google people and or their comments/attitudes, but in general @google has built up quite a bit of positive "karma", at least from my outside perspective. (I suspect others probably see and may feel this way as well) To compare against AMDGPU isn't really fair. AMDGPU may have "limited use" as pointed out, but the niche community that does in fact use it and care about it has high impact. The hardware is also publicly available. /* In theory nothing gets in the way of AMD GPU's gaining greater market adoption - I blame marketing more than technology since they are strong on the current gen consoles */
On Tue, Feb 9, 2016 at 2:39 PM, Jacques Pienaar <jpienaar at google.com> wrote:> The ISA & encoding is documented in the comments and diagrams of > lib/Target/Lanai/LanaiInstrFormats.td. If that makes sense I'll add a > link to this tablegen in docs/CompilerWriterInfo.rst. >Generally CompilerWriterInfo is reserved for "official" documents from hardware vendors. One of the main uses of CompilerWriterInfo is to have authoritative specs that can be used to make decisions about whether our backends are correct or not, so it is somewhat tautological to link to our backends :) -- Sean Silva> > Thanks, > > Jacques > > On Tue, Feb 9, 2016 at 2:12 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> Do you have a psABI document? Or an ISA reference? Or an encoding >> reference? >> >> I know at least the encoding reference is missing for AArch64, so it's >> not a huge deal, but anything we can put in >> http://llvm.org/docs/CompilerWriterInfo.html >> (docs/CompilerWriterInfo.rst) would be appreciated. >> >> -- Sean Silva >> >> On Tue, Feb 9, 2016 at 9:40 AM, Jacques Pienaar via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi all, >>> >>> We would like to contribute a new backend for the Lanai processor >>> (derived from the processor described in [1]). >>> >>> Lanai is a simple in-order 32-bit processor with: >>> * 32 32-bit registers, including: >>> * 2 registers with fixed values; >>> * 4 used for program state tracking (PC, SP, FP, RCA); >>> * 2 reserved for explicit usage by user (R10 and R11), used in >>> threading library; >>> * Up to 4 used for argument passing; >>> * No callee-saved registers >>> * No floating point support >>> >>> Backend development is focused primarily on compiling C99 code (no >>> exception support). The patches implement all the parts required for code >>> generation: >>> >>> * LLVM triple: http://reviews.llvm.org/D17003 >>> * Clang support: http://reviews.llvm.org/D17002 >>> * MCExpr & ELF: http://reviews.llvm.org/D17008 >>> * Lanai backend (lib/Target/Lanai): http://reviews.llvm.org/D17011 >>> >>> We are still actively developing the backend and have many optimizations >>> in mind. >>> >>> I'll be the maintainer of this backend. >>> >>> Please leave code comments on the Phab patches, while discussing >>> high-level comments about the backend on this llvm-dev thread. >>> >>> Thanks, >>> >>> Jacques >>> >>> [1] David E. Culler, Anoop Gupta, and Jaswinder Pal Singh. 1997. >>> Parallel Computer Architecture: A Hardware/Software Approach (1st ed.). >>> Morgan Kaufmann Publishers Inc., San Francisco, CA, USA. >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160209/c3f6e734/attachment.html>
----- Original Message -----> From: "C Bergström via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Jacques Pienaar" <jpienaar at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, February 9, 2016 4:53:14 PM > Subject: Re: [llvm-dev] [RFC] Lanai backend > > On Wed, Feb 10, 2016 at 5:39 AM, Jacques Pienaar via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > The ISA & encoding is documented in the comments and diagrams of > > lib/Target/Lanai/LanaiInstrFormats.td. If that makes sense I'll add > > a link > > to this tablegen in docs/CompilerWriterInfo.rst. > > Some driveby comments - > > If the processor isn't encumbered and by this I mean any company > could > in theory make a "Lanai compatible" processor, then I personally > would > be supportive or middle path. If on the other hand the processor is > highly proprietary or encumbered (patents?) then I'd more in the > middle or slightly against.This is an important point. Whether or not the ISA is encumbered in the sense you mentioned does not affect my view on whether it should be accepted upstream or not, however, given the potential for such a backend to serve educational purposes, I think it is important that Google make the relevant legal status of the ISA clear. -Hal> > I can't always agree with all @google people and or their > comments/attitudes, but in general @google has built up quite a bit > of > positive "karma", at least from my outside perspective. (I suspect > others probably see and may feel this way as well) > > To compare against AMDGPU isn't really fair. AMDGPU may have "limited > use" as pointed out, but the niche community that does in fact use it > and care about it has high impact. The hardware is also publicly > available. /* In theory nothing gets in the way of AMD GPU's gaining > greater market adoption - I blame marketing more than technology > since > they are strong on the current gen consoles */ > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory