Messages in this thread | | | Date | Tue, 2 Mar 2010 10:05:27 +0200 | From | Gleb Natapov <> | Subject | Re: use of setjmp/longjmp in x86 emulator. |
| |
On Mon, Mar 01, 2010 at 01:34:42PM -1000, Zachary Amsden wrote: > On 03/01/2010 12:56 PM, H. Peter Anvin wrote: > >On 03/01/2010 02:31 PM, H. Peter Anvin wrote: > >>On 03/01/2010 11:18 AM, Zachary Amsden wrote: > >>>It's going to be ugly to emulate segmentation, NX and write protect > >>>support without hardware to do this checking for you, but it's just what > >>>you have to do in this slow path - tedious, fully specified emulation. > >>> > >>>Just because it's tedious doesn't mean we need to use setjmp / longjmp. > >>>Throw / catch might be effective, but it's still pretty bizarre to do > >>>tricks like that in C. > >>> > >>Well, setjmp/longjmp really is not much more than exception handling in C. > >> > >For what it's worth, I think that setjmp/longjmp is not anywhere near as > >dangerous as people want to make it out to be. gcc will warn for > >dangerous uses (and a lot of non-dangerous uses), but generally the > >difficult problems can be dealt with by moving the setjmp-protected code > >into a separate function. > > I'd be curious to see if it would need to evolve it to preemptsetjmp > / irqlongjmp or some other more complex forms in time. > Just don't allow stupid usage of longjmp. Like everything else it can be abused.
> But I'd rather implement a new language where acquisition of > resources such as locks, dynamically allocated objects, and ref > counts are predicated in the function typing and are heavily > encouraged to possess defined inverses. Then the closure of a > particular layer of nesting already has enough information to > provide release upon escape, and the compiler can easily take the > burden of checking for a large class of lock and resource violation. > > And it would have to be prettier than the current languages that do > that, meaning operator overloading would be banned. Although it > would define rational numbers, super-extended precision arithmetic, > imaginary numbers, quaternions and matrices as part of the spec, so > there would be no need to use arithmetic overrides anyway, and then > all the nonsensical operators could die, die, die, especially the > function () and logical operator overrides. > Will you language have a lot of parentheses?
-- Gleb.
| |