llvm dev - Feb 2017 - 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170201/f970fe97/attachment.html>

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

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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

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

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.
>
> Thanks,
> Ed
>
> 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
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170203/35bb4770/attachment.html>