LEON Sparc Sub-targets upgrade - first commit

[via llvm-commits]

Hi James, Chris,

First of all, thanks for your help James.

Regarding the sub-target variants: yes, GR740 (we should use GR740 rather
than NGMP, http://microelectronics.esa.int/gr740/) is just a chip
implementing the LEON4FT (similar to what AT697F is to LEON2FT). I think we
should only have three sub-target variants: LEON2, LEON3 and LEON4.

Regarding the sub-target features: Not *everything* needs to be switched
on/off individually. Only things that make sense or can be reused, e.g. UT699
is a LEON3 but does not have support for CASA, GR712RC is a LEON3 which has
CASA. So it would be a good idea if the backend can be configurable in this
aspect.

About the support for AT697E: yes, I agree it is extremely unlikely that any
mission using AT697E today will move from GCC to LLVM, but... you never
know :)

Kind regards,
Jorge




From:	"James Y Knight via llvm-commits" <llvm-commits at lists.llvm.org>
To:	"Chris. Dewhurst" <Chris.Dewhurst at lero.ie>
Cc:	"llvm-commits" <llvm-commits at lists.llvm.org>
Date:	08/09/2015 15:08
Subject:	RE: LEON Sparc Sub-targets upgrade - first commit
Sent by:	"llvm-commits" <llvm-commits-bounces at lists.llvm.org>



Sorry, maybe I misunderstood your earlier messages; I thought *you* had
inherited an existing code base you were giving snippets of and planning to
submit pieces of upstream!


Apologies if that was an incorrect understanding!


On Sep 8, 2015 4:36 AM, "Chris.Dewhurst" <Chris.Dewhurst at lero.ie> wrote:
  Hi,

  Thanks for all that useful information, although the one critical piece of
  information in here is about existing revisions, which I wasn't aware of.
  Moving forward from an existing code-base is almost certainly going to
  result in a higher chance of acceptance into the LLVM source code-base.

  I'm almost frantic in anticipation of finding out where this code is. I'll
  keep looking, but finding this is likely to dramatically alter my direction
  on this project. Any help appreciated.

  On the other notes, I had anticipated that the number of features would be
  viewed somewhat negatively - as I view them that way myself. The ESA
  requirement is that we can switch on and off individual features. However,
  Im fairly sure that getting the code accepted into the LLVM code-base has
  higher priority, so alterations to the design, even potentially to the
  project requirements are anticipated.

  Chris.
        3. LEON's hardware implementation also has very many errata, which we
        need to fix as software optimsations. The intention in the design is
        to implement a back-end pass for each change and add these to the
        LEON target's information about the processor type. e.g. SDIV is not
        working correctly on LEON processors, but SDIVrr works correctly, so
        a back-end pass will modify the instructions to repair this erratum.
        A sample of a LEON processor type definition is as follows, with
        similar variants for LEON3,4 and NGMP:

  Yeah, these AT697 and UT699 processors sure have a whole lot of errata.
  [e.g. http://www.atmel.com/Images/doc4409.pdf is really rather
  astounding!]. Although, I'd note that most of them are already fixed by the
  AT697F and UT699E revisions.

        _______________________________________________
        llvm-commits mailing list
        llvm-commits at lists.llvm.org
        http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits



This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.