XPost: alt.folklore.computers   
   From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   Scott Lurndal  wrote:   
   >cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >>In article <84c7R.819121$PGrb.160843@fx10.iad>,   
   >>Scott Lurndal  wrote:   
   >>>cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >>>>In article <10jjc9s$3uhtk$1@dont-email.me>,   
   >>>>Chris Ahlstrom   wrote:   
   >>>>>Waldek Hebisch wrote this post by blinking in Morse code:   
   >>>>>   
   >>>>>> In alt.folklore.computers c186282  wrote:   
   >>>>>>    
   >>>>>>>   Hmm ... look at all the GNU 'compilers' -   
   >>>>>>>   FORTRAN, COBOL, Ada, 'D', M2, Rust,C++,   
   >>>>>>>   G++, even Algol-68. None are 'compilers'   
   >>>>>>>   per-se, but to-'C' TRANSLATORS. So, 'C',   
   >>>>>>>   pretty much All Are One And One Is All.   
   >>>>>>   
   >>>>>> No.  Compiler as first stage translate given language to a   
   >>>>>> common representation.  This representatiton is different   
   >>>>>> than C.  Ada and GNU Pascal have parametrized types, there   
   >>>>>> is nothing like that in C.   
   >>>>>>   
   >>>>>>    
   >>>>>>   
   >>>>>> C++ (and some other languages)   
   >>>>>> have exceptions, C do not have them.   
   >>>>>   
   >>>>>What about setjmp()/longjmp() ?   
   >>>>   
   >>>>Not at all the same thing.  `setjmp`/`longjmp` are about   
   >>>>non-local flows of control; exceptions are about non-local   
   >>>>passing of values.   
   >>>   
   >>>However, in many real world situations, [sig]setjump and   
   >>>[sig]longjmp can be used to emulate exceptions.   
   >>   
   >>Yes, I said just that.  :-)   
   >>   
   >>>I have a C++ application that models a computer (Burroughs V380   
   >>>et alia).   The thread that models each processor (cpu) uses   
   >>>longjmp whenever a condition is encountered that would have   
   >>>been signaled as a fault on the real cpu.    The processor code   
   >>>doesn't do dynamic memory allocation;  and the fault code is   
   >>>stored in the processor class before the longjmp call.   
   >>>   
   >>>I once tried replacing setjmp/longjmp with C++ exceptions which   
   >>>led to a 20% reduction in simulated CPU performance (as measured   
   >>>by the time to compile a COBOL program).   
   >>   
   >>Huh.  Interesting.  I wonder why...possibly to run a bunch of   
   >>nop destructors?   
   >   
   >A large component of the overhead was the code generated in every   
   >function to handle unwinding during exception processing.   
      
   That makes sense; thanks.   
      
   >When   
   >using setjmp/longjmp, I compiled with the following options so   
   >it wouldn't generate the unwind code:   
   >   
   >GXXFLAGS   = -mno-red-zone   
   >GXXFLAGS  += -fno-strict-aliasing   
   >GXXFLAGS  += -fno-stack-protector   
   >GXXFLAGS  += -fno-exceptions   
   >GXXFLAGS  += -Wall   
   >GXXFLAGS  += -mtune=native   
      
   Most of those seem irrelevant to generating extra code for stack   
   unwinding.  `setjmp`/`longjmp` are really just pushing and   
   popping some register state (including the stack pointer) so   
   presumably it simply skips all of that code by skipping over any   
   intermediate stack frame frames?   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)