[llvm-dev] Status of AAP (Embecosm's demonstration architecture)?
Ed Jones via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 2 03:57:56 PST 2017
We are still working on AAP, and I have been intermittently updating
the patches merging in changes from upstream. The backend in the
submitted patches has all of the basic functionality we need, so there
haven't been many changes to make to it other than fixing bugs and
making changes suggested by reviewers.
The AAP in the patches is quite simple, but our aim is to add
interesting features over time to improve generic LLVM. For example,
at the moment I am experimenting with changing AAP to add support for
non-octet chars (making the smallest addressable unit a 16-bit word).
This won't go in the initial patches but will build on AAP.
As for your architecture question:
The diagram is misleading. We actually only have one 64kB data memory
and one 16MW code memory, and instructions can only access the data
memory. I'll get the diagram fixed.
On 1 February 2017 at 01:07, Tyro Software via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> The initial proposal to include AAP in LLVM met with some concern that it
> would be actively maintained (thread from
> http://lists.llvm.org/pipermail/llvm-dev/2016-August/103807.html ), and
> after some review activity seemingly went quiet (although review code has
> been updated quite recently). Is AAP likely to land any time soon?
> Also an AAP architecture question (possibly the wrong forum, though
> evidently the AAP authors follow this list) - the architecture presentation
> ( http://www.embecosm.com/appnotes/ean13/ean13.pdf ) shows in fig 2.1
> multiple 16-bit-address data memory stores, seemingly with overlapping
> address ranges (0000-FFFF). How is a data store selected, e.g. for use with
> subsequent LDB/STB?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
More information about the llvm-dev