[prev] [thread] [next] [lurker] [Date index for 2007/01/29]
Martin Ebourne wrote: > On Sun, 2007-01-28 at 13:44 +0200, Yossi Kreinin wrote: > > Now lets see, this shouldn't be too hard. The key point to remember here > is that a try block covers a fixed range of code which always resides > within a given range of machine addresses for any given compilation > (ignoring PIC here, but that's fixable). > > So what we need are some good old fashioned tables here. Say start > address, end address, catch handler address, maybe stack offsets and > other stuff. When the implementation's throw function is called it is > trivial to unwind the stack and get the program counter in each method > back up the stack, after all this has to be saved anyway for normal > operation. I don't think it does. What does have to be saved is the address right after the point of call. The address of destructors needed for unwinding is a different address. I guess you could arrange some way to look up the one based on the other (using a new-fashioned hash table or something), not the most trivial thing to do. PIC code aside, I don't think anyone actually produces hash tables at link time. And there is not always a "canonical" callstack layout (the kind you can parse from within the program without knowing how each function was compiled). gcc has -fomit-frame-pointer telling it to avoid generating this canonical layout. Green Hills does this by default. For each function you'll have to generate a lot of code handling each special case of unwinding. The approach apparently taken by, say, gcc on x86 - adding a dynamically maintained unwind stack - has the big advantage of being simple enough to be reliable enough. > > No rocket science here I'm afraid. Lack of rocket science is probably not something to be afraid of... Let's make it simple: did you actually see it /done/? I tried it with gcc 3.3.1 on x86 and exceptions do translate to overhead (I don't know x86 assembly either, but I can see when 2 additional instructions are emitted). Green Hills on ARM is worse, trust me. Let's say I don't care for the monstrous inflation of data. Let's say I don't care that the generated assembly code looks like dog vomit. Can you name a platform where no extra instructions in the normal flow path are generated when exceptions are enabled? A lot of things are simple, theoretically. Theoretically you can take a huge program with no user-specified type information (say, a Scheme program) and have a smart compiler figure out the static type constraints wherever they exist and generate all the statically-typed implementations at link time, and it's constant time, right, since the program size is a constant, right? I really want to know about a practical platform which handles exceptions well. Maybe it does other things which are theoretically possible with C++ but I've never seen them done either.There's stuff above here
Generated at 23:01 on 06 Feb 2007 by mariachi 0.52