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 11:55:53 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!news1.optus.net.au!optus!snewsf0.syd.ops.aspac.uu.net!nnrp1.ozemail.com.au!53ab2750!not-for-mail From: "Peter Milliken" Newsgroups: comp.lang.ada References: 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? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4927.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Message-ID: Date: Wed, 19 Nov 2003 06:55:52 +1100 NNTP-Posting-Host: 203.15.64.31 X-Trace: nnrp1.ozemail.com.au 1069185352 203.15.64.31 (Wed, 19 Nov 2003 06:55:52 EST) NNTP-Posting-Date: Wed, 19 Nov 2003 06:55:52 EST Xref: archiver1.google.com comp.lang.ada:2642 Date: 2003-11-19T06:55:52+11:00 List-Id: 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 :-) 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. 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..... 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. Thanks for the replies, Peter "Randy Brukardt" wrote in message news:vrih63aerng37f@corp.supernews.com... > "Peter Milliken" wrote in message > news:zgRsb.200$co2.10332@nnrp1.ozemail.com.au... > > 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). > > > > When I say "possible", I just mean "follow the cross-compiling > instructions > > and out pops an Ada compiler" - I don't mean, "spend months of work > patching > > various files and then you might have an Ada compiler" :-) > > To not answer your actual question at all, but... > > As someone else pointed out, the biggest cost/overhead is porting the > runtime libraries. Speaking for Janus/Ada, porting the code > generator/compiler usually only takes a month or so (and that's for building > a code generator from scratch). But building the basic runtime support for > exceptions, tasking, floating point (which usually has to be emulated on > small processors), etc. can take a lot of time. In addition, that support > can make programs quite large. > > Because of this, I think you'd have trouble making acceptable programs with > a general-purpose compiler like GCC. > > Janus/Ada was originally built for Z-80 and 8086 processors without much > memory. Thus, we only load floating point and tasking support when they are > used. That isn't very valuable on standard systems like Windows these days, > but it matters a lot on 8-bit systems. > > The only reason that we don't support 8-bit processors is a lack of demand. > Everyone seems to use a different processor, and thus we cannot really > justify the investment building code generators (easy) and runtime libraries > (not as easy) for each one. > > Of course, we're always interested in customization projects, but that won't > help you convince your manager... > > Randy Brukardt > > > > >