From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ad47c3851d906864 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.232.42 with SMTP id tl10mr11965881pbc.7.1335620604354; Sat, 28 Apr 2012 06:43:24 -0700 (PDT) Path: r9ni108352pbh.0!nntp.google.com!news2.google.com!news4.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!194.134.4.91.MISMATCH!news2.euro.net!news.mixmin.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Ada on Nintendo DS ? Date: Sat, 28 Apr 2012 13:43:18 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <82zk9wcohf.fsf@stephe-leake.org> Mime-Version: 1.0 Injection-Date: Sat, 28 Apr 2012 13:43:18 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="2424"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19bWqcVPQ4lOJJUmazCASCN" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:afTLKr8JxWSSiljAOCW7L9rZtpY= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2012-04-28T13:43:18+00:00 List-Id: On 2012-04-28, Stephen Leake wrote: > Natasha Kerensikova writes: >> As far as I can tell, devkitARM is a toolchain derived from GCC that >> targets my hardware (it seems there is also some libraries to deal with >> DSPs and stuff, but I can care about this later on). > > It should be straight-forward to include Ada in that toolchain. The hard > part will be the Ada runtime library; it assumes some operating system, > similar to POSIX. It is possible to use no runtime, but then you lose > some features of Ada (exceptions, fixed point, tasking, new/free, etc). Well, that's encouraging for a start :-) Is there some "official" list of what does not have to be supported on an RTL-less system? The C Standard has the notion of "freestanding" and "hosted" environments, which basically means without or with libc (which is quite weaker than POSIX); is there something similar in Ada RM? Or is it up to the compiler provider to decide what belong to RTL and what is code generated on bare metal? For example I'm a bit surprised to see fixed point in the list, when I would have naively thought appropriate inline code generation would be enough (exactly like when I did fixed point "by hand" in 386 assembly). > Is there an OS on the Nintendo? I would have to double check, but as far as I remember no. There is only a bootloader that transfers binary code from cartridge storage to memory and jump to it, and that's it. An even more fuzzy memory of mine says Nintendo sells a SDK that comes with most of what you would expect from an OS, but that's not exactly within hobbyist financial reach. On the other hand, devkitARM comes with a libnds that might take care of a reasonable amount of stuff. >> On the other end, gnatdroid seems to successfully translate Ada code >> into binary that can be fed to ARM CPUs. > > gnatdroid is intended for Android, a specific operating system. It might > be useful as an example. That's all I expected from it, really. My reasoning was that devkitARM is an example of C --(1)--> GCC internals --(2)--> Nintendo DS while gnatdroid is an example of Ada --(3)--> GCC internals --(4)--> native Android What I need is just arrows (2) and (3), and I chose gnatdroid for the argument to lower the risk of stumbling on platform-related variation in "GCC internals" part. Both are ARM code, and that's the closed target I have found. >> Would anyone have an estimation or a bound on how difficult it can be? > Definitely set a goal of a runtimeless compiler, and see if you can make > that work. Then think about what parts of the Ada runtime you really > need. That was most definitely my plan. First make RTL-less Ada run (which might not be that easy considering "proving" something runs involves an output, that require going through DSPs or direct access to LCD or speakers), then bind divkitARM's libnds, and then the parts of libada I miss, then celebration about the projet reaching such an incredibly mature stage, then the rest of libada. > But it also leads to the Dark Side :). (as in, "I know I can do this > simple program in C; I'll put off porting Ada just a little longer"). Well remember I'm coming from a decade of allegiance to the Dark Side, and still find most task to look easier in C (with the notable exception of debugging low-quality code I have not written), and yet I kept being irresistibly attracted to the Bright Sparkling Shiny Blinding Side ;-) Thanks for your help, Natasha