amitava@ei.ecn.purdue.edu (Amitava Das) (06/13/91)
A beginner's question befor i invest on a compiler for my newly acquired PC I plan to write long memory and cpu intensive ( i am not overly interested in nice graphics in window) programs in either fortran or c & c ++. these will primarily be automating electrical machine design problems (such as desigining a huge power transformer, i know they will be slow, but that's ok if i could run at all). i will need to define large arrays, so, i need as much memory as i can. i have 4M of "EXTENDED" RAM. My system is 80386, 33MHz, IBM Compatible. DOS 4.01 1) Can the PC compilers (for example, Boreland C++, or Microsoft Fortran or other cheaper Fortran compilers) make use of the extended memory automatically, or do i need to call the compiler from operating system environments such as Disqview 386 or Windows to make use of the extended memory? In other words, does the compiler need an extended memory manager to make use of the extended memory? 2) is there any limitation on how much lines of code, and how many arrays these compilers can support or these are determined by the system hardware? any suggestion about compilers which are not too expensive, and not too fancy but will allow me run large programs. thanks a lot for your time. any suggestion about any specific brand of not-very-expensive compiler will be highly appreciated. thanks amitava@ecn.purdue.edu
<LEEK@QUCDN.QueensU.CA> (06/13/91)
In article <KHB.91Jun13100812@chiba.Eng.Sun.COM>, khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) says: > >Check the adverts again. Lahey has been selling one for quite some >time. I have not used it extensively, but it seemed to work well. >-- Yes. The compilers are fairly good, but I am a little bit disappointed at the $2000 + price tag to get it to use more than 640K of memory. The company trys to make lots of $$$ by selling the compilers at a heafty price. (There is nothing wrong with that. I don't like nor use FORTRAN anyway) We found that out recently. We decided to do C++ route - use Borland C++ for developement work & compile it with GCC if we need lots of memory. (GCC is free and supports up to 256 megabytes of Virtual Memory) >---------------------------------------------------------------- >Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM >SMI 2550 Garcia 12-33 | (415 336 2648) > Mountain View, CA 94043 K. C. Lee
dlindsle@afit.af.mil (David T. Lindsley) (06/13/91)
From a design standpoint, you'd be better off with C++, I think. The only Fortran I know of that can use extended memory is Watcom's. However, it does so by using the Phar Lap (memory management?) software. We have had this here at AFIT for about six months; as far as I know, we haven't even been able to get Watcom's demo programs (supplied with the compiler) to work. (The people trying to get it to work are electrical & computer engineers, FYI.) You need a compiler that will compile 386 code. As far as I know, what these things basically do is raise an exception or some signal which puts the CPU into (386) protected mode. Now you've got your 4GB segments, and the program can run. When it's done, the CPU goes back into whatever mode it was in. I also (personally) tried getting an MS Fortran program to use extended memory from Windows 3. The program manipulated several matrices, which should (ideally) have been about 3..4Mb. No luck there either. However, I'm no Windows expert -- maybe I wasn't setting something correctly. (Anybody out there had better luck?) Anyway, like I said, you need a compiler that "speaks 386". I like Borland's compilers, but I'm not sure if they've got a 386 line. I know Zortech does, though. Have you considered getting Unix for your 386? -- Dave Lindsley #24601# OPINIONS. MINE. (Nobody tells me dlindsle@blackbird.afit.af.mil anything anyway, so I can't possibly ?? lamroN eb yhW ?? be anybody's mouthpiece...)
dlindsle@afit.af.mil (David T. Lindsley) (06/13/91)
DOS will only recognize 1Meg of memory (based on the 8086's 16-bit address bus, plus a 4-bit segment register). Of this, the upper 384K are reserved by DOS for itself, leaving 640K. What extended memory managers actually do is fool DOS into thinking there's more memory than there really is. In addition, they relocate device drivers (e.g. MOUSE.SYS, VDISK.SYS, ANSI.SYS) and other memory- resident stuff in those 384K of "high memory", which leaves more of your 640K base memory available for whatever. But even a "far" (20-bit) pointer is still only going to be able to address 1Meg of memory. i.e. if you've got arrays or other chunks of data or code bigger than ~600K, you're in trouble (that's why you need a 386-based compiler). Overlays can reduce your code size into manageable chunks. A 250x250 double-precision array is half a meg (which doesn't leave you a lot of space for the rest of your data, let alone the code). If your data is in smaller chunks, you may be able to do something with a memory manager (or try and let Windows do "paging" for you). Good luck; my experience tells me you'll need it. -- Dave Lindsley #24601# OPINIONS. MINE. (Nobody tells me dlindsle@blackbird.afit.af.mil anything anyway, so I can't possibly ?? lamroN eb yhW ?? be anybody's mouthpiece...)
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (06/14/91)
>The only Fortran I know of that can use extended memory is Watcom's.
Check the adverts again. Lahey has been selling one for quite some
time. I have not used it extensively, but it seemed to work well.
--
----------------------------------------------------------------
Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043
tholen@hale.ifa.hawaii.edu (Dave Tholen) (06/14/91)
David T. Lindsley writes: > The only Fortran I know of that can use extended memory is Watcom's. > > I also (personally) tried getting an MS Fortran program to use extended > memory from Windows 3. The program manipulated several matrices, which > should (ideally) have been about 3..4Mb. No luck there either. However, > I'm no Windows expert -- maybe I wasn't setting something correctly. > (Anybody out there had better luck?) Microsoft recently announced version 5.1 of their FORTRAN compiler, with extensive Windows support, including the use of extended memory. To quote from their brochure: "Access all virtual memory on a PC with an 80386 or higher processor, up to 64 megabytes. Access all extended memory on a PC with an 80286 processor." Of course, starting with version 4.1, Microsoft's FORTRAN compiler also ran under OS/2, which gave you access to 16 megabytes of memory. Which vendors will support the 32-bit version of OS/2 (which has a 4 gigabyte flat memory architecture) remains to be seen.
BVAUGHAN@pucc.Princeton.EDU (Barbara Vaughan) (06/14/91)
In article <1991Jun13.160602.23726@afit.af.mil>, dlindsle@afit.af.mil (David T. Lindsley) writes: > >The only Fortran I know of that can use extended memory is Watcom's. >However, it does so by using the Phar Lap (memory management?) >software. We have had this here at AFIT for about six months; as far >as I know, we haven't even been able to get Watcom's demo programs >(supplied with the compiler) to work. (The people trying to get it >to work are electrical & computer engineers, FYI.) I asked several months ago about Fortran compilers for 386 machines and received many replies from happy users of Watcom's compiler. I also received a copy of a review published in the April '90 issue of Computer Language which mentions four compilers that can run in protected mode: Lahey F77LEM/32, OTG FTN77, Microway NDP and SVS F77. The latter two compilers got very poor reviews; Watcom was not reviewed as it was still in beta test when the review was published. All of these can also use virtual memory (some require Phar Lap Tools, Lahey requires separate purchase of its own Ergo OS/386.) I will send copies of these letters and reviews on request. I must warn that I found some inaccuracies and cannot be sure of the correctness of some of the letters and comments. But that's the weakness of the net, as this posting shows. Barbara Vaughan
kil@pandora.cs.wayne.edu (Joseph I. Landman) (06/14/91)
I am quite familiar with the use of 286/386 type machines, and the fortran compilers ms fortran 5.0, and the lahey f77-lem/16. I must state that for memory intensive/compute intensive work I would NOT recommend a strict 386/387 system. The benchmark speeds that have some applicability inidcate that they run about .25 MegaFlop for a 33Mhz system. But if you have this system and you cannot afford the funds to upgrade, then I would recommend the following course of action. Buy the Microsoft fortran (v5.1) and OS/2, the unbundled version. this option is inexpensive in comparison to getting unix for the 386 with a compiler, etc. OS/2 unbundled can be had for about 150$, and it will let ms fortran use ALL of available memory for its data objects. MS fortran will generate re-entrant multithreaded code that will run under OS/2 (it comes with os/2 specific libraries). Plus, this code will run/compile etc in the background if you wish. This is probably the least expensive option, and possibly the simplest. Others have suggested unix on the 386. Well Ive been using PC's since IBM introduced them, from measly little 8088 based machines (like the one I am typing on now), to speedster 486 machines with 16Mb memory, etc. Unix on these machines is horrible. Not the implementation, just the speed. If you are willing to spend the ridiculous amount of money on a new operating system that some of the people suggested, you may as well get better hardware instead. Such as an i860 based addin card for the 386 machine with a fortran compiler. I have seen ttthe torq, and i860 based workstation. with only one i860 processor, fortran flies at about 12 Mflops . The addin cards are simialr I understand. Thus for about the price of a new (slow) sparc 1, you can get the performance of an rs 6000 / 520. I personally do extremely compute intensive non vectorizable work that requires raw megafloppage. THe local IBM3090 is not fast enough for me, my short runs take about aCn hour, at midnight. I tried this program on my 286/10. Well I let the machine run over the weekend, and voila, monday morning, it was still chugging away..., not even through the 1st iteration of several hundred. I have used the lahey compiler f77-lem 16. It is a bit flaky on the 286/10, but I am very impressed by the speed and quality on the 386/387 in my thesis advisors office. If it were more reasonably priiced, I would have my own personal copy for home, but I have as of yet to see a reasonably priced fortran compiler for PC's. Joe Landman kil@pandora.cs.wayne.edu D
martelli@cadlab.sublink.ORG (Alex Martelli) (06/14/91)
amitava@ei.ecn.purdue.edu (Amitava Das) writes:
...
:define large arrays, so, i need as much memory as i can. i have 4M of
:"EXTENDED" RAM. My system is 80386, 33MHz, IBM Compatible. DOS 4.01
:
:1) Can the PC compilers (for example, Boreland C++, or Microsoft
:Fortran or other cheaper Fortran compilers) make use of the extended
:memory automatically, or do i need to call the compiler from operating
:system environments such as Disqview 386 or Windows to make use of the
:extended memory? In other words, does the compiler need an extended
:memory manager to make use of the extended memory?
Zortech C++, in its new release 3.0, comes, according to what I've read, with
a built-in "Dos extender" that will let you take full advantage of an 80286
(addressing 16 Mbytes) or even better of an 80386 (addressing huge amounts
AND performing 32-bit operations) - at least in the Professional Edition, but,
I believe I recall, even in the cheaper one. I have not yet received the
upgrade info from the 2.1 I have, so this is half-recalled hearsay...
For other compilers, you may need specific 386-editions, as well as a separate
"Dos extender" products (some compilers may come with bundled extender, like
Zortech will, but I know of none). Here, for example, we use Watcom Fortran
and C, and the Pharlap dos-extender, but cheap, they are NOT!
--
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).
roth@oasys.dt.navy.mil (Pete Roth) (06/14/91)
If funding is the problem, you might consider contacting the umiacs project people at the U of Maryland...they are offering *free* time on a Connection Machine... regards, pete - - - - - - - - - - - - - - - - - - - - - - - - - - Peter N Roth roth@oasys.dt.navy.mil Objects in this office are closer than they appear.
iris@interet.UUCP (User) (06/14/91)
In article <1991Jun13.160602.23726@afit.af.mil> dlindsle@afit.af.mil (David T. Lindsley) writes: >The only Fortran I know of that can use extended memory is Watcom's. Several others do. We use Silicon Valley Software's FORTRAN and C and are fairly pleased with their performance and quality. Others include NDP, and Lahey. All of these use PharLap's extender. The extender can be "bound" into the executable so that you end up with "YOURPROG.EXE". ========================================================================== Iris Engelson uunet!iris@interet Director of Software Development Tel: 201-763-1200 Interet Fax: 201-763-5120 111 Dunnell Road Maplewood, NJ 07040
dlindsle@afit.af.mil (David T. Lindsley) (06/14/91)
tholen@hale.ifa.hawaii.edu (Dave Tholen) writes: >Microsoft recently announced version 5.1 of their FORTRAN compiler, with >extensive Windows support, including the use of extended memory. To quote >from their brochure: > "Access all virtual memory on a PC with an 80386 or higher processor, > up to 64 megabytes. > Access all extended memory on a PC with an 80286 processor." I read about that too in one of the PC journals. They even had a 800 number you could call. I did. What I got was "The number you have reached -- xxx-xxxx -- has been disconnected." Using virtual paging to access extended memory is one thing. What I want to know is, what's the page size? Like I said, I'm interested in using large arrays. An array reference A(i,j) into an n by m matrix usually is computed as <value at (address of array + offset)> = <value at (address of A(1,1) + ((j-1)*n) + i)>. (This assumes column-major storage, but for row-major storage you'd just swap i and j in the formula.) Note that the address formula will consist of two far (20-bit) pointers (on a 286 or less, or in code generated by a non-386 compiler). So -- and this is the million-dollar question -- what happens if and when an array is bigger than (min(page_size, 640K))? When, in other words, the offset may be larger than 1MB, and therefore cannot be stored as a 20-bit pointer? Does the VM scheme allow for segmenting data across page/1M boundaries? That, incidentally, is what I called Microsoft's 800 number to find out. I think this is a legitimate question -- FORTRAN is, after all, the standard language for numerical work, and matrices with (say) 500 rows and columns are not all that unusual. (Whether that sort of work ought to be done on a PC is another question, but you can't argue too loudly about the customer's equipment when you're a mere consultant.) Anybody had experience with this sort of thing? Am I missing something obvious here? Please note that I have directed followups to comp.sys.ibm.pc.programmer. This thread has strayed away from FORTRAN proper, and that group is more appropriate. -- Dave Lindsley #24601# OPINIONS. MINE. (Nobody tells me dlindsle@blackbird.afit.af.mil anything anyway, so I can't possibly ?? lamroN eb yhW ?? be anybody's mouthpiece...)
2011_552@uwovax.uwo.ca (Terry Gaetz (UWO Astronomy)) (06/15/91)
In article <12844@pucc.Princeton.EDU>, BVAUGHAN@pucc.Princeton.EDU (Barbara Vaughan) writes: [...] > I asked several months ago about Fortran compilers for 386 machines > and received many replies from happy users of Watcom's compiler. > I also received a copy of a review published in the April '90 issue > of Computer Language which mentions four compilers that can run in > protected mode: Lahey F77LEM/32, OTG FTN77, Microway NDP and SVS F77. > The latter two compilers got very poor reviews; Watcom was not reviewed > as it was still in beta test when the review was published. > All of these can also use virtual memory (some require Phar Lap Tools, > Lahey requires separate purchase of its own Ergo OS/386.) > I will send copies > of these letters and reviews on request. I must warn that I found > some inaccuracies and cannot be sure of the correctness of some of > the letters and comments. But that's the weakness of the net, as this > posting shows. I was singularly unimpressed with the _Computer_Language_ review. The reviewer seemed to be mainly concerned with whether the Fortran could be made into Turbo Pascal and totally unconcerned with quality/efficiency issues important to people interested in large programs with long runtimes. None of the 'benchmarks' used were standard, so it was impossible to verify his results. (His comparison of runtimes for Microsoft Fortran vs. NDP Fortran-386 gave results almost diametrically opposed to my own experiences.) The review included none of the commonly used benchmarks (LINPACK, Livermore Loops). In his testing of protected-mode 386 compilers, the reviewer didn't bother to try out programs which were large enough to require more than 640K; why pay more for a protected mode compiler if you aren't going to take advantage of its features? As a review of Fortran compilers, the _Computer_Language_ review should be taken with a large block of salt. Somewhat better are Al Cameron's reviews in _MIPS_ (now _Personal_Workstation_). Cameron is a working scientist and at least tested the compilers with more realistic code (including, in some cases, the SPH simulation code he uses in his research). The main problem I had with Cameron's reviews was that he didn't pay any attention to error trapping. I tried out SVS Fortran after reading his review; I returned it as unacceptable. Cameron's review had suggested that SVS could be up to a factor of two faster than NDP; the problem with the NDP compiler had been fixed in the meantime so that SVS runtimes were only a few percent faster than NDP. More importantly, SVS had no way to handle exceptions (at least at that time). I tried calculating 2./0. and got an answer of 0. with _no_ sign that anything was amiss. Similarly, sqrt(-3.) returned -3., with no hint that there was a problem. I just about gagged when I saw this. I have been using MicroWay's NDP Fortran since about 1987. The recent versions of NDP Fortran allow the user to install an error handler or to modify the 387 interrupt flags; debugging has become much easier. -- Terry Gaetz -- gaetz@uwovax.uwo.ca
dmg@ssc-vax (David M Geary) (06/15/91)
In article <1991Jun13.160602.23726@afit.af.mil> dlindsle@afit.af.mil (David T. Lindsley) writes: >From a design standpoint, you'd be better off with C++, I think. > >However, it does so by using the Phar Lap (memory management?) >software. We have had this here at AFIT for about six months; as far >as I know, we haven't even been able to get Watcom's demo programs >(supplied with the compiler) to work. (The people trying to get it >to work are electrical & computer engineers, FYI.) > >You need a compiler that will compile 386 code. As far as I know, >what these things basically do is raise an exception or some signal >which puts the CPU into (386) protected mode. Now you've got your >4GB segments, and the program can run. When it's done, the CPU goes >back into whatever mode it was in. > I have been involved for about 2 years writing a GUI which consumes quite a bit of memory at run time. I developed it under Unix, and all was rosy until I went to port to the PC ;-( After many headaches trying to deal with the brain-dead DOS architecture, we finally purchased PharLap's DOS Extender. It has worked like a charm. We have not fully ported to PC yet, but most of the technical problems we had have been solved by using PharLap's product. I highly recommend it. >Anyway, like I said, you need a compiler that "speaks 386". I like >Borland's compilers, but I'm not sure if they've got a 386 line. I >know Zortech does, though. Have you considered getting Unix for your >386? > Well, we used MS C 5.0 along with PharLap's DOS Extender and things have turned out well. We support many customers internal to Boeing, and it was not a feasible thing to have to tell our customers that they had to install Unix on their PCs to run our product. Check out PharLap's DOS Extender. It works. -- |~~~~~~~~~~ David Geary, Boeing Aerospace, Seattle, WA. ~~~~~~~~~~| |-----------------------------------------------------------------------------| |~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~| |-----------------------------------------------------------------------------|
mrs@netcom.COM (Morgan Schweers) (06/15/91)
Greetings, I hate to say something like this, but I seriously recommend that you dump the Borland *AND* Microsoft stuff, and go with GPP (Gnu++) available from grape.ecs.clarkson.edu:pub/msdos/djgpp... It swaps into flat-memory mode when executing the programs. It also supports virtual memory automatically. In effect, if you had the space, you could malloc(50*1024*1024)... dj@ctron.com (DJ Delorie) has done one hell of a good job porting GNU++... Pick it up and play with it! -- Morgan Schweers P.S. It only works on 386 equipped systems. Also pick up the patches, because they include floating-point handling. -- mrs@netcom.com | Morgan Schweers | Good code, good food, good sex. Is ms@gnu.ai.mit.edu| These messages | anything else important? -- Freela Kilroy Balore | are not the +-------------------------------------- Freela | opinion of anyone.| I *AM* an AI. I'm not real...
ndeng@dec-1.CE.Berkeley.EDU (Nan Deng) (06/16/91)
In article <23@interet.UUCP> iris@interet.UUCP (User) writes: >In article <1991Jun13.160602.23726@afit.af.mil> dlindsle@afit.af.mil (David T. Lindsley) writes: >>The only Fortran I know of that can use extended memory is Watcom's. >Several others do. We use Silicon Valley Software's FORTRAN and C and >are fairly pleased with their performance and quality. Others include >NDP, and Lahey. All of these use PharLap's extender. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Not necessarily. Lahey uses the OS/386 DOS extender instead of Phar Lap. > The extender can >be "bound" into the executable so that you end up with "YOURPROG.EXE". Only Lahey comes with the binder in the compiler/dos extender package. Although it is the most expensive in all compilers, it does have an unlimited runtime license. The others, like SVS and NDP using Phar Lap extender, will need to perchase a 1000 copy runtime license directly from Phar Lap in order to get the binder which costs $2,000, and you must fill out quarterly reports to the company to report how many copy you have used in the license. >========================================================================== >Iris Engelson uunet!iris@interet >Director of Software Development Tel: 201-763-1200 >Interet Fax: 201-763-5120 >111 Dunnell Road >Maplewood, NJ 07040 Nan Deng ndeng@ce.berkeley.edu
ragrawal@magnus.acs.ohio-state.edu (Rajiv Agrawal) (06/17/91)
In article <1991Jun16.045246.12825@agate.berkeley.edu> ndeng@dec-1.CE.Berkeley.EDU (Nan Deng) writes: >In article <23@interet.UUCP> iris@interet.UUCP (User) writes: >>In article <1991Jun13.160602.23726@afit.af.mil> dlindsle@afit.af.mil (David T. Lindsley) writes: >>>The only Fortran I know of that can use extended memory is Watcom's. >>Several others do. We use Silicon Valley Software's FORTRAN and C and >>are fairly pleased with their performance and quality. Others include >>NDP, and Lahey. All of these use PharLap's extender. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Not necessarily. Lahey uses the OS/386 DOS extender instead of Phar Lap. ^^^^^^^^^^^^^^^^^^^ Is this the same as the made by Ergo Software out in Boston? We have been using a product by them called OS/386 for quite some time with Microsoft FORTRAN 5.0. Works quite well. I think the street cost is about $595 and they charge about $10 for a binder (provided you sign some form). > >Only Lahey comes with the binder in the compiler/dos extender package. >Although it is the most expensive in all compilers, it does have an >unlimited runtime license. The others, like SVS and NDP using Phar Lap >extender, will need to perchase a 1000 copy runtime license directly from >Phar Lap in order to get the binder which costs $2,000, and you must fill >out quarterly reports to the company to report how many copy you have used >in the license. > Has anybody tried out the latest FORTRAN from Microsoft ie. V 5.1? It has some library to run program under Windows that can suck up all the extended memory. Rajiv.
BVAUGHAN@pucc.Princeton.EDU (Barbara Vaughan) (06/17/91)
In article <1991Jun17.053203.29029@magnus.acs.ohio-state.edu>, ragrawal@magnus.acs.ohio-state.edu (Rajiv Agrawal) writes: >In article <1991Jun16.045246.12825@agate.berkeley.edu> ndeng@dec-1.CE.Berkeley.EDU (Nan Deng) writes: >>In article <23@interet.UUCP> iris@interet.UUCP (User) writes: >>>In article <1991Jun13.160602.23726@afit.af.mil> dlindsle@afit.af.mil (David T. Lindsley) writes: >>> ... and Lahey. All of these use PharLap's extender. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>Not necessarily. Lahey uses the OS/386 DOS extender instead of Phar Lap. > >Is this the same as the made by Ergo Software out in Boston? ... Yes, it is. Barbara Vaughan
mstoer@sol.UVic.CA (Marcell Stoer) (06/17/91)
In article <1991Jun17.053203.29029@magnus.acs.ohio-state.edu> ragrawal@magnus.acs.ohio-state.edu (Rajiv Agrawal) writes: >Has anybody tried out the latest FORTRAN from Microsoft ie. V 5.1? It has >some library to run program under Windows that can suck up all the >extended memory. > Do you seriuously want to run under Windows? It's slow enough as is. I for one want fast execution. I use a 25MHz 386 with 387 and 4M of extended memory. Windows is still slow. I prefer WATCOM FORTRAN 77/386, I did have to buy a DOS extender (Pharlap's), but it was worth it. IT's fast, it comes with a great compiler package, ie debugger, profiler ... IT is also compatible with WATCOM C 386 so you can link applications. All WATCOM software uses the same compiler tools, which means that all you have is seperate compilers, include files and libraries, everything else is the same. I have used MS Fortran, never Lahey, but MS is definitely not in the league with these other compilers. That's usually the case though with MS software. just my 2 cents worth, -ms -- Marcell Stoer Internet : mstoer@sol.uvic.ca Department of Chemistry Molecular Beam Laser Spectrometry Laboratory Voice : (604) 721-8975 University of Victoria FAX : (604) 721-7147
joe@proto.com (Joe Huffman) (06/18/91)
You might want to consider Zortech C/C++ 3.0. It includes a royality free 32 bit 386 DOS extender that is DOS, VCPI, and DPMI (Windows 3.0) compliant. -- uunet!proto!joe joe@proto.com
bright@nazgul.UUCP (Walter Bright) (06/18/91)
/>>>The only Fortran I know of that can use extended memory is Watcom's. />Only Lahey comes with the binder in the compiler/dos extender package. />Although it is the most expensive in all compilers, it does have an />unlimited runtime license. Zortech's new version 3.0 of C and C++ comes with a royalty-free 286 DOS Extender and a 386 DOS Extender. With the 386 compiler and 386 extender, you can have arrays as large as available memory without resorting to 'huge' or 'far' memory models or keywords. You can commercially distribute applications built with it without obtaining a license or paying royalties to Zortech. I can email you more information if you are interested.
pcg@aber.ac.uk (Piercarlo Grandi) (06/20/91)
On 17 Jun 91 21:06:07 GMT, joe@proto.com (Joe Huffman) said: joe> You might want to consider Zortech C/C++ 3.0. It includes a joe> royality free 32 bit 386 DOS extender that is DOS, VCPI, and DPMI joe> (Windows 3.0) compliant. There is also the free GNU CC and GNU C++ compiler package for MSDOS that includes (with full sources) the compilers, various tools, and a virtual memory extender (GO32) that supports 32 bit addressing and paged virtual memory to disk under MSDOS. If you wanted you could probably easily port GNU Emacs under MSDOS using this compiler. The compiler is available on the GNUish MSDOS project servers, and is the result of the work of D.J. Delorie. There is another GCC implementation with a free extender by a Japanese researcher, but only a preliminary version has been made available. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
ndeng@dec-1.CE.Berkeley.EDU (Nan Deng) (06/20/91)
In article <346@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes: >/>>>The only Fortran I know of that can use extended memory is Watcom's. >/>Only Lahey comes with the binder in the compiler/dos extender package. >/>Although it is the most expensive in all compilers, it does have an >/>unlimited runtime license. > >Zortech's new version 3.0 of C and C++ comes with a royalty-free 286 >DOS Extender and a 386 DOS Extender. With the 386 compiler and 386 extender, >you can have arrays as large as available memory without resorting to >'huge' or 'far' memory models or keywords. You can commercially distribute >applications built with it without obtaining a license or paying >royalties to Zortech. I can email you more information if you are interested. Will Mr. Bright please post some information about the new Zortech compiler on the net? I tried to reach you directly through e-mail but my machine told me it does not connected to your machine.
louk@tslwat.UUCP (Lou Kates) (06/22/91)
> Well, we used MS C 5.0 along with PharLap's DOS Extender and > things have turned out well. We support many customers internal > to Boeing, and it was not a feasible thing to have to tell our > customers that they had to install Unix on their PCs to run our > product. > > Check out PharLap's DOS Extender. It works. >-- >|~~~~~~~~~~ David Geary, Boeing Aerospace, Seattle, WA. ~~~~~~~~~~| You could also look into Ergo's DOS extender. We use MS C and MS FORTRAN together with Ergo's DOS extender. With it you write two processes: a real mode process that contains DOS dependent stuff and a protected mode process that has everything else. You use remote procedure calls between the two which seems a rather clean way to do things. It uses the same API on both 286 and 386 processors. We have some large optimization programs that run under it. We did notice that by switching to a compiler that can generate 386 code (the MS compilers can only generate 286 code) that we could get quite a speed up. Lou Kates, Teleride Sage Ltd., louk%tslwat@watmath.waterloo.edu 519-725-0646