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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fd9a8f91bb89a8d2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-11-14 01:53:16 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!62.173.119.178!not-for-mail From: Peter Amey Newsgroups: comp.lang.ada Subject: Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada? Date: Fri, 14 Nov 2003 09:53:09 +0000 Message-ID: References: NNTP-Posting-Host: 62.173.119.178 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1068803595 53229316 62.173.119.178 (16 [69815]) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en In-Reply-To: Xref: archiver1.google.com comp.lang.ada:2484 Date: 2003-11-14T09:53:09+00:00 List-Id: Peter Milliken wrote: > Subject pretty much says it all. > > Now that you can build an Ada compiler using gcc 3.X (well, according to the > build instructions of gcc 3.x :-)), I began to wonder whether it was > possible to build a cross-compiler for an 8-bit target processor. The 8-bit > processor family in question is already supported by gcc (I believe). Peter, Given that there is already a C compiler for your target, one approach might be to _design_ in Ada and then use an Ada->C compiler/translator to convert the design to C for compilation. In practice you can tie the translator and C compiler so tightly together that it looks like an Ada compiler. The biggest problem with this approach in general is the size of the run-time library you need to support all of Ada (esp. tasking, exception handling etc.) and writing such a library for a small processor. We have had some success in avoiding these problems by using SPARK as the design language. This gives several benefits: 1. SPARK is designed to need zero (or at least very little) run-time library support so all the generated C is directly and easily traceable back to some SPARK source statement. 2. Using the SPARK tools you can easily prove the code to be exception free (e.g. no range violations) and this means the translation can be greatly simplified because it does not have to include the run-time checks that a full Ada compiler would place in the code. The SPARK tools can be told how big your C int is, for example, and can ensure there are no overflows in the translated code. 3. You can do a great deal of strong verification on the SPARK "design model" before generating the C and therefore greatly reduce the cost of the testing process. We have submitted a paper to Ada Europe 2004 on this topic. regards Peter ------------------------------------------------------------ Peter Amey Principal Consultant Praxis Critical Systems 20, Manvers St. +44 (0)1225 466991 Bath www.praxis-cs.co.uk BA1 1PX www.sparkada.com ------------------------------------------------------------