ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (01/20/91)
I just upgraded from Turbo Pascal 5.0 to 6.0 had have some questions: 1. Software Floating Point: It looks like they've made rather dramatic improvements with software floating point. My astronomy program, which relies heavily on floating point, runs about 40% faster when software floating point is used. Has anyone noticed similar speedups? 2. Turbo Vision: Turbo Vision is supposed to allow you to have hints associated with submenus that appear in the status line. For example, when you're running the Turbo Pascal Integrated Development Environment, if you hold down the left mouse button and scan down the submenus, brief "hints" will appear in the status line for each submenu. The manual makes brief mention of this, but unfortunately I could not find an example in the manual or in the demo source directories. Does anyone have an example of submenus with "hints"? 3. Turbo Pascal for Windows: Turbo Pascal for Windows is supposed to be out in the first quarter of this year. Has anyone heard if Borland is going to make Turbo Vision "talk to" Windows 3.0? If I knew that Turbo Vision applications could become Windows 3.0 applications by changing a compilation option, I suppose that it would make the investment in learning Turbo Vision worthwhile... Thanks in advance, Eric Bergman-Terrell
ace@cc.ic.ac.uk (Andriko del Saludo) (01/22/91)
In article <1991Jan20.152128.21994@isis.cs.du.edu> ebergman@isis.UUCP (Eric Bergman-Terrell) writes: > >I just upgraded from Turbo Pascal 5.0 to 6.0 had have some questions: > >1. Software Floating Point: >3. Turbo Pascal for Windows: > > Turbo Pascal for Windows is supposed to be out in the first quarter > of this year. Has anyone heard if Borland is going to make > Turbo Vision "talk to" Windows 3.0? If I knew that Turbo Vision > applications could become Windows 3.0 applications by changing > a compilation option, I suppose that it would make the investment > in learning Turbo Vision worthwhile... > I picked up a thread like that on compuserve. Apparently Borland will not say that TPW will support turbo vision (in fact it strongly denies it). On the other hand the comment was that if you learn TV now, porting to TPW will bw much much easier, which implies a measure of support for TV. Also, when I saw a beta version of TPW it looked like compiling a TV app quite effortlessly. IMHO TV is a useful thing to learn. ace -- --------------------------------------------------------------- - Andreas C. Enotiadis (ace@cc.ic.ac.uk, ace@epstech.uucp) - - (I'm still thinking about something clever to put here...) - ---------------------------------------------------------------
eli@smectos.gang.umass.edu (Eli Brandt) (01/23/91)
In article <1991Jan20.152128.21994@isis.cs.du.edu> ebergman@isis.UUCP (Eric Bergman-Terrell) writes: > >I just upgraded from Turbo Pascal 5.0 to 6.0 had have some questions: > >1. Software Floating Point: > > It looks like they've made rather dramatic improvements with > software floating point. My astronomy program, which relies > heavily on floating point, runs about 40% faster when software > floating point is used. Has anyone noticed similar speedups? This sounds like you're using {$E+}, IEEE floating point. IMHO, this is a bad idea: without a coprocessor, it's so damned slow (though yes, it is faster than 5.0, I got about 30%) that it's intolerable. What I end up doing is distributing two versions of every fp-intensive program: one '87-only and the other with six-byte reals. In 5.0, E+ was about one third the speed of E-, if I'm remembering the right numbers. I haven't looked at 6.0 output, but in 5.0, every time you do an E+ fp instruction, it calls some INT 37h I believe, which then goes to Borland fp code to convert your real to 10-bytes, multiply these mongo 10-byte reals, convert them back, and return from the interrupt. What's worse, even if the user has an '87, it still goes through an interrupt for each instruction, which is some serious overhead... [ second question deleted; I haven't learned TV yet ] >3. Turbo Pascal for Windows: > > Turbo Pascal for Windows is supposed to be out in the first quarter > of this year. Has anyone heard if Borland is going to make > Turbo Vision "talk to" Windows 3.0? If I knew that Turbo Vision > applications could become Windows 3.0 applications by changing > a compilation option, I suppose that it would make the investment > in learning Turbo Vision worthwhile... I would guess that that's why they put it in. However, who knows? If I write a few 20 K-line programs in Turbo Vision and Borland pulls a Turbo Basic on it, I'm going to be *annoyed*. I couldn't care less about TP/Windows, but TP for X might be interesting. >Thanks in advance, > > >Eric Bergman-Terrell Eli
ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (01/27/91)
No, the software floating point that I noticed a 40% improvement in was the standard one (i.e. not 8X87 emulation). I've never used the software 8X87 emulation because it was (in 5.0 anyway) about 50% slower than the standard software floating point... Apparently Borland tuned some of the floating point library routines - compared with my program compiled under 5.0 and 6.0, some of the numerical results differ in the least significant digit displayed by my program. Terrell
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (02/07/91)
In article <25453@dime.cs.umass.edu> eli@smectos.CS.UMASS.EDU (Eli Brandt) writes: > >This sounds like you're using {$E+}, IEEE floating point. IMHO, this is a bad >idea: without a coprocessor, it's so damned slow (though yes, it is faster than >5.0, I got about 30%) that it's intolerable. What I end up doing is distributing >two versions of every fp-intensive program: one '87-only and the other with >six-byte reals. In 5.0, E+ was about one third the speed of E-, if I'm remembering >the right numbers. I haven't looked at 6.0 output, but in 5.0, every time you >do an E+ fp instruction, it calls some INT 37h I believe, which then goes to >Borland fp code to convert your real to 10-bytes, multiply these mongo 10-byte reals, >convert them back, and return from the interrupt. What's worse, even if the user >has an '87, it still goes through an interrupt for each instruction, which is >some serious overhead... No, it only goes through the interrupt the first time. The interrupt checks to see if there's an FPU installed, and if so, patches the caller back to inline code. I always use the E+ version, but you're right: I wouldn't want to execute any Duncan Murdoch