alex@mks.UUCP (06/24/87)
I haven't seen much mention on this group of the fact that Turbo C is really just the next release of Wizard C. They purchased the copyright. They have sped it up by merging the passes all into one large executable, and using all of memory for the temp file and never going to disk. The speed is impressive. Service for Wizard customers is disapointing. After having paid $450 for wizard, and $100 per year for update service to Wizard, Wizard is as a direct result of the buyout defunct - their support line is a recording to phone Borland. The only thing that Borland is willing to do is give a free $99 Turbo compiler. They will not give the $295 library source which used to come with wizard. While they tell us that they'll support wizard until the end of Aug., what this means is answer user level questions - no bug fixes, basically they say does the bug still exist under Turbo. The people on their customer support line are helpful and knowledgable, but there is no 800 number, and if its busy you have a choice of waiting or phoning again - they will not phone back. Now Turbo C generates smaller and faster code than Wizard. EXCEPT for floating point. Wizard generated in-line function calls like dadd@ to add two floating point numbers on the stack. Turbo generates the real 8087 instructions, assembled with the masm /e option for special interrupts for a floating-point emulator. This is very slow - I've only tried it on one floating point problem so far - it took 40% more time to run than the wizard version [this is with no floating point chip. I don't know about with it]. I guess that simply saving and restoring registers after an interrupt and interpreting the instruction is simply slower. Profiling it shows 67% of the time in e086_shortcut or e086_entry for turbo. Only 41% is spent in dmul@, ddiv@, normalize@, cvtdl@ and such in wizard. [The other nice thing about old wizard is that profiling it showed exactly which floating point op's were taking the time and makes it much easier to rewrite a piece of the code without floating point]. Turbo C with floating point is also much larger - it appears to drag in all kinds of wierd stuff. Without library sources however, you can't tell what is what and just why various pieces are being dragged in. I suppose as an emulator it has to bring in everything because it doesn't know which instructions you might have - as opposed to calling external routines where if you had no divides, the ddiv@ wouldn't get called in.