Steve Scaffidi wrote:
Bob Rogers wrote:
Better is a language design where the handler runs in the dynamic
context of the exception, and gets to decide what to do, and how much
information to capture. Like Perl 6. (Does this mean we're back on
topic now? ;-)
It's certainly a powerful
Interesting post and thread. I'm always learning something new on this list.
My experience has been in authentication code. If login is broken,
everything is broken. Hence, there are high uptime requirements. But it
is only money, not lives at stake. Also, not embedded in a shipping
On Fri, Mar 19, 2010 at 10:49:43AM -0500, Charlie Reitzel wrote:
Likewise, compilers have a _lot_ more miles on them by now, so trust
levels should be improved there as well.
I don't know about that. Hopefully the compiler writers that embedded
programmers
use are doing a better job than
Greg London Wrote:
[ John Redford wrote:]
you have a call stack, and you want code to execute quickly in order to
meet a time constraint (hard or not),
Now, checking every next() call to see if it
returns EOF (or sets some EOF flag variable) is inefficient,
You're not thinking like
I don't know, but I would guess that embedded coding standards may be
liberalizing (for lack of a better word) in response to hardware
changes. Actual CPUs, with hardware support for a stack are the norm
these day, no? Don't only very high volume, low cost mass market
products (e.g. remote
On Thu, Mar 18, 2010 at 11:40:40AM -0400, Martin Cracauer wrote:
FWIW, in C++ as of today's gcc, a function exiting with a thrown
exception is roughly 1000 times more expensive than a regular
call/return ...
More expensive defined how? Memory usage? CPU cycles? Developer
effort?
I just
Charlie Reitzel wrote:
Point being, there is a gradation of programming techniques appropriate to
different environments.
However, I have yet to find an actual working environment that would call
for using Exceptions as normal flow control (same goes for setjmp/longjmp).
In my
David Cantrell wrote on Fri, Mar 19, 2010 at 04:04:33PM +:
On Thu, Mar 18, 2010 at 11:40:40AM -0400, Martin Cracauer wrote:
FWIW, in C++ as of today's gcc, a function exiting with a thrown
exception is roughly 1000 times more expensive than a regular
call/return ...
More expensive
...I think something has been lost here. You seem to be implying that
writing fast code does not matter for embedded code, because it runs
against a fixed clock.
The thing being lost is the difference between code that
you think is fast and code that you have *proven* is fast.
the FAA
GL and then there's
GL embedded as in must achieve a frame rate of 30 hz.
Where
30 Hz is a variable,
and
must may be of varying strength / harm -
* otherwise the screen refresh will be skipped jerky, or only partial
ugly;
...
* otherwise Flight Law control loop time is violated and
Greg London wrote:
And no open-ended processes are allowed per frame.
But Nothing about throwing exceptions is open-ended.
How deep is your stack?
That does not really matter. What matters is the complexity of the flow.
I suspect I know what you're thinking here, based on what you say
But do all programming techniques need to be approved by the FAA?
Any used in licensed devices subject to FAA or FDA or NSA/DoD or NASA
review, ranging from the Space Shuttle flight computer to on insulin
pump. Testing doesn't count with them.
That puts *Engineering* into Software
Greg London wrote:
What you're doing is you're telling me that you think
using exceptions will be faster than using other
control structures. And maybe you can provide a case
where the real objective measures show that it is
faster. But you haven't *proven* it will be fast and
accurate
I _am_ telling you I think exceptions are faster than other control
structures _In_ _Some_ _Cases_.
I'm happy to explain clarify if I am unclear.
I'm curious.
Maybe I'm out of my depth, pun not intended, but I was under the impression
that thrown exceptions have to unwind the stack anyway.
WHOA!
I _am_ telling you I think exceptions are faster than other control
structures _In_ _Some_ _Cases_.
But you can just think about that. Or not. I'm happy to explain
clarify if I am unclear. But I am not here to tell you what to do and
prove why you should do it.
It went like
William Ricker wrote:
Yes. longjmp was once not only less C code but far far quicker to unwind
a deep stack than the standard
return(-1) if rc 0; # lather rinse repeat
in old C on old slow hardware without optimized stack instructions. The
return()'s register swizzling is far cheaper on
On Fri, Mar 19, 2010 at 11:07 AM, Conor Walsh c...@adverb.ly wrote:
I _am_ telling you I think exceptions are faster than other control
structures _In_ _Some_ _Cases_.
I'm happy to explain clarify if I am unclear.
I'm curious.
Maybe I'm out of my depth, pun not intended, but I was under
Conor Walsh writes:
Maybe I'm out of my depth, pun not intended, but I was under the impression
that thrown exceptions have to unwind the stack anyway. Is there some way
exceptions are usually implemented that doesn't cost as much as unwinding
the stack one level at a time? It seems like
In a desktop environment this makes sense. However in some other
contexts, such as real time embedded programming, it likely doesn't.
And the issue there is the difference between average running time and
worst case running time.
I'd kiss you right now if I could...
;)
On Fri, Mar 19, 2010 at 2:31 PM, Greg London em...@greglondon.com wrote:
In a desktop environment this makes sense. However in some other
contexts, such as real time embedded programming, it likely doesn't.
And the issue there is the difference between average running time and
worst case
From: Ben Tilly bti...@gmail.com
Date: Fri, 19 Mar 2010 11:34:41 -0700
On Fri, Mar 19, 2010 at 11:07 AM, Conor Walsh c...@adverb.ly wrote:
I'm curious.
Maybe I'm out of my depth, pun not intended, but I was under the
impression that thrown exceptions have to unwind the
When I said exceptions are just flow control, I meant it in the broad,
almost-trivial machine sense.
But then your point has nothing to do with marketing.
All languages can do exceptions, and all exceptions
translate into either branches in assembly or the
hardware seeing a physical
Charlie Reitzel wrote on Wed, Mar 17, 2010 at 07:11:55PM -0500:
I was quietly reading this thread, but I must respectfully but strenuously
disagree with the premise that exceptions are simply another kind of flow
control. OK, semantically exceptions _are_ another type of flow
control.
On Thu, Mar 18, 2010 at 11:40:40AM -0400, Martin Cracauer wrote:
...
This is the reason why coding standards for systems with very high uptime
requirements often disallow throwing exceptions. This can extend to
disallowing use of libraries that throw (or taking pains to configure libs
Mike Small wrote on Thu, Mar 18, 2010 at 01:07:52PM -0400:
On Thu, Mar 18, 2010 at 11:40:40AM -0400, Martin Cracauer wrote:
...
This is the reason why coding standards for systems with very high uptime
requirements often disallow throwing exceptions. This can extend to
disallowing
But for safety critical projects, the no rtti, no exceptions rule
is pretty common isn't it? Not sure if it's justified or not, but
very common from what I hear. Something to do with code verification,
provability?
I'm a little rusty, but my memory of life-critical avionics certification
On Thu, Mar 18, 2010 at 01:30:13PM -0400, Martin Cracauer wrote:
garbage collection (which only helps with memory resouces), or
reference counted smart pointers.
Resources are more than memory. In the age of 64 bit virtual memory
memory leaks are actually a comparably minor issue.
File
So anyone have a guess at which tools they mean? The compiler itself
or testing and verification tools?
When you are working on a life-critical avionics (LCA) project,
everything must be certified to the same stringent requirements.
That means the compiler must be certified as strictly as
On Thu, Mar 18, 2010 at 01:46:43PM -0500, Greg London wrote:
So anyone have a guess at which tools they mean? The compiler itself
or testing and verification tools?
When you are working on a life-critical avionics (LCA) project,
everything must be certified to the same stringent
Greg London wrote:
[...Lots of fascinating stuff removed...]
It's not a language problem. It's not a construct problem.
It's not that embedded folks don't know that exceptions
are nothing more than jumps.
And yet they do use jumps, no?
When it comes down to it, it's a *system* issue.
Well, interrupts aren't exceptions.
sorry, I'm programming an interrupt controller right now.
wires got crossed.
you have a call stack, and you want code to execute quickly in order to
meet a time constraint (hard or not),
Now, checking every next() call to see if it
returns EOF (or sets
I was quietly reading this thread, but I must respectfully but strenuously
disagree with the premise that exceptions are simply another kind of flow
control. OK, semantically exceptions _are_ another type of flow
control. Let's not jump down a rathole. But, in any language,
exception-safe
32 matches
Mail list logo
