Zortech C++ 2.12 Problems

Robin Becker rb at cc.ic.ac.uk
Thu Nov 8 00:30:21 AEST 1990


I just tried out Zortech's C++ 2.1 and had some severe problems with
porting a large program (I currently use MSC 5.1).  The code is large
so I wanted to try VCM (virtual code management).

Problem 1 is that the setjmp/longjmp pair in the distributed library
don't work in VCM.  I have the library source and was able to check
and after some struggling I repaired this.  I was able to get longjmp
to leap into code which had been swapped to disk and so on. However,
I am fairly certain that with the way VCM is implemented it's almost
impossible to get setjmp/longjmp and signal trapping to work repeatedly.
The problem seems to be that longjmp is supposed to jump to an earlier
program state (i.e. higher up the stack) and VCM doesn't maintain a
stack; instead it maintains a set of code chunks in lieu of swapped
out overlays.  By unrolling the stack and removing the unwanted chunks
I guess you could get back to the original state, but the current
implementation doesn't make this easy or efficient.  VCM certainly
isn't plug 'n go by any means.

Problem 2 concerns floating point error trapping.  It seems that the
traditional meaning of signal(SIGFPE,..) is ignored.  You can only
trap floating point errors if you use the FP emulation routines.
And then only if you add a routine called CFXERR.  I looked in the
source and sure enough there's a statment in the signal code of
the form case SIGFPE: break; /*ignore*/ 8-(.  If you use inline
80x87 code errors go untrapped.  Also these errors corrupt the
80x87 stack i.e. after an invalid operation one of the operands may
not get popped properly.

Theoretically I could install my own hardware trap rewrite the emulator
to eliminate the redundant error status bit checks and eliminate
problem 2,  but alas Zortech have chosen to use subroutine calls
to simulate the floating point instructions rather than the interrupt
mechanism which MSC & my assembler (& TC?) use so all my high speed
stuff would go out the window.  I haven't got the time, the compiler
seems to work ok,  but the libraries lack depth and security and
I have junked this product after less than a week of use.  The VCM
stuff seems to work (modulo problem 1),  but if I hadn't got the
library source I couldn't have fixed even that.  Maybe the beta
testers were in beta (or maybe gamma) mode.

Finally on the Byte benchmarks which I ran, MSC 5.1 beat Zortech every
time.

Oh well back to overlays
			Robin Becker



More information about the Comp.lang.c mailing list