Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!ditsydh.syd.dit.CSIRO.AU!evans
From: evans@syd.dit.CSIRO.AU (Bruce.Evans)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: What disk caches work with djgcc?
Message-ID: <1991May19.140858.27613@syd.dit.CSIRO.AU>
Date: 19 May 91 14:08:58 GMT
Article-I.D.: syd.1991May19.140858.27613
References: <1502@balrog.ctron.com> <1991May17.113928.27055@syd.dit.CSIRO.AU> <1506@balrog.ctron.com>
Organization: CSIRO Division of Info Tech, Sydney, Australia
Lines: 29

In article <1506@balrog.ctron.com> dj@ctron.com writes:
>djgcc *is* compatible with himem.sys, as long as you have the XMS
>version of himem.sys, and tell smartdrive not to use all of the XMS
>memory!  You might have an old (pre-XMS) version of djgcc also.

I tried himem.sys again and found it does work, but only with the old
smartdrv.sys. The exact versions are

	himem.sys    2.04 from DOS     4.01 (not tried)
	himem.sys    2.60 from Windows 3.0  (works)
	smartdrv.sys 2.10 from DOS     4.01 (works)
	smartdrv.sys 3.03 from Windows 4.01 (doesn't work)
	
'device=\win\smartdrv.sys 3072 1024' makes 7168K extended memory invisible to
djgpp though it only gives a 3072K cache. DOS's mem command reports 7168K is
in use. However, td386 (Turbo debugger) uses the missing memory.

hyperdisk with himem 2.60 leaves plenty of extended memory for djgpp too.
However, it did not work when I tried it last week - maybe the order of
installation of the drivers is important.

With smartdrv, the write-through cache resulted in a lot of sluggish disk
activity from djgpp. This is easy to fix for small compiles by using a RAM
isk for gcctmp. However, for large compiles (and large 32-bit programs), at
best the RAM disk will use memory better given to the program. At worse
the program will swap to the RAM disk (duh). This seems to always happen
now. Am I messing some swaptmp variable in TFM?
-- 
Bruce Evans		evans@syd.dit.csiro.au