Cross-toolchain for DS [was: Newcomers to

[Natasha Kerensikova <lithiumcat@instinctive.eu>]

Hello,

On 2014-10-10, Luke A  Guest <laguest@archeia.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>>> I'm also trying to build a cross-compiler for Nintendo DS, it's a bit
>>> less smooth but I haven't spent much time on it yet. Is it also doomed?
>>> 
>> 
>> I strongly recommend you follow Luke's link; he's spent quite a bit
>> of effort over the years on this and he's encountered a good range
>> of problems (there was a time when I was following Luke's work
>> closely).
>>
>
> Cheers, I have not touched it for a while. I was going try to maintain a
> GCC tree but I think it's going to easier to maintain patches still. I have
> some tiny patches which allow you to bud a gnat cross compiler with tools
> on the same vein as a c cross compiler. It's not great. It adds a new
> required flag to turn off building of the runtime. I need to rebook at it.
> Once my new site is ready I'll be going back to old projects, this one
> included. 

The problem here is that I'm trying to mix several projects, and it's
really difficult to make a "Frankenstein's toolchain" without
understanding what is going on, especially since it seems there are
several ways to do the same thing, and all with different versions and
patchsets.

I really want to start from devkitARM, since they provide a lot of very
useful system libraries for the target, and whatever target
configuration they use is what is needed for the host tools to build the
image.

It is built around gcc 4.8.2 with newlib. As a first step, I would be
happy with an Ada front-end without RTS, based only on a C-exported main
and C-imported system primitives. To reach this point, it seems the
required patchset is quite light.

Luke, would you mind explaining your gcc-4.6.1.diff and your choice of
configure flags? That would be extremely helpful to backport it into
devkitARM.

Then I will consider how to deal with the RTS and what features can be
realistically provided.

>> It's experiences like that which make we wonder if we need some kind
>> of new half-way language between C and Ada which is easy to bring up
>> on a new target and while not been as type-safe as Ada would be much
>> better than C.
>
> It's this kind of thing that makes me consider developing a new language
> derived from Asa bit simplified and just made easier to build.

Would anyone know whether an LLVM-based compiler would help on that
particular front?

On the one hand, having such a well-defined intermediate form should
result in a very loose coupling between back-end and front-end, making
all languages roughly equal.

On the other hand, how wide is the availability of LLVM-to-embedded-target
back-end? It's not much of a progress if C and Ada are equal at
"limited to desktop targets" point.


The reason why I'm asking, is I'm stilling working on updating gela and
building on it a RTS-limited LLVM-based Ada 95 compiler seems realistic
(albeit far away down the road).


Natasha