[llvm-dev] Status of AAP (Embecosm's demonstration architecture)?
Tyro Software via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 3 03:15:33 PST 2017
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)
On Thu, Feb 2, 2017 at 12:57 PM, Ed Jones <ed.jones at embecosm.com> wrote:
> 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
> > ( 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
> > subsequent LDB/STB?
> > _______________________________________________
> > 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...
More information about the llvm-dev