hlison@bbn.com (Herb Lison) (01/12/90)
Does anyone know if there are any compiler options with MSC5.1 which let the compiler generate 386 specific instructions where appropriate. The documentation I have only shows the /G2 option for generating 286 code. Specifically, it would be nice to take advantage of 32 integer multiplies and shifts, or is this something the compiler does automatically? Thanks, Herb Lison
kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (01/12/90)
In article <13346@garnet.BBN.COM> hlison@bbn.com (Herb Lison) writes: >Does anyone know if there are any compiler options with MSC5.1 which >let the compiler generate 386 specific instructions where appropriate. >The documentation I have only shows the /G2 option for generating >286 code. Specifically, it would be nice to take advantage of >32 integer multiplies and shifts, or is this something the compiler >does automatically? MSC 5.1 will not generate 386 instructions under any circumstances, not automatically, not today, not tomorrow, not next year, not ever. MASM 5.1 will generate some of the 386 instructions, but not all. You have to get somebodies (Phar Lap is an example) 386 compiler and DOS extender. Chewey, get us outta here! kaleb@mars.jpl.nasa.gov (818)354-8771 Kaleb Keithley
batman@watsci.uwaterloo.ca (Marcell Stoer) (01/12/90)
In article <13346@garnet.BBN.COM> hlison@bbn.com (Herb Lison) writes: >Does anyone know if there are any compiler options with MSC5.1 which >let the compiler generate 386 specific instructions where appropriate. >The documentation I have only shows the /G2 option for generating >286 code. Specifically, it would be nice to take advantage of >32 integer multiplies and shifts, or is this something the compiler >does automatically? > >Thanks, > >Herb Lison If you want to issue 386 instructions, you will need a compiler that generates 32 bit code. Microsoft has no such compiler. There are companies that provide these though. One is WATCOM ( presently the best C compiler around, refer to BYTE, PC Magazin, INFO World...etc), another is Metaware. These compilers generate 386 (32 bit) specific code that can make use of all the memory your machine has (passed the 640K limit of DOS). To run the executables you will also need a DOS-Extender that can switch your 386 to protected mode in order to make use of the 32 bit utilities. Phar Lap has a good DOS-Extender. These 386 compilers generally cost around $650-900 (think twice) and the DOS-Extender is $495 (when I bought it 2 months ago). If anyone is interested for more info on WATCOM you can e-mail me and I'll pass the info along. -- Marcell BITNET : Batman@Watsci.uwaterloo.ca ===============================================================================
henry@Apple.COM (Peter Henry) (01/12/90)
In article <580@watserv1.waterloo.edu> batman@watsci.UUCP (Marcell Stoer) writes: >If you want to issue 386 instructions, you will need a compiler that >generates 32 bit code. Microsoft has no such compiler. There are companies ... >Phar Lap has a good DOS-Extender. These 386 compilers generally cost around >$650-900 (think twice) and the DOS-Extender is $495 (when I bought it 2 months >ago).> Great! for the price of the compiler and extender, you could just buy UNIX for the 386 (with all the trimmings), get a real 32-bit environment, with compiler (and/or use GCC), and still have money left over... These UNIXes will even support DOSMERGE-style apps that let you run MSDOS programs. Seems to me, if you're willing to spend that kind of money to develop software that won't even run under MSDOS (without the extender), what are you doing running MSDOS as your primary OS in the first place? Get UNIX, and spawn DOS for your word processing/games/spreadsheet etc. (until good ones are written for UNIX)! -Peter Henry (peter@nucleus.apple.com)
dhinds@portia.Stanford.EDU (David Hinds) (01/12/90)
On a tangent to the previous articles in the series, why are these DOS extenders and things needed anyway??? Almost all of the 386-specific instructions can be executed by the processor in real mode (i.e., under DOS) without any contortions. The only ones requiring protected mode are the funny ones for playing with memory management and task switching. Any DOS program can use the 386's 32-bit registers, extended arithmetic, and new addressing modes. Any DOS program can simply use 32-bit addresses to access extended memory. Borland's Turbo Assembler will let you put 32-bit code in the middle of anything you want. So why aren't compilers available for higher languages that do this? It wouldn't be much work to just have a separate 386-specific version of a compiler's run-time library, but even this would be a big speed boost for math-intensive programs. For a single task, the 386 can run 32-bit code just as well under DOS in real mode, as it can under UNIX, OS/2, or a DOS extender in protected mode. -David Hinds dhinds@portia.stanford.edu
louk@tslwat.UUCP (Lou Kates) (01/12/90)
In article <580@watserv1.waterloo.edu> batman@watsci.UUCP (Marcell Stoer) writes: >In article <13346@garnet.BBN.COM> hlison@bbn.com (Herb Lison) writes: >>Does anyone know if there are any compiler options with MSC5.1 which >>let the compiler generate 386 specific instructions where appropriate. >>The documentation I have only shows the /G2 option for generating >>286 code. Specifically, it would be nice to take advantage of One reply mentions that Microsoft C does not generate 386 code but that Watcom and Metaware can and that these can allow you to pass the 640K limit. Its true that you can't generate 386 code on Microsoft C but if the problem is that you need to exceed the 640K limit then you could use the 286 code option and run the result under the Eclipse OS/286 DOS extender which will allow you to run Microsoft C programs up to 16 MB large on a 286 or 386. If you are using a 386 then you will likely want their 386 version OS/386 which will also allow you to run 286 generated code from Microsoft C. Lou Kates, ...!watmath!looking!tslwat!louk, 519-725-0277
bcw@rti.UUCP (Bruce Wright) (01/13/90)
In article <580@watserv1.waterloo.edu>, batman@watsci.uwaterloo.ca (Marcell Stoer) writes: > If you want to issue 386 instructions, you will need a [C] compiler that > generates 32 bit code. Microsoft has no such compiler. Maybe you meant to say that Microsoft has no such compiler at a reasonable price. They most certainly *do* have a 32-bit version of their C compiler - it comes with their OS/2 V2.0 development kit (just shipping in the last month). I haven't seen it, not doing OS/2 development, and it's rather expensive (the whole development kit costs $2600, counting documentation, compiler, developer's tools, etc). It's basically the same sort of deal as their earlier SDK's - a premium price to get an early look at the new version of OS/2. But it probably isn't ready for prime time yet. Bruce C. Wright
norsk@sequent.UUCP (Doug Thompson) (01/13/90)
In article <13346@garnet.BBN.COM> hlison@bbn.com (Herb Lison) writes: >Does anyone know if there are any compiler options with MSC5.1 which >let the compiler generate 386 specific instructions where appropriate. >The documentation I have only shows the /G2 option for generating >286 code. Specifically, it would be nice to take advantage of >32 integer multiplies and shifts, or is this something the compiler >does automatically? > >Thanks, > >Herb Lison MSC 5.1 DOES NOT generate 386 32-bit instructions. -- Douglas Thompson UUCP: ..{tektronix,ogicse,uunet}!sequent!norsk Sequent Computer Systems Phone: (503) 526-5727 15450 SW Koll Parkway !"The scientist builds to learn;the engineer learns in Beaverton OR 97006 !order to build." Fred Brooks
fredb@llama.rtech.UUCP (Fred Buechler) (01/13/90)
In article <13346@garnet.BBN.COM> hlison@bbn.com (Herb Lison) writes: >Does anyone know if there are any compiler options with MSC5.1 which >let the compiler generate 386 specific instructions where appropriate. I just read in a recent (1/8/90) Infoworld that Microsoft is now shipping the OS/2 2.0 Software Developers Kit. Included in the kit are 32 bit versions of MSC 5.1 and MASM 5.1 with a 32 bit debugger. The 2.0 release of OS/2 contains 32 bit code and will only run on 32 bit (386/486) systems. Fred.
kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (01/13/90)
In article <3416@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes: >In article <580@watserv1.waterloo.edu>, batman@watsci.uwaterloo.ca (Marcell Stoer) writes: >> If you want to issue 386 instructions, you will need a [C] compiler that >> generates 32 bit code. Microsoft has no such compiler. > >Maybe you meant to say that Microsoft has no such compiler at a reasonable >price. They most certainly *do* have a 32-bit version of their C compiler - >it comes with their OS/2 V2.0 development kit (just shipping in the last >month). I haven't seen it, not doing OS/2 development, and it's rather >expensive (the whole development kit costs $2600, counting documentation, >compiler, developer's tools, etc). > Which means that they (Microsoft) doesn't have it. Specifically, I can't run down to Egghead or Software Etc and pick up a copy. Not only that, but this might imply that you have to run the compiler under OS/2, which not every has, or wants, especially if you are developing for the DOS environment... Chewey, get us outta here! kaleb@mars.jpl.nasa.gov (818)354-8771 Kaleb Keithley
zmact61@tsun6.doc.ic.ac.uk.doc.ic.ac.uk (D Spinellis) (01/16/90)
In article <8166@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: > On a tangent to the previous articles in the series, why are these DOS >extenders and things needed anyway??? Almost all of the 386-specific >instructions can be executed by the processor in real mode (i.e., under DOS) >without any contortions. [...] >Any DOS program can simply use 32-bit addresses to access >extended memory. Sorry, but the above is not exactly correct. It is true that most of the 386 instructions can be used in the real mode, but the segment limit is still limited to 64K. That is the base address (the one that is added to the segment) even when using 32 bit operands must be less than 65535. If it is more an exception will occur. Because of this you miss the linear addressing feature of the 386. In order to increase the segment limit you have to go to protected mode. Try the following program to convince yourself: mov ebx,010000h ; This is more than the segment limit mov al, [ebx] ; You should get an exception in real ; mode at this point. Diomidis -- Diomidis Spinellis Internet: dds@cc.ic.ac.uk Department of Computing BITNET: dds@cc.ic.ac.uk Imperial College UUCP: ...!cernvax!cc.imperial.ac.uk!dds London SW7 2BZ JANET: dds@uk.ac.ic.cc
torb@idt.unit.no (Tor Brekke) (01/17/90)
In article <1451@gould.doc.ic.ac.uk> dds@cc.ic.ac.uk (Diomidis Spinellis) writes: >Sorry, but the above is not exactly correct. It is true that most of the >386 instructions can be used in the real mode, but the segment limit is >still limited to 64K. ^^^ Sorry, byt this is not correct either. It is possible to trick the 386 into beliving that it's segments are larger than 64K in real mode. It involves a trip into protected mode though. If a descriptor i set up with a limit larger than 64K and left in one of the segment registers when reentering real mode, the processor will still believe that the segment has the old size. I have not done this myself, but a friend of mine has and it worked fine. Tor Brekke Email : torb@idt.unit.no
zmact61@tsun6.doc.ic.ac.uk.doc.ic.ac.uk (D Spinellis) (01/18/90)
In article <1990Jan17.102756.8171@idt.unit.no> torb@grimne.UUCP (Tor Brekke) writes: >In article <1451@gould.doc.ic.ac.uk> dds@cc.ic.ac.uk (Diomidis Spinellis) writes: >>Sorry, but the above is not exactly correct. It is true that most of the >>386 instructions can be used in the real mode, but the segment limit is >>still limited to 64K. > >Sorry, byt this is not correct either. It is possible to trick the 386 >into beliving that it's segments are larger than 64K in real mode. [...] >If a descriptor i set up >with a limit larger than 64K and left in one of the segment registers >when reentering real mode, the processor will still believe that the >segment has the old size. Is this a bug of the 386 or a documented feature? I have not found any mention of it in the Intel literature. It sounds very useful, but if it is undocumented it might go away in new chip releases. Diomidis -- Diomidis Spinellis Internet: dds@cc.ic.ac.uk Department of Computing BITNET: dds@cc.ic.ac.uk Imperial College UUCP: ...!cernvax!cc.imperial.ac.uk!dds London SW7 2BZ JANET: dds@uk.ac.ic.cc
torb@idt.unit.no (Tor Brekke) (01/18/90)
In article <1452@gould.doc.ic.ac.uk> zmact61@doc.ic.ac.uk (D Spinellis) writes: >In article <1990Jan17.102756.8171@idt.unit.no> torb@grimne.UUCP (Tor Brekke) writes: >>If a descriptor i set up >>with a limit larger than 64K and left in one of the segment registers >>when reentering real mode, the processor will still believe that the >>segment has the old size. > >Is this a bug of the 386 or a documented feature? I have never seen it it documented, but one might get a hint that it is possible in section 14.5 of "80386 Programmer's Reference Manual" where switching to real-address mode is described. It says that all segment registers must be loaded with a descriptor to a segment of size 64KB *before* entering real mode. This is bound to make people try other sizes :-) Tor Brekke Email: torb@idt.unit.no