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-18 12:13:57 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" 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: Tue, 18 Nov 2003 14:11:08 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:2644 Date: 2003-11-18T14:11:08-06:00 List-Id: "Peter Milliken" wrote in message news:cPuub.611$W07.11450@nnrp1.ozemail.com.au... > In the initial case, I wouldn't be that interested in tasking or floating > point support. I would like exception handling and run-time checking though > :-) > > My current application space is of the order of 8K so my "needs" are fairly > modest from the perspective of Ada features. Whilst I know people have tiny > OS's and "tasking" for spaces this small I can't really imagine why you > would bother :-) A simple round robin scheduler synchronised to a timer > interrupt is more than sufficient for me, throw in some interrupt handling > for the few peripherals of the chip you are using and you have pretty much > used up your 8K anyway :-) Right. Which is why we went to the lengths of keeping the floating point and tasking separate. > My knowledge of compiler technology is approximately nil, I am somewhat > surprised (although I probably shouldn't be :-)) at what you say is required > to go into the runtime libraries as opposed to code generated by the > compiler i.e. exception handling is the only surprise from the list you have > mentioned. Well, we probably have more use of the Janus/Ada runtime libraries than some other compilers do. (We use the heap more extensively, for instance.) But anything that takes more than a handful of instructions ends up in the runtime. Even multiply and divide end up there on processors that don't support those operations in the instruction set. > Is run-time checking generated by a compiler for which you have a code > generator? or is that more runtime work? I guess even if the compiler > generated the runtime checking you need the exception handling to catch it > :-) Although (hopefully), a really simple exception handling mechanism could > be easily achieved (as opposed to a full traceback system - one of the > micros I have just finished using had an 8 deep hardware stack that was > inaccessible from software - no way to perform a traceback :-)). But in the > initial case just catching the exception would be start..... I can't speak for compilers in general (of course), but in Janus/Ada, the checking itself is part of the generated code. If the check fails, then a call is made to the runtime to raise the exception. Obviously, you could live without exception handling, but you'd still need some sort of routine to report the error (send the error string(s) to a debug port, say). The traceback stuff in Janus/Ada doesn't take that much code, but if you're trying to get your program into 8K, you'd probably be better off without it. > Anyway, doesn't look like I can get anything "off the shelf" from gcc 3.X - > perhaps I should start browsing the gnat/gcc 3.X source to get some idea of > where and what needs modifications. Sounds like a plan. Good luck. Randy.