Date: Fri, 1 May 92 19:25:58 CDT
From: csaba AT vuse DOT vanderbilt DOT edu (Csaba A. Biegl)
To: ckgp!thomas AT uunet DOT uu DOT net
Subject: Re:  Mixing 1.05 and 1.06 (was re: 1.05 and 1.06)
Cc: djgpp%sun DOT soe DOT clarkson DOT edu AT RELAY DOT CS DOT NET
Status: O

Ever since 1.06 came out I have been using the 1.06 libraries, extender,
etc.. with the GCC 1.39 compiler from release 1.05. No problems whatsoever.
I keep the new executables in a separate directory and have a set of batch
files to change over to them by fixing up the path and the env vars.
Occasionally I recompile my programs with 2.1 just to test if there are
any differences. So far everything is OK. (Well, not quite: once I found
a code generation bug in 2.1 -- 1.39 generated proper code (-: )

I replaced the following files of the 1.06 distribution (all in the 'bin'
sub-dir) with their 1.05 counterparts:

gcc.exe
cc1.exe
cpp.exe
as.exe
ld.exe
ar.exe

Everything else is from the 1.06 distrib. Disclaimers:

(1)	This won't work for C++ (The C++ parts are REALLY different in 1.05
	and 1.06)
(2) I didn't test the emulator as I have a 387

DON'T:

(1) Use gcc.exe of 1.05 (the Turbo C version) with the compiler passes
	from 1.06.

(2) Mix passes from the two releases.


In my opinion the 2.1 GCC compiler is not that much slower as the 1.39
version. (I have done some benchmarks on UNIX boxes with both.) It may
be 100-200 kBytes bigger and 10 % slower but this does not account for
the performance loss we have all been observing. IMO the main
contributing factors are:

(1) GCC.EXE is a Turbo C program in 1.05 and it is a protected mode 32
	bit program in 1.06. As a 'system()' call swaps out the currently
	running 32-bit program under GO32, GCC.EXE will be swapped in and
	out three times during the compilation of a C file. Even in the 
	best case, when you have
	a clever disk cache and/or RAM disk and avoid writing the swap file
	to the disk, a significant amount of memory moving is necesssary. 

(2) The compiler driver of 1.06 does not recognize any of the documented
	environment variables for the location of the temporary files. Just
	do a 'gcc -v ..' and you will see that your temporary compiler files
	are named '/tmp/...'. 


Once I did an experiment on an 8MB machine when I used up big chunks of 
memory for a
disk cache and a RAM disk AND(!) I JOIN-ed the RAM disk under the \TMP
directory. Of course I also made sure that the swap file went to the RAM
disk. With BOTH of these modifications (emphasis: BOTH!!!) I got back to
the point where I was previously with 1.39: during a long 'make', after
the first few files the disk light was blinking only when the compiler
was writing out the '.o' files. The 'make' lasted about 25% longer than
with 1.39 -- which was kind of acceptable to me. BUT....
The price? I had to waste about 6 MBytes
for cache and RAM disk, while with the 1.39 compiler I can zip along
with a 1.5MB cache and a 0.5MB RAM disk (for the temp files) just fine.

What can be done?

(1)  Change GO32 not to swap out everything for a system() call. If it
	 is too dangerous for general purpose use, what about a special 
	 version of GO32 just for the compiler?

(2)  Fix GCC.EXE to recognize the temporary file path properly.

(3)  Alternatively to (1), build a Turbo C version of GCC.EXE. DJ wrote
	 some time ago that Mr. Stallman wished GCC.EXE to be compiled with
	 GCC itself. (I am just guessing, but it may have to do with FSF 
	 distribution policies.) But it should not prevent YOU from building
	 a GCC.EXE for yourself with TCC. (It is built from a single .c file
	 if I remember well -- and we can look at DJ's patches he had to do
	 when he ported the 1.39 compiler driver to TCC.) If nothing happens
	 with option (1) in the near future I am definitely going to do it!


Whatever it is worth...


-----------------------------------
Csaba Biegl
csaba AT vuse DOT vanderbilt DOT edu