Status of AAP (Embecosm's demonstration architecture)?

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?

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.

Thanks,
Ed

Thanks for the info - and great news that non-octet bytes may soon be in a supported target (a perennial if infrequent question on this list)

/Tyro