d88-eli@nada.kth.se (Erik Liljencrantz) (08/31/89)
When computers are advertised with 1 Mb of RAM you always has to ask
what the not-for-DOS 384Kb are used for. Some computers has shadow RAM,
other turn the extra kilobytes into extended memory, while some 286
motherboards have logic to turn them into 384Kb expanded memory.
However, in my new Compaq Deskpro 386/20e (no, I didn't spend the money,
my boss did...) the 384Kb are divided into two parts:
128 Kb Compaq reserved memory
256 Kb additional memory
The 128Kb is possibly used for shadowing the BIOS, that's OK. The 256Kb can
be accessed by CEMM (and turned into expanded memory) but I can't use it
as extended memory. The manual mentions that the 256Kb's are mapped just
below the 16Mb boundary (and not just above the 1Mb boundary where I would
like them to be). CEMM is a memory hog. It consumes 33Kb conventional memory
and gives me 256Kb EMS memory. It also degrades the performance of the
CPU (from 33Mhz to 31Mhz according to Landmark).
Well, to my questions:
Can I turn those 256Kb into normal extended memory?
What happens if I take out the 1Mb memory module and inserts a 4Mb module?
Any experiences with Turbo Debugger on this machine? (I mean TD386...)
Do you have the answers? Or more questions? Happy to hear from you!
Preferably by email, if not of general interest...
Erik Liljencrantz
d88-eli@nada.kth.seralf@b.gp.cs.cmu.edu (Ralf Brown) (09/01/89)
In article <1538@draken.nada.kth.se> d88-eli@nada.kth.se (Erik Liljencrantz) writes: }like them to be). CEMM is a memory hog. It consumes 33Kb conventional memory }and gives me 256Kb EMS memory. It also degrades the performance of the }CPU (from 33Mhz to 31Mhz according to Landmark). Not surprising, since you have to turn on Virtual-86 mode to be able to emulate EMS on the 386, which means that *every* memory access has to go through the on-chip memory managment unit, which it doesn't have to do in real mode. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/46 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? |"Humor is laughing at what you haven't got when you ought to What's that?| have it." -- Langston Hughes
Devin_E_Ben-Hur@cup.portal.com (09/03/89)
> In article <1538@draken.nada.kth.se> d88-eli@nada.kth.se (Erik Liljencrantz) wr > ites: > }like them to be). CEMM is a memory hog. It consumes 33Kb conventional memory > }and gives me 256Kb EMS memory. It also degrades the performance of the > }CPU (from 33Mhz to 31Mhz according to Landmark). > > Not surprising, since you have to turn on Virtual-86 mode to be able to > emulate EMS on the 386, which means that *every* memory access has to go > through the on-chip memory managment unit, which it doesn't have to do in rea l > mode. > > -- > {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/4 6 Not quite. In virtual mode, every segment-register load takes extra cycles for memory management, but normal memory accesses occur at the same speed as real mode. Far calls, interrupts, POP <seg>, far returns, MOV <seg>, and LxS instructions run much slower in virtual mode than real mode, but most other instruction timings are unaffected. This means stupid large-model C code gets hurt far worse than small model or good asm programs. Devin_Ben-Hur@Cup.Portal.Com ...ucbvax!sun!portal!cup.portal.com!devin_ben-hur
johnl@esegue.segue.boston.ma.us (John R. Levine) (09/04/89)
In article <21803@cup.portal.com> Devin_E_Ben-Hur@cup.portal.com writes: >> In article <1538@draken.nada.kth.se> d88-eli@nada.kth.se (Erik Liljencrantz) >wr >> ites: >>> [CEMM] degrades the performance of the CPU (from 33Mhz to 31Mhz >>> according to Landmark). >> Not surprising, since you have to turn on Virtual-86 mode to be able to >> emulate EMS on the 386, which means that *every* memory access has to go >> through the on-chip memory managment unit, which it doesn't have to do in >> real mode. >Not quite. In virtual mode, every segment-register load takes extra cycles >for memory management, but normal memory accesses occur at the same speed >as real mode. ... It appears to be a combination of both. Virtual memory mapping takes no extra time so long as the mapped addresses are in the paging cache. Every paging cache miss causes two memory reads from the two-level page tables. You'd think that in virtual-86 mode segment register loads should be as fast as they are in real mode, since it is doing none of the descriptor table manipulation that it has to do in regular virtual mode, but as far as I can tell from reading the 386 Programmer's Reference, segment loads in virtual 86 mode run at the same speed as in protected mode. I suppose we're supposed to be grateful to have virtual 86 mode at all. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 {ima|lotus}!esegue!johnl, johnl@ima.isc.com, Levine@YALE.something Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
philba@microsoft.UUCP (Phil Barrett) (09/06/89)
In article <1989Sep3.175859.5068@esegue.segue.boston.ma.us> johnl@esegue.segue.boston.ma.us (John R. Levine) writes: > >You'd think that in virtual-86 mode segment register loads should be as fast >as they are in real mode, since it is doing none of the descriptor table >manipulation that it has to do in regular virtual mode, but as far as I can >tell from reading the 386 Programmer's Reference, segment loads in virtual >86 mode run at the same speed as in protected mode. I suppose we're >supposed to be grateful to have virtual 86 mode at all. Thats odd, my 386 PRM says that real address mode and virtual 8086 mode are the same in clock counts (2 for reg to seg reg move, 5 for memory to seg reg move). The book also says Protected Virtual Address Mode takes 18 clocks for reg to seg reg and 19 for mem to seg reg move. Note that Prot. Virt Addr mode is NOT V86 mode. This is on page E-2 of the Intel book. Note: I have the book dated 1986, order number 230985.001 which means its the first rev so maybe intel changed the spec. Most likely, the overhead of LIMulators like CEMM, 386Max and QEMM are due to paging being enabled (TLB misses/flushes), i/o overhead and GP fault overhead. Phil `the above opinions are my own' Barrett Microsoft Corp.