LEON Sparc Sub-targets upgrade - first commit

[Chris.Dewhurst via llvm-commits]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150908/1197f80a/attachment.html>