rb@cc.ic.ac.uk (Robin Becker) (11/07/90)
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
bright@nazgul.UUCP (Walter Bright) (11/16/90)
In article <1990Nov7.133021.9748@cc.ic.ac.uk> rb@cc.ic.ac.uk (Robin Becker) writes:
<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).
<Oh well back to overlays
I encourage you to Zortech a call and get your money refunded if you are that
unhappy with it.