Xref: utzoo comp.sys.ibm.pc:41838 alt.msdos.programmer:1011
Path: utzoo!attcan!uunet!tank!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!caesar.cs.montana.edu!ogicse!decwrl!shelby!portia!dhinds
From: dhinds@portia.Stanford.EDU (David Hinds)
Newsgroups: comp.sys.ibm.pc,alt.msdos.programmer
Subject: Re: 386 instructions
Summary: Why is generating 386 code a big deal???
Message-ID: <8166@portia.Stanford.EDU>
Date: 12 Jan 90 03:18:33 GMT
References: <13346@garnet.BBN.COM> <580@watserv1.waterloo.edu> <6142@internal.Apple.COM>
Sender: David Hinds <dhinds@Portia.stanford.edu>
Followup-To: comp.sys.ibm.pc
Distribution: comp
Organization: Stanford University
Lines: 18


    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