* Ada and embedded applications @ 2001-06-04 18:59 Chris Campbell 2001-06-04 19:34 ` Marin David Condic ` (4 more replies) 0 siblings, 5 replies; 40+ messages in thread From: Chris Campbell @ 2001-06-04 18:59 UTC (permalink / raw) Hi, On another group a discussion about various languages errupted and it took a while to get anything positive out of it(it's started as the old "my language is best" debate). Now the discussion seems to be focussed on distance from hardware, like C being relatively close to hardware. This is largely irrelevant background. One poster claimed that Ada was not used in some embedded devices because of memory overheads for exception handling. Claiming it was used in embedded devices in industries that had budgets that supported it (e.g. the aerospace industry). Is this correct or is it rubbish? Also does exception handling in Ada really have a large overhead? (This is probably an implementation issue but is their anything in the language that makes exception handling bulky?). I'm curious because one of the projects i'm working on involves writing an OS. It's supposed to be as small as possible and i wouldn't want too many overheads. (Also are exceptions dependant on platform? i.e. the mechanisms for flagging an exception dependant on the OS? If so the GNAT pragma No_Runtime would eliminate this, but i'd have no exceptions to tell me if my code's buggered). Chris Campbell. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 18:59 Ada and embedded applications Chris Campbell @ 2001-06-04 19:34 ` Marin David Condic 2001-06-04 21:12 ` Chris Campbell 2001-06-04 21:02 ` Larry Kilgallen ` (3 subsequent siblings) 4 siblings, 1 reply; 40+ messages in thread From: Marin David Condic @ 2001-06-04 19:34 UTC (permalink / raw) Ada in general allows compilers to be creative about how they handle the implementation of features to be as small and/or efficient as possible. For example, GNAT has a version that restricts some features of the language in order to be able to go to a "No Runtime" result. (Its called GNORT, in case you want to do some searching for info on it.) You lose some features, but can make code that doesn't depend on anything but what you provide. GNAT itself is available for the cost of a download if you don't need support. (Don't know for sure about GNORT.) So I don't think it ought to be a budgetary issue. Many embedded projects are using GCC as their compiler - GNAT isn't any different in how it can be used. As for exceptions - the space/speed is going to vary depending on the compiler. Again, there isn't anything in there that requires megabytes of memory or huge processing overhead, but all compilers are different. I think you'd find that whatever overhead is there that it isn't excessive - or even the biggest ticket item on the list of features. Think about it this way: Real-world embedded applications need to do a variety of failure detection & accommodation things. You have to do checks for math overflows, out of bounds references, out of memory conditions, etc. etc. Ada provides you with exceptions which require some non-zero overhead to deal with. C provides you with *nothing* and hence has no overhead. The problem is that because you still need to check for error conditions, you're going to have to do *something* on your own - thus creating more overhead. It makes C look great for a while ("Look! No overhead!") until you realize you've got all this extra code hanging around doing error processing of some form. Usually, compiler generated stuff is going to end up more efficient in the long run, especially for more mature compilers. Ada is really good for applications that have a high reliability requirement specifically because of all the checking it does (compile and run time) for error conditions. If you think Ada is expensive, get a price quote on failure! :-) With Ada, if you really need to, you can turn off the standard exceptions and if you don't create any of your own, you should impose no additional overhead on your program. C gives you no choice in the matter. You have to be *very careful* when listening to C programmers talk about Ada because usually they base their criticisms on a variety of rumors, FUD, misinformation, etc., or a BAD experience with one particular compiler developed 15 years ago. (Like getting a BAD meal in a restaurant - maybe it was just one bad day for an otherwise good restaurant, but it left a bad taste in your mouth and you never go back.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Chris Campbell" <chris.danx@ntlworld.com> wrote in message news:LTQS6.29382$%_1.5022327@news2-win.server.ntlworld.com... > Hi, > > On another group a discussion about various languages errupted and it took a > while to get anything positive out of it(it's started as the old "my language is > best" debate). Now the discussion seems to be focussed on distance from > hardware, like C being relatively close to hardware. This is largely irrelevant > background. > > One poster claimed that Ada was not used in some embedded devices because of > memory overheads for exception handling. Claiming it was used in embedded > devices in industries that had budgets that supported it (e.g. the aerospace > industry). > > > Is this correct or is it rubbish? Also does exception handling in Ada really > have a large overhead? (This is probably an implementation issue but is their > anything in the language that makes exception handling bulky?). > > I'm curious because one of the projects i'm working on involves writing an OS. > It's supposed to be as small as possible and i wouldn't want too many overheads. > (Also are exceptions dependant on platform? i.e. the mechanisms for flagging an > exception dependant on the OS? If so the GNAT pragma No_Runtime would eliminate > this, but i'd have no exceptions to tell me if my code's buggered). > > > > > Chris Campbell. > > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 19:34 ` Marin David Condic @ 2001-06-04 21:12 ` Chris Campbell 2001-06-04 21:33 ` Matthew Woodcraft ` (4 more replies) 0 siblings, 5 replies; 40+ messages in thread From: Chris Campbell @ 2001-06-04 21:12 UTC (permalink / raw) > Ada in general allows compilers to be creative about how they handle the > implementation of features to be as small and/or efficient as possible. For > example, GNAT has a version that restricts some features of the language in > order to be able to go to a "No Runtime" result. (Its called GNORT, in case > you want to do some searching for info on it.) You lose some features, but > can make code that doesn't depend on anything but what you provide. GNAT > itself is available for the cost of a download if you don't need support. > (Don't know for sure about GNORT.) So I don't think it ought to be a > budgetary issue. Many embedded projects are using GCC as their compiler - > GNAT isn't any different in how it can be used. GNORT has been discontinued by ACT. Maybe they integrated it into GNAT. > As for exceptions - the space/speed is going to vary depending on the > compiler. Again, there isn't anything in there that requires megabytes of > memory or huge processing overhead, but all compilers are different. I think > you'd find that whatever overhead is there that it isn't excessive - or even > the biggest ticket item on the list of features. I suppose if i could keep exceptions in it'd be good since i'd know where the OS crashed. Still it I can't since GNAT must use some DOS or windows calls to display the point where the exception occured. This is really annoying me now. I didn't even consider exceptions when i settled on Ada for this project but now i can see they could be benefitial -- In Ada exceptions are always there letting you know when something goes barmy. > With Ada, if you really need to, you can turn off the standard exceptions > and if you don't create any of your own, you should impose no additional > overhead on your program. C gives you no choice in the matter. You have to > be *very careful* when listening to C programmers talk about Ada because > usually they base their criticisms on a variety of rumors, FUD, > misinformation, etc., or a BAD experience with one particular compiler > developed 15 years ago. (Like getting a BAD meal in a restaurant - maybe it > was just one bad day for an otherwise good restaurant, but it left a bad > taste in your mouth and you never go back.) That's why i was curious and decided to find out why. I also wanted to put the guy right if need be. I still can't do that because I still don't know if Ada is less favoured when budgets are tight. It doesn't seem to me, from what's been said in this thread so far that exceptions take up that much extra memory and it shouldn't really matter(but then i've never programmed an embedded device before). If i were a program developer for a life support machine i'd rather use Ada than C. If the worst happened and someone died unneccessarily due to a bug, you'd stand a better chance of finding it with Ada. The other reason he gave i tend to agree with: it can be slow to develop compilers for new processors, but in some ways it can take a while to get a C compiler for the new processor, Ada however is much more complex than C and will take more time starting from scratch. Out of interest GNAT is based upon GCC i think and GCC compiles things to an intermediate form -- a RTL -- (is this right?) so all you'd really need to do is port specific parts of GNAT to the OS if any on the new processor and have a GCC backend that compiles to that processor. It seems like it really wouldn't take that long after you've got this. Is my understanding of this all barmy? Chris Campbell ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:12 ` Chris Campbell @ 2001-06-04 21:33 ` Matthew Woodcraft 2001-06-04 21:33 ` Ted Dennison ` (3 subsequent siblings) 4 siblings, 0 replies; 40+ messages in thread From: Matthew Woodcraft @ 2001-06-04 21:33 UTC (permalink / raw) "Chris Campbell" <chris.danx@ntlworld.com> writes: > Out of interest GNAT is based upon GCC i think and GCC compiles things > to an intermediate form -- a RTL -- (is this right?) Not quite - RTL is processor-specific. There is a processor-independent intermediate form, but it comes earlier in the compilation process than RTL. > so all you'd really need to do is port specific parts of GNAT to the > OS if any on the new processor and have a GCC backend that compiles to > that processor. It seems like it really wouldn't take that long after > you've got this. Is my understanding of this all barmy? That's more-or-less right. Creating a GCC back end for a new processor is a decent-sized job, but in most cases one will already exist, and the 'only' effort would be making it work with GNAT. That's very little effort compared with writing an Ada compiler from scratch, for sure, but nonetheless I guess it's tricky to do correctly. -M- ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:12 ` Chris Campbell 2001-06-04 21:33 ` Matthew Woodcraft @ 2001-06-04 21:33 ` Ted Dennison 2001-06-04 22:33 ` Chris Campbell 2001-06-04 22:09 ` Marin David Condic ` (2 subsequent siblings) 4 siblings, 1 reply; 40+ messages in thread From: Ted Dennison @ 2001-06-04 21:33 UTC (permalink / raw) In article <XPSS6.23515$HL5.2779772@news6-win.server.ntlworld.com>, Chris Campbell says... > >I suppose if i could keep exceptions in it'd be good since i'd know where the OS >crashed. Still it I can't since GNAT must use some DOS or windows calls to >display the point where the exception occured. This is really annoying me now. >I didn't even consider exceptions when i settled on Ada for this project but now >i can see they could be benefitial -- In Ada exceptions are always there letting >you know when something goes barmy. Given that goal, I'd be tempted to try make a special compiler version just for the kernel that does a BCOD (blue-screen-of-death) message. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:33 ` Ted Dennison @ 2001-06-04 22:33 ` Chris Campbell 2001-06-05 7:55 ` Chris Campbell 0 siblings, 1 reply; 40+ messages in thread From: Chris Campbell @ 2001-06-04 22:33 UTC (permalink / raw) > >I suppose if i could keep exceptions in it'd be good since i'd know where the OS > >crashed. Still it I can't since GNAT must use some DOS or windows calls to > >display the point where the exception occured. This is really annoying me now. > >I didn't even consider exceptions when i settled on Ada for this project but now > >i can see they could be benefitial -- In Ada exceptions are always there letting > >you know when something goes barmy. > > Given that goal, I'd be tempted to try make a special compiler version just for > the kernel that does a BCOD (blue-screen-of-death) message. I like that idea! I want the OS to be as good as possible in all respects, this means that if there is an exception i wan't to know it's details so i can track down the bug. How would i start with that(making the special)? Getting the sources is first, what then? Chris Campbell p.s. i wan't be sure were talking about the same thing. Are you suggesting i should make a special version of GNAT that i can code the kernel in? (this is what i've assumed above). Or are you suggesting i port GNAT to the OS once the kernel is coded? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 22:33 ` Chris Campbell @ 2001-06-05 7:55 ` Chris Campbell 2001-06-05 15:03 ` Ted Dennison 0 siblings, 1 reply; 40+ messages in thread From: Chris Campbell @ 2001-06-05 7:55 UTC (permalink / raw) > I like that idea! I want the OS to be as good as possible in all respects, this > means that if there is an exception i wan't to know it's details so i can track > down the bug. > > > How would i start with that(making the special)? Getting the sources is first, > what then? > > Chris Campbell > > p.s. i wan't be sure were talking about the same thing. Are you suggesting i > should make a special version of GNAT that i can code the kernel in? (this is > what i've assumed above). Or are you suggesting i port GNAT to the OS once the > kernel is coded? Sorry I was half asleep when i wrote that. The idea of creating a version just for the kernel is a good idea Ted. I'm gonna get the source for GNAT (i think it's available) and make a start. My first problem will be to get rid of the system dependant code, and maybe replace it if possible. One thing concerns me, consider tasks for example. I can't implement tasks in the compiler due to the nature of the work i'll be doing. Tasks are highly dependant on the native OS so i'll reprogram bits, but to do what? Is there something that a compiler should do when a language feature isn't supported? Also which distribution of GNAT should i get for this? I think the DOS distribution since it's probably very close to what i need (tasking doesn't really become an issue since it doesn't work yet, or that's what i remember seeing somewhere). I think i'll need to get DJGPP to compile the whole thing, hmm ... nope got that already. Chris Campbell ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 7:55 ` Chris Campbell @ 2001-06-05 15:03 ` Ted Dennison 0 siblings, 0 replies; 40+ messages in thread From: Ted Dennison @ 2001-06-05 15:03 UTC (permalink / raw) In article <cf0T6.122$YB3.72776@news2-win.server.ntlworld.com>, Chris Campbell says... > >it if possible. One thing concerns me, consider tasks for example. I can't >implement tasks in the compiler due to the nature of the work i'll be doing. >Tasks are highly dependant on the native OS so i'll reprogram bits, but to do >what? Is there something that a compiler should do when a language feature >isn't supported? For building a microkernel, I'd imagine you'd want to create a "no tasking" program. I believe Gnat has custom pragmas to enforce that. >Also which distribution of GNAT should i get for this? I think the DOS There appears to be only one source distribution for Gnat, so the answer to this is trivial. The tougher question is what target you should configure it for when you build the compiler. I'd guess that the best way to start would probably be a Windows to bare x86 cross-compiler. I haven't looked at the source distribution myself, so I don't know how much work that would be. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:12 ` Chris Campbell 2001-06-04 21:33 ` Matthew Woodcraft 2001-06-04 21:33 ` Ted Dennison @ 2001-06-04 22:09 ` Marin David Condic 2001-06-05 2:18 ` tmoran 2001-06-05 7:45 ` Martin Dowie 2001-06-05 10:15 ` Rod Chapman 4 siblings, 1 reply; 40+ messages in thread From: Marin David Condic @ 2001-06-04 22:09 UTC (permalink / raw) I have not followed GNORT with any serious use in mind. I can't speak for where that may or may not be. As for exceptions and DOS: That isn't specifically an Ada thing. I've used Ada compilers that targeted bare hardware and used no RTOS other than what they brought to the table. Typically, we turned off most of the run time error checking because of speed issues - but then we were unusually hard on processor budgets. You *always* have to remember that what GNAT does is *not* the same as saying what Ada does - whatever GNAT does for exception generating & handling is not necessarily going to be what all Ada compilers (or even GNAT) will do on all different platforms. As with any other embedded project, you must spend time up front evaluating compilers and vendors against your requirements. Failure to do so can get real expensive. When you talk about budgets, what precisely do you mean? Processor/Memory budgets or actual project $$$ budgets? There is no particular reason you can't do real-time, embedded work in Ada under the same processor/memory budgets as you would have for C. (Availability of compilers may be an issue for a particular processor...) You have to know your compiler and know what parts of it are going to cost you speed/space & try to understand how to work with it to optimize things best. That is the same issue with any language or compiler. For example - tasks are going to force you to have some kind of runtime library overhead plus space & speed. Usually, you can do something about it by simply not using tasks and having the linker eliminate dead code. Sometimes, you may need to tailor the RTK - but that is all compiler dependent. In the case of C you can't decide to *start* using tasks because they don't exist. You'll have to grow your own if your app needs some kind of multi-threading & I'll bet it gets more cumbersome & inefficient than had you just used Ada. FWIW, I've built realtime systems on incredibly small/slow processors using Ada and had to fight for every CPU cycle. I can't give you scientific evidence because we never tried to do it both in Ada and C, but from my experience, I don't think we'd have had any speed advantage using a C compiler. We had a very good Ada compiler and evaluating the code that came out of it, it was hard to imagine getting code that was better for the structures we were using. (Granted, we were using very few features - not lots of tasking (some) or complex data representations or OOP features or anything like that. Math calculations, if checks, data representations using records and not much else.) If you are talking $$$ to do a project, then it gets a little fuzzier. As well you know, GNAT is available at no cost, but you're on your own for support at that price. So is GCC. You can always buy support - sometimes at high prices - for either compiler. RR Software has an inexpensive Ada compiler, but I don't think they target the embedded market - unless your "embedded system" is really a PC running windows - which is a little like cheating. Aonix had a nice embedded Ada compiler for not too many $$$ for a number of targets. Price compared to C? Depends on what you get. There are C compilers given away with development kits for specific board level products. Aonix I think started at around $700 a bunch of years ago and depending on what you wanted, the $$$ went up. But on a product of any significant size, the cost of the compiler was pretty much below the noise level. Green Hills has a compiler with multiple front-ends that will target a number of processors. Essentially, you get Ada or C (or a few other languages) as a choice for the front end & buy basically the same back end & development tools. The cost has got to be roughly the same. I just don't see the costs as being hugely different or even a major concern since you have options in either case. If you've got some teeny-tiny processor you'll probably find that there is no Ada as a choice for it. That's one reason C is so popular with the embedded world. Most SBCs and smaller processors have a C compiler available. Could you get Ada on them? Maybe. Maybe not. Ada *will* have a problem fitting on a lot of smaller processors because if you want it validated, you've got to find a way to get lots of features out of a chip that may not offer much support for them. (Floating point? Context switching for tasks? Lots of things get to be a problem on small chips.) C, lacking much in the way of features and not exactly having validation as one of its strong points, has an easier time fitting on small chips. No floating point support? No problem. Integer-C only. No tasking support? No problem - there are no tasks. That's where Ada is going to have a hard time. But of course, hardware just keeps getting faster, bigger & cheaper, so maybe one day the 16-bit micro-controllers won't be an issue for anybody. (Want to build an embedded controller for a toaster? No sweat! Here's your PowerPC chip with on-board 128 meg of memory for $0.39 in production quantities of ten.) As for moving compilers to new targets - it depends a lot on the compiler. GCC (and by insinuation, GNAT) have a lot of unsupported back-ends out there that target a lot of wierd machines. I don't imagine they'd get so many if customizing the compiler was a horrendously hard effort - or was only easy if you were dealing with C on the front end. I don't think it would take a whole lot longer to build the back end for a new machine with Ada as the front end than it would for C. There would be some runtime library porting that may get a bit bigger with Ada, but the bulk of the work on *any* compiler is not the parsing of the source language, but the generation of code & optimization. If the compiler is set up to be easily retargeted, I don't think the source language is going to matter much. OTOH, if the compiler is itself highly customized to Ada language features, I could see how it might be a bigger job to retarget. The level of effort is going to be really dependent on the architecture of the compiler, not the language. -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Chris Campbell" <chris.danx@ntlworld.com> wrote in message news:XPSS6.23515$HL5.2779772@news6-win.server.ntlworld.com... > > > Ada in general allows compilers to be creative about how they handle the > > implementation of features to be as small and/or efficient as possible. For > > example, GNAT has a version that restricts some features of the language in > > order to be able to go to a "No Runtime" result. (Its called GNORT, in case > > you want to do some searching for info on it.) You lose some features, but > > can make code that doesn't depend on anything but what you provide. GNAT > > itself is available for the cost of a download if you don't need support. > > (Don't know for sure about GNORT.) So I don't think it ought to be a > > budgetary issue. Many embedded projects are using GCC as their compiler - > > GNAT isn't any different in how it can be used. > > GNORT has been discontinued by ACT. Maybe they integrated it into GNAT. > > > > As for exceptions - the space/speed is going to vary depending on the > > compiler. Again, there isn't anything in there that requires megabytes of > > memory or huge processing overhead, but all compilers are different. I think > > you'd find that whatever overhead is there that it isn't excessive - or even > > the biggest ticket item on the list of features. > > I suppose if i could keep exceptions in it'd be good since i'd know where the OS > crashed. Still it I can't since GNAT must use some DOS or windows calls to > display the point where the exception occured. This is really annoying me now. > I didn't even consider exceptions when i settled on Ada for this project but now > i can see they could be benefitial -- In Ada exceptions are always there letting > you know when something goes barmy. > > > > With Ada, if you really need to, you can turn off the standard exceptions > > and if you don't create any of your own, you should impose no additional > > overhead on your program. C gives you no choice in the matter. You have to > > be *very careful* when listening to C programmers talk about Ada because > > usually they base their criticisms on a variety of rumors, FUD, > > misinformation, etc., or a BAD experience with one particular compiler > > developed 15 years ago. (Like getting a BAD meal in a restaurant - maybe it > > was just one bad day for an otherwise good restaurant, but it left a bad > > taste in your mouth and you never go back.) > > That's why i was curious and decided to find out why. I also wanted to put the > guy right if need be. I still can't do that because I still don't know if Ada > is less favoured when budgets are tight. It doesn't seem to me, from what's > been said in this thread so far that exceptions take up that much extra memory > and it shouldn't really matter(but then i've never programmed an embedded device > before). If i were a program developer for a life support machine i'd rather > use Ada than C. If the worst happened and someone died unneccessarily due to a > bug, you'd stand a better chance of finding it with Ada. > > The other reason he gave i tend to agree with: it can be slow to develop > compilers for new processors, but in some ways it can take a while to get a C > compiler for the new processor, Ada however is much more complex than C and will > take more time starting from scratch. > > Out of interest GNAT is based upon GCC i think and GCC compiles things to an > intermediate form -- a RTL -- (is this right?) so all you'd really need to do is > port specific parts of GNAT to the OS if any on the new processor and have a GCC > backend that compiles to that processor. It seems like it really wouldn't take > that long after you've got this. Is my understanding of this all barmy? > > > > > Chris Campbell > > > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 22:09 ` Marin David Condic @ 2001-06-05 2:18 ` tmoran 2001-06-05 13:38 ` Marin David Condic ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: tmoran @ 2001-06-05 2:18 UTC (permalink / raw) >that may not offer much support for them. (Floating point? Context switching >for tasks? Lots of things get to be a problem on small chips.) C, lacking I used to regularly compile and run Ada 83 programs in 16 bit DOS on a 286, often generating a small memory model (64K) .com file. But I grant that's gigantic compared to 512 bytes of RAM. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 2:18 ` tmoran @ 2001-06-05 13:38 ` Marin David Condic 2001-06-06 4:09 ` Jeffrey Carter 2001-06-05 18:23 ` Randy Brukardt 2001-06-05 18:25 ` Randy Brukardt 2 siblings, 1 reply; 40+ messages in thread From: Marin David Condic @ 2001-06-05 13:38 UTC (permalink / raw) I wouldn't say that it is *impossible* to get an Ada program into 512 bytes of memory, but you'd have to have a compiler that made it possible to build code with no runtime (like GNORT) or you might find yourself dragging along way too much other stuff. Technically speaking, I don't think this is a *language* problem - more one of a *linkage* problem. There may be some language issues such as this: I write a single procedure to run in my 512 bytes of memory. Will Ada demand that there be some kind of elaboration/initialization/finalization that takes place such that I've got to drag along more stuff than I need? Could a compiler be built (and would it be *legal* Ada or a subset?) that was smart enough to detect that my single procedure program required nothing but jumping to the starting address and executing from there? I'd suspect thjat the answer is "Yes, but it may require bending language rules and will certainly require you don't use specific features." Naturally, you couldn't use the whole of the Ada language in a setting like that, which raises issues of validation. It may be possible to target Ada for that sort of microcontroller, but it doesn't seem to be high on anybody's priority list. Possibly it is viewed as a) too difficult to accomplish in a reasonable span of time and b) too little interest on the part of the folks who program these things to make it worth investing the energy in it. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ <tmoran@acm.org> wrote in message news:akXS6.63509$%i7.48165181@news1.rdc1.sfba.home.com... > >that may not offer much support for them. (Floating point? Context switching > >for tasks? Lots of things get to be a problem on small chips.) C, lacking > I used to regularly compile and run Ada 83 programs in 16 bit DOS on > a 286, often generating a small memory model (64K) .com file. But I grant > that's gigantic compared to 512 bytes of RAM. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 13:38 ` Marin David Condic @ 2001-06-06 4:09 ` Jeffrey Carter 0 siblings, 0 replies; 40+ messages in thread From: Jeffrey Carter @ 2001-06-06 4:09 UTC (permalink / raw) Marin David Condic wrote: > > I wouldn't say that it is *impossible* to get an Ada program into 512 bytes > of memory, but you'd have to have a compiler that made it possible to build > code with no runtime (like GNORT) or you might find yourself dragging along > way too much other stuff. Technically speaking, I don't think this is a > *language* problem - more one of a *linkage* problem. There may be some > language issues such as this: I write a single procedure to run in my 512 > bytes of memory. Will Ada demand that there be some kind of > elaboration/initialization/finalization that takes place such that I've got > to drag along more stuff than I need? Could a compiler be built (and would > it be *legal* Ada or a subset?) that was smart enough to detect that my > single procedure program required nothing but jumping to the starting > address and executing from there? I'd suspect thjat the answer is "Yes, but > it may require bending language rules and will certainly require you don't > use specific features." Pragma Preelaborate exists to allow the elimination of elaboration, including initialization. Obviously you can't use controlled types in a pre-elaborable unit, so finalization disappears, too. I would think that if you can get the compiler to accept your procedure with pragma Preelaborate that it would do what you want. -- Jeff Carter "I blow my nose on you." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 2:18 ` tmoran 2001-06-05 13:38 ` Marin David Condic @ 2001-06-05 18:23 ` Randy Brukardt 2001-06-05 18:25 ` Randy Brukardt 2 siblings, 0 replies; 40+ messages in thread From: Randy Brukardt @ 2001-06-05 18:23 UTC (permalink / raw) tmoran@acm.org wrote in message ... >>that may not offer much support for them. (Floating point? Context switching >>for tasks? Lots of things get to be a problem on small chips.) C, lacking > I used to regularly compile and run Ada 83 programs in 16 bit DOS on >a 286, often generating a small memory model (64K) .com file. But I grant >that's gigantic compared to 512 bytes of RAM. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 2:18 ` tmoran 2001-06-05 13:38 ` Marin David Condic 2001-06-05 18:23 ` Randy Brukardt @ 2001-06-05 18:25 ` Randy Brukardt 2001-06-05 20:18 ` Marin David Condic 2 siblings, 1 reply; 40+ messages in thread From: Randy Brukardt @ 2001-06-05 18:25 UTC (permalink / raw) tmoran@acm.org wrote in message ... >>that may not offer much support for them. (Floating point? Context switching >>for tasks? Lots of things get to be a problem on small chips.) C, lacking > I used to regularly compile and run Ada 83 programs in 16 bit DOS on >a 286, often generating a small memory model (64K) .com file. But I grant >that's gigantic compared to 512 bytes of RAM. As I recall, that version could make useful programs that fit in 16K ROM and 2K RAM. The only reason to prefer C is ignorance... Randy. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 18:25 ` Randy Brukardt @ 2001-06-05 20:18 ` Marin David Condic 0 siblings, 0 replies; 40+ messages in thread From: Marin David Condic @ 2001-06-05 20:18 UTC (permalink / raw) ....or availability. C has the advantage over Ada in that you can usually get some version of a C compiler for a lot of small microcontrollers. Ada is around for some 16 bit processors (not necessarily the most popular, either) and most of the more generally used 32 bit processors (M680x0, Mips, PowerPC, 80x86, etc.) I'd say that anyone who prefers C over Ada in a host/target environment where a descent implementation of Ada is available is doing so out of ignorance (Or anti-Ada bigotry). For lots of popular processors you have good Ada implementations & no reason not to gain its advantages over C. For quite a few smaller processors your choices quickly become C or Assembly language and I'd rather use C than Assembly. This may be blasphemy, but I'd be in favor of an Ada subset for small microcontrollers wherein any features too hard to implement or too costly were dropped. I'd want the Ada features that had compile-time implications (rep clauses, static checks, etc.) but would willingly abandon run-time features (floating point, big integers, whatever) in order to have Ada as a choice over C. That's one area where "The Mandate" ended up hurting Ada. If there had been a 100% upward-compatible subset of Ada available for small embedded machines, it might not have received so much resistance and might have seen more "evolving" implementations. In the early days, Ada just bit off more than she could chew & we're still paying that price. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:zt9T6.39$yq2.1735@client... > > As I recall, that version could make useful programs that fit in 16K ROM > and 2K RAM. The only reason to prefer C is ignorance... > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:12 ` Chris Campbell ` (2 preceding siblings ...) 2001-06-04 22:09 ` Marin David Condic @ 2001-06-05 7:45 ` Martin Dowie 2001-06-05 13:49 ` Marin David Condic 2001-06-05 10:15 ` Rod Chapman 4 siblings, 1 reply; 40+ messages in thread From: Martin Dowie @ 2001-06-05 7:45 UTC (permalink / raw) It hasn't been discontinued, it's been renamed to "GNAT Pro High Integrity Edition" - really trips off the tongue! :-) And is the Ravenscar Profile edition will be called GRAVEN? > GNORT has been discontinued by ACT. Maybe they integrated it into GNAT. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 7:45 ` Martin Dowie @ 2001-06-05 13:49 ` Marin David Condic 2001-06-05 20:47 ` Martin Dowie 0 siblings, 1 reply; 40+ messages in thread From: Marin David Condic @ 2001-06-05 13:49 UTC (permalink / raw) I really wish that the whole GNU thing had gone off in another naming direction. We've been stuck for years - and will continue to be stuck for years to come - with a whole slew of awkward names stemming from the "GNU" acronym. One day, comes The Revolution, and I get to run the whole world, we'll name all software/systems after ex-girlfriends or favorite pets, or dead presidents or *anything* that doesn't have to be an awkward acronym. ("Let me demonstrate my new Ada compiler. I call it 'Laura-Muffy-Rosevelt'" :-) But that's just my pet peeve.... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message news:3b1c8b72$1@pull.gecm.com... > It hasn't been discontinued, it's been renamed to > "GNAT Pro High Integrity Edition" - really trips off the tongue! :-) > > And is the Ravenscar Profile edition will be called GRAVEN? > > > GNORT has been discontinued by ACT. Maybe they integrated it into GNAT. > > > ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 13:49 ` Marin David Condic @ 2001-06-05 20:47 ` Martin Dowie 0 siblings, 0 replies; 40+ messages in thread From: Martin Dowie @ 2001-06-05 20:47 UTC (permalink / raw) "Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in message news:9fio0s$2n5$1@nh.pace.co.uk... > One day, comes The Revolution, and I get to run the whole world, we'll name > all software/systems after ex-girlfriends or favorite pets, or dead > presidents or *anything* that doesn't have to be an awkward acronym. ("Let > me demonstrate my new Ada compiler. I call it 'Laura-Muffy-Rosevelt'" :-) I won't ask which is which... :-) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:12 ` Chris Campbell ` (3 preceding siblings ...) 2001-06-05 7:45 ` Martin Dowie @ 2001-06-05 10:15 ` Rod Chapman 4 siblings, 0 replies; 40+ messages in thread From: Rod Chapman @ 2001-06-05 10:15 UTC (permalink / raw) > GNORT has been discontinued by ACT. Maybe they integrated it into GNAT. GNORT has simply changed name - it is now called GNAT Pro High-Integrity Edition, and is fully supported by ACT. I'm sure there must be details on www.gnat.com somewhere... - Rod ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 18:59 Ada and embedded applications Chris Campbell 2001-06-04 19:34 ` Marin David Condic @ 2001-06-04 21:02 ` Larry Kilgallen 2001-06-04 20:06 ` Ehud Lamm 2001-06-04 21:15 ` Robert A Duff ` (2 subsequent siblings) 4 siblings, 1 reply; 40+ messages in thread From: Larry Kilgallen @ 2001-06-04 21:02 UTC (permalink / raw) In article <LTQS6.29382$%_1.5022327@news2-win.server.ntlworld.com>, "Chris Campbell" <chris.danx@ntlworld.com> writes: > Hi, > > On another group a discussion about various languages errupted and it took a > while to get anything positive out of it(it's started as the old "my language is > best" debate). Now the discussion seems to be focussed on distance from > hardware, like C being relatively close to hardware. This is largely irrelevant > background. > > One poster claimed that Ada was not used in some embedded devices because of > memory overheads for exception handling. Claiming it was used in embedded > devices in industries that had budgets that supported it (e.g. the aerospace > industry). Efficiency of exception handling obviously varies among implementations, but I worry about any design that is going to encounter so many exceptions that their performance becomes relevant. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:02 ` Larry Kilgallen @ 2001-06-04 20:06 ` Ehud Lamm 2001-06-04 21:18 ` Ted Dennison 2001-06-05 12:35 ` Marc A. Criley 0 siblings, 2 replies; 40+ messages in thread From: Ehud Lamm @ 2001-06-04 20:06 UTC (permalink / raw) Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote in message > Efficiency of exception handling obviously varies among implementations, > but I worry about any design that is going to encounter so many exceptions > that their performance becomes relevant. Perhaps one should note that there can be implementations in which exception handling support causes overhead even for programs and routines that don't raise or handle exceptions. -- Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== Me! ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 20:06 ` Ehud Lamm @ 2001-06-04 21:18 ` Ted Dennison 2001-06-05 12:35 ` Marc A. Criley 1 sibling, 0 replies; 40+ messages in thread From: Ted Dennison @ 2001-06-04 21:18 UTC (permalink / raw) In article <9fgq5t$hok$1@news.huji.ac.il>, Ehud Lamm says... > >Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote in message >> Efficiency of exception handling obviously varies among implementations, >> but I worry about any design that is going to encounter so many exceptions >> that their performance becomes relevant. > >Perhaps one should note that there can be implementations in which exception >handling support causes overhead even for programs and routines that don't >raise or handle exceptions. If your definition of "overhead" includes the executable's memory footprint, I think all programs would qualify. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 20:06 ` Ehud Lamm 2001-06-04 21:18 ` Ted Dennison @ 2001-06-05 12:35 ` Marc A. Criley 2001-06-05 19:00 ` Pascal Obry 1 sibling, 1 reply; 40+ messages in thread From: Marc A. Criley @ 2001-06-05 12:35 UTC (permalink / raw) Ehud Lamm wrote: > > Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote in message > > Efficiency of exception handling obviously varies among implementations, > > but I worry about any design that is going to encounter so many exceptions > > that their performance becomes relevant. > > Perhaps one should note that there can be implementations in which exception > handling support causes overhead even for programs and routines that don't > raise or handle exceptions. > I know ACT was touting "zero-cost exception" technology for some GNAT platforms a year or so ago, which was intended to alleviate exactly this concern. (Without Dewar being here, nor being a supported customer, I don't get much ACT press info any more :-( Marc A. Criley Senior Staff Engineer Quadrus Corporation www.quadruscorp.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 12:35 ` Marc A. Criley @ 2001-06-05 19:00 ` Pascal Obry 0 siblings, 0 replies; 40+ messages in thread From: Pascal Obry @ 2001-06-05 19:00 UTC (permalink / raw) "Marc A. Criley" <mcqada@earthlink.net> writes: > I know ACT was touting "zero-cost exception" technology for some GNAT > platforms a year or so ago, which was intended to alleviate exactly this > concern. (Without Dewar being here, nor being a supported customer, I > don't get much ACT press info any more :-( Look at the -gnatZ option in gnatmake and in the documentation. I don't have the list of supported platforms for ZCE. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://perso.wanadoo.fr/pascal.obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 18:59 Ada and embedded applications Chris Campbell 2001-06-04 19:34 ` Marin David Condic 2001-06-04 21:02 ` Larry Kilgallen @ 2001-06-04 21:15 ` Robert A Duff 2001-06-04 21:30 ` Chris Campbell 2001-06-05 7:50 ` Martin Dowie 2001-06-06 2:31 ` Ken Garlington 4 siblings, 1 reply; 40+ messages in thread From: Robert A Duff @ 2001-06-04 21:15 UTC (permalink / raw) "Chris Campbell" <chris.danx@ntlworld.com> writes: > One poster claimed that Ada was not used in some embedded devices because of > memory overheads for exception handling. Sounds like nonsense, but it's not completely clear what that poster meant. An exception handler typically costs a small number of words of space for certain tables. Even if those tables were huge (not likely), you don't have to use exception handlers if you don't like. It's silly to use C because when using Ada you might be tempted to use an inefficient feature that C doesn't have at all. I don't think Ada exception handlers have any *distributed* overhead -- that is, you don't pay anything substantial for the mere existence of exception handling in the language, if you don't use it. (Unless you're talking about combining exception handling and finalization -- but C doesn't have finalization, so that can't be the issue.) Perhaps that poster was talking about the space overhead of run-time checking (array bounds and the like). That overhead exists, but it's not all that high, and anyway, pragma Suppress will turn it off. >... Claiming it was used in embedded > devices in industries that had budgets that supported it (e.g. the aerospace > industry). That sounds like nonsense, too. I wouldn't believe it unless some (current) prices were quoted for comparison. - Bob ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:15 ` Robert A Duff @ 2001-06-04 21:30 ` Chris Campbell 2001-06-05 2:06 ` Jeffrey Carter 2001-06-05 14:04 ` Marin David Condic 0 siblings, 2 replies; 40+ messages in thread From: Chris Campbell @ 2001-06-04 21:30 UTC (permalink / raw) "Robert A Duff" <bobduff@world.std.com> wrote in message news:wccsnhg6j6v.fsf@world.std.com... > "Chris Campbell" <chris.danx@ntlworld.com> writes: > > > One poster claimed that Ada was not used in some embedded devices because of > > memory overheads for exception handling. > > Sounds like nonsense, but it's not completely clear what that poster > meant. This is the exact text (and not my regurgutation of it which is vague). -- [ ... ] > This is what I meant with "worship". Of course you're right, it's almost > sure, that there exists a C compiler for that hand-holdable device. > But why there is _only_ a C compiler for it? And not Pascal? Or Ada? > Perhaps even Java could be possible? Pascal (or at least something that looks roughly like Pascal) would be a reasonable possibility if everybody agreed exactly what that "roughly like Pascal" language really ought to be. Ada probably is not reasonable for _most_ such devices. Ada requires exception handling, which takes up quite a bit of memory. In embedded devices, price matters a LOT, and more memory means a higher price. Ada _does_ get used in embedded systems with budgets to support it (e.g. the aerospace industry) but in the lower-end of the market, exception handling makes it unusable (and the same goes for C++). Consider that at work right now, I'm working on some code for a PIC 16C55, which has a total of 512 bytes (no, not Kbytes, but bytes) of program memory available. It might be possible to get an Ada program to run in that, but if so it'll take somebody a LOT smarter than me to do it. In addition, Ada is a large, complex language so porting it to a new processor tends to be a relatively slow, expensive process. If a company has a choice between using C and waiting 6 months for an Ada compiler to get finished, there's often little real choice at all. -- -- Jerry Coffin on alt.os.development in post Re: using C to develop an OS -- Chris Campbell ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:30 ` Chris Campbell @ 2001-06-05 2:06 ` Jeffrey Carter 2001-06-05 14:04 ` Marin David Condic 1 sibling, 0 replies; 40+ messages in thread From: Jeffrey Carter @ 2001-06-05 2:06 UTC (permalink / raw) Chris Campbell wrote [concerning a post about languages for hand-held devices]: > > This is the exact text (and not my regurgutation of it which is vague). > > -- > [ ... ] > Ada probably is not reasonable for _most_ such devices. Ada requires > exception handling, which takes up quite a bit of memory. In > embedded devices, price matters a LOT, and more memory means a higher > price. Ada _does_ get used in embedded systems with budgets to > support it (e.g. the aerospace industry) but in the lower-end of the > market, exception handling makes it unusable (and the same goes for > C++). So, write it in C, with hand-written code for all possible exceptions, and in Ada, with exceptions and exception handlers, and see which one "takes up" more memory. The Ada compiler can optimize a lot of the overhead away, but the C compiler has no choice but to keep it in. Or is it good to save a few bytes but have your app crash every third time you run it? In that case Ada can be just as small as C. -- Jeff Carter "You tiny-brained wipers of other people's bottoms!" Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 21:30 ` Chris Campbell 2001-06-05 2:06 ` Jeffrey Carter @ 2001-06-05 14:04 ` Marin David Condic 1 sibling, 0 replies; 40+ messages in thread From: Marin David Condic @ 2001-06-05 14:04 UTC (permalink / raw) For something this small, you could probably code the app in assembler and not find any good reasons to go to a higher level language. You probably wouldn't get any big advantages using Ada for this sort of target anyway (other than you're working with ther *coolest* language and one where the syntax doesn't drive you crazy. :-) Any program that could be made to run in 512 bytes of memory could be coded in Ada, C or Assembler and be made just about equally reliable with nearly equal effort. Its just too small a system to think you need to worry much about code readability (throw it away and rewrite it) or software reuse (are you going to port the app somewhere else?) or runtime constraint checks or any of the other things where Ada gives you an edge. Something like this you toss to a single programmer and in a few days he hands you back a working program that has been poured over pretty thoroughly to make sure it works right. Where you want to work with Ada is where programs become larger, data representations become more complex, the number of developers is bigger, etc. It would be *nice* if Ada was available for all sorts of microcontrollers and the quality of the compilers made it possible to use Ada for such small memory models. I believe that there is no reason that you couldn't write code using a subset of Ada that would be able to fit in something this small, but it requires some work on the part of the compiler vendor to target that kind of platform. I just don't see anyone devoting much effort to targeting that market. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Chris Campbell" <chris.danx@ntlworld.com> wrote in message news:c5TS6.23613$HL5.2796687@news6-win.server.ntlworld.com... > > Consider that at work right now, I'm working on some code for a PIC > 16C55, which has a total of 512 bytes (no, not Kbytes, but bytes) of > program memory available. It might be possible to get an Ada program > to run in that, but if so it'll take somebody a LOT smarter than me > to do it. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 18:59 Ada and embedded applications Chris Campbell ` (2 preceding siblings ...) 2001-06-04 21:15 ` Robert A Duff @ 2001-06-05 7:50 ` Martin Dowie 2001-06-05 14:24 ` John English 2001-06-06 2:31 ` Ken Garlington 4 siblings, 1 reply; 40+ messages in thread From: Martin Dowie @ 2001-06-05 7:50 UTC (permalink / raw) Chris Campbell <chris.danx@ntlworld.com> wrote in message news:LTQS6.29382$%_1.5022327@news2-win.server.ntlworld.com... > One poster claimed that Ada was not used in some embedded devices because of > memory overheads for exception handling. Claiming it was used in embedded > devices in industries that had budgets that supported it (e.g. the aerospace > industry). Christ, I'd love a budget of any size! :-) I'm using Ada (partly) because it will save us money! > Is this correct or is it rubbish? Also does exception handling in Ada really > have a large overhead? (This is probably an implementation issue but is their > anything in the language that makes exception handling bulky?). A few compilers I've come across offer 'zero cost' exception handling. By this they mean that it will have no affect on %CPU usage if there are no exceptions. The price you pay for that tends to be *slightly* slower exception handling if/ when it does happen. But really, is this guy designing a system that has exceptions happening in a run-of-the-mill fashion? If so, he should forget what language it is written in and go back to the design... ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 7:50 ` Martin Dowie @ 2001-06-05 14:24 ` John English 2001-06-08 23:55 ` Robert A Duff 0 siblings, 1 reply; 40+ messages in thread From: John English @ 2001-06-05 14:24 UTC (permalink / raw) Martin Dowie wrote: > A few compilers I've come across offer 'zero cost' exception handling. By > this > they mean that it will have no affect on %CPU usage if there are no > exceptions. > The price you pay for that tends to be *slightly* slower exception handling > if/ > when it does happen. Hmm, the "obvious" way to handle exceptions involves one extra word in the stack frame (a pointer to the start of the exception handling code) which costs (typically) 4 bytes per handled block and 1 extra word to pop on exit, which may or may not cost nothing, but is certainly pretty cheap. For example, i386 processors have POPA/POPAD (pop all) instructions, 680x0 have MOVEM (move multiple registers) where the cost of an extra register is an extra memory cycle, and Vaxen of fond memory had a word for the exception handler as a standard part of the stack frame created by CALL. Detecting exceptions can be more expensive -- e.g. on a processor that doesn't generate an exception on arithmetic overflow, checking for constraint errors can add quite a bit to the overall code cost. The other complication is controlled types and the sequence of object destruction that block exit can entail. Does anyone have any references to alternative ways of implementing exception handling? ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.comp.it.bton.ac.uk/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-05 14:24 ` John English @ 2001-06-08 23:55 ` Robert A Duff 2001-06-09 12:47 ` Ehud Lamm 2001-06-14 16:27 ` Pat Rogers 0 siblings, 2 replies; 40+ messages in thread From: Robert A Duff @ 2001-06-08 23:55 UTC (permalink / raw) John English <je@brighton.ac.uk> writes: > Hmm, the "obvious" way to handle exceptions involves one extra word > in the stack frame (a pointer to the start of the exception handling > code) which costs (typically) 4 bytes per handled block and 1 extra > word to pop on exit, which may or may not cost nothing, but is certainly > pretty cheap. But the more desirable implementation is to save the small cost of setting that pointer, and spend perhaps 10,000 instructions searching a table of code addresses when an exception is raised. If exceptions being raised are rare, but blocks protected by exception handlers are more common, that's a win. > Does anyone have any references to alternative ways of implementing > exception handling? One variant of the code-table technique was decribed in the Ada 83 rationale. The implementation you described above is essentially equivalent to the VAX/VMS standard method. I don't have other references at hand, but surely a lot of this stuff is common lore, and documented somewhere. - Bob ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-08 23:55 ` Robert A Duff @ 2001-06-09 12:47 ` Ehud Lamm 2001-06-14 16:27 ` Pat Rogers 1 sibling, 0 replies; 40+ messages in thread From: Ehud Lamm @ 2001-06-09 12:47 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> wrote in message > > But the more desirable implementation is to save the small cost of > setting that pointer, and spend perhaps 10,000 instructions searching a > table of code addresses when an exception is raised. If exceptions > being raised are rare, but blocks protected by exception handlers are > more common, that's a win. > Some insight may be gained from looking at system.exceptions and ada.exceptions in the Gnat distribution. -- Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== Me! ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-08 23:55 ` Robert A Duff 2001-06-09 12:47 ` Ehud Lamm @ 2001-06-14 16:27 ` Pat Rogers 1 sibling, 0 replies; 40+ messages in thread From: Pat Rogers @ 2001-06-14 16:27 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1287 bytes --] "Robert A Duff" <bobduff@world.std.com> wrote in message news:wccvgm6bk7b.fsf@world.std.com... > John English <je@brighton.ac.uk> writes: > > > Hmm, the "obvious" way to handle exceptions involves one extra word > > in the stack frame (a pointer to the start of the exception handling > > code) which costs (typically) 4 bytes per handled block and 1 extra > > word to pop on exit, which may or may not cost nothing, but is certainly > > pretty cheap. > > But the more desirable implementation is to save the small cost of > setting that pointer, and spend perhaps 10,000 instructions searching a > table of code addresses when an exception is raised. If exceptions > being raised are rare, but blocks protected by exception handlers are > more common, that's a win. > > > Does anyone have any references to alternative ways of implementing > > exception handling? > > One variant of the code-table technique was decribed in the Ada 83 > rationale. The implementation you described above is essentially > equivalent to the VAX/VMS standard method. I don't have other > references at hand, but surely a lot of this stuff is common lore, and > documented somewhere. T. P. Baker and G. A. Riccardi, �Implementing Ada Exceptions,� IEEE Software, vol. 3, no. 5, pp. 42-51, 1986. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-04 18:59 Ada and embedded applications Chris Campbell ` (3 preceding siblings ...) 2001-06-05 7:50 ` Martin Dowie @ 2001-06-06 2:31 ` Ken Garlington 2001-06-06 11:14 ` Chris Campbell 2001-06-06 15:42 ` Marin David Condic 4 siblings, 2 replies; 40+ messages in thread From: Ken Garlington @ 2001-06-06 2:31 UTC (permalink / raw) "Chris Campbell" <chris.danx@ntlworld.com> wrote in message news:LTQS6.29382$%_1.5022327@news2-win.server.ntlworld.com... : Hi, : : On another group a discussion about various languages errupted and it took a : while to get anything positive out of it(it's started as the old "my language is : best" debate). Now the discussion seems to be focussed on distance from : hardware, like C being relatively close to hardware. This is largely irrelevant : background. : : One poster claimed that Ada was not used in some embedded devices because of : memory overheads for exception handling. Claiming it was used in embedded : devices in industries that had budgets that supported it (e.g. the aerospace : industry). : : Is this correct or is it rubbish? Rubbish. : Also does exception handling in Ada really : have a large overhead? (This is probably an implementation issue but is their : anything in the language that makes exception handling bulky?). Not for most of the embedded Ada code I've written. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-06 2:31 ` Ken Garlington @ 2001-06-06 11:14 ` Chris Campbell 2001-06-06 15:47 ` Marin David Condic 2001-06-06 17:57 ` Jerry van Dijk 2001-06-06 15:42 ` Marin David Condic 1 sibling, 2 replies; 40+ messages in thread From: Chris Campbell @ 2001-06-06 11:14 UTC (permalink / raw) > : One poster claimed that Ada was not used in some embedded devices because > of > : memory overheads for exception handling. Claiming it was used in embedded > : devices in industries that had budgets that supported it (e.g. the > aerospace > : industry). > : > : Is this correct or is it rubbish? > > Rubbish. > : Also does exception handling in Ada really > : have a large overhead? (This is probably an implementation issue but is > their > : anything in the language that makes exception handling bulky?). > > Not for most of the embedded Ada code I've written. Maybe this posters views where based on the fact that the last time he used Ada was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and compiler technology less advanced than it is today). Chris Campbell ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-06 11:14 ` Chris Campbell @ 2001-06-06 15:47 ` Marin David Condic 2001-06-06 17:57 ` Jerry van Dijk 1 sibling, 0 replies; 40+ messages in thread From: Marin David Condic @ 2001-06-06 15:47 UTC (permalink / raw) If that's the case, yeah, he's operating on ancient information. Lots of the early compilers were very bad. This is the classic case of people evaluating a language based on a particular compiler rather than on the basis of the syntax & semantics of the language. Really smart people fall into this trap surprisingly often. In a way, its inevitable because you can't write real-world code using a theoretic compiler. If all the language implementations are bad, its hard not to conclude that the language itself is bad - or that it doesn't matter how "good" it *might* be one day. I'd suggest you recommend he try writing some code in Ada using a more modern compiler & that he learn something about pragma Supress, etc. If you want efficient code, you *must* learn the language thoroughly & understand your compiler. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Chris Campbell" <chris.danx@ntlworld.com> wrote in message news:hfoT6.11877$fs6.656133@news6-win.server.ntlworld.com... > Maybe this posters views where based on the fact that the last time he used Ada > was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and > compiler technology less advanced than it is today). ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-06 11:14 ` Chris Campbell 2001-06-06 15:47 ` Marin David Condic @ 2001-06-06 17:57 ` Jerry van Dijk 2001-06-06 22:32 ` Chris Campbell 1 sibling, 1 reply; 40+ messages in thread From: Jerry van Dijk @ 2001-06-06 17:57 UTC (permalink / raw) "Chris Campbell" <chris.danx@ntlworld.com> writes: > Maybe this posters views where based on the fact that the last time he used Ada > was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and > compiler technology less advanced than it is today). Given that the poster was Jerry Coffin, that sounds very unlikely. -- -- Jerry van Dijk | email: jvandyk@attglobal.net -- Leiden, Holland | web: home.trouwweb.nl/Jerry ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-06 17:57 ` Jerry van Dijk @ 2001-06-06 22:32 ` Chris Campbell 2001-06-06 22:37 ` Chris Campbell 0 siblings, 1 reply; 40+ messages in thread From: Chris Campbell @ 2001-06-06 22:32 UTC (permalink / raw) "Jerry van Dijk" <jvandyk@attglobal.net> wrote in message news:uae3l4hkl.fsf@attglobal.net... > "Chris Campbell" <chris.danx@ntlworld.com> writes: > > > > Maybe this posters views where based on the fact that the last time he used Ada > > was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and > > compiler technology less advanced than it is today). > > Given that the poster was Jerry Coffin, that sounds very unlikely. Why? I'm sure he stated that in one of his most recent posts to alt.os.dev. Chris ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-06 22:32 ` Chris Campbell @ 2001-06-06 22:37 ` Chris Campbell 0 siblings, 0 replies; 40+ messages in thread From: Chris Campbell @ 2001-06-06 22:37 UTC (permalink / raw) > > > Maybe this posters views where based on the fact that the last time he used > Ada > > > was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and > > > compiler technology less advanced than it is today). > > > > Given that the poster was Jerry Coffin, that sounds very unlikely. > > Why? I'm sure he stated that in one of his most recent posts to alt.os.dev. I take it back, part of the post i miss read and now i've checked it and it's not true. He has used GNAT and some others. Sorry Jerry, my mistake. Chris Campbell ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada and embedded applications 2001-06-06 2:31 ` Ken Garlington 2001-06-06 11:14 ` Chris Campbell @ 2001-06-06 15:42 ` Marin David Condic 1 sibling, 0 replies; 40+ messages in thread From: Marin David Condic @ 2001-06-06 15:42 UTC (permalink / raw) I think a more prudent answer would be "It Depends". Considering that it is possible to generate programs that will need lots of constraint checking at runtime & constraint errors are sort of part of exception handling, one might conclude that exception handling can cost a significant part of the budget due to code bloat & runtime inefficiencies. (This may be from whence the original "rubbish" came from - a misunderstanding of the *necessity* of doing all this checking.) The other side of exception processing is that you can easily turn off checking & run without a net. At that point, exception processing should be at or near 0 as part of the memory/CPU budget. I've done embedded stuff where leaving in runtime error checking would have killed the project. In a sense this is "inherent in the language" because Ada requires that the checks be done for validation. In another sense it is not inherent because the language provides means of disabling the checks when speed/space is an issue. So it is fair to say that exception processing *can* impose a significant overhead, but *need not*, provided you understand what you are doing. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ken Garlington" <Ken.Garlington@computer.org> wrote in message news:JBgT6.1923$E6.322615411@newssvr16.news.prodigy.com... > : Also does exception handling in Ada really > : have a large overhead? (This is probably an implementation issue but is > their > : anything in the language that makes exception handling bulky?). > > Not for most of the embedded Ada code I've written. > > ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2001-06-14 16:27 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-06-04 18:59 Ada and embedded applications Chris Campbell 2001-06-04 19:34 ` Marin David Condic 2001-06-04 21:12 ` Chris Campbell 2001-06-04 21:33 ` Matthew Woodcraft 2001-06-04 21:33 ` Ted Dennison 2001-06-04 22:33 ` Chris Campbell 2001-06-05 7:55 ` Chris Campbell 2001-06-05 15:03 ` Ted Dennison 2001-06-04 22:09 ` Marin David Condic 2001-06-05 2:18 ` tmoran 2001-06-05 13:38 ` Marin David Condic 2001-06-06 4:09 ` Jeffrey Carter 2001-06-05 18:23 ` Randy Brukardt 2001-06-05 18:25 ` Randy Brukardt 2001-06-05 20:18 ` Marin David Condic 2001-06-05 7:45 ` Martin Dowie 2001-06-05 13:49 ` Marin David Condic 2001-06-05 20:47 ` Martin Dowie 2001-06-05 10:15 ` Rod Chapman 2001-06-04 21:02 ` Larry Kilgallen 2001-06-04 20:06 ` Ehud Lamm 2001-06-04 21:18 ` Ted Dennison 2001-06-05 12:35 ` Marc A. Criley 2001-06-05 19:00 ` Pascal Obry 2001-06-04 21:15 ` Robert A Duff 2001-06-04 21:30 ` Chris Campbell 2001-06-05 2:06 ` Jeffrey Carter 2001-06-05 14:04 ` Marin David Condic 2001-06-05 7:50 ` Martin Dowie 2001-06-05 14:24 ` John English 2001-06-08 23:55 ` Robert A Duff 2001-06-09 12:47 ` Ehud Lamm 2001-06-14 16:27 ` Pat Rogers 2001-06-06 2:31 ` Ken Garlington 2001-06-06 11:14 ` Chris Campbell 2001-06-06 15:47 ` Marin David Condic 2001-06-06 17:57 ` Jerry van Dijk 2001-06-06 22:32 ` Chris Campbell 2001-06-06 22:37 ` Chris Campbell 2001-06-06 15:42 ` Marin David Condic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox