Fix for 8 Mb memory limit

[Joe Kelsey]

There is a problem with the posted fix.  Simply modifying cmap.h and
changing the constant on the memory counting loop in the system startup
isn't quite enough.  The routine Fastreclaim at the end of locore.s has
various cmap constants wired into it:  namely the size of struct cmap
and the bit offsets of the fields c_intrans and c_free.  If you don't
fix these, you will start seeing random, seemingly arbitrary core dumps
on your system because the Fastreclaim loop is incorrectly marking text
pages as referenced or not.  Here is my fix:

/*	locore.s	6.3	83/08/12	*/
	.
	.
	.
/*
 * Extracted and unrolled most common case of pagein (hopefully):
 *	resident and not on free list (reclaim of page is purely
 *	for the purpose of simulating a reference bit)
 *
 * Built in constants:
 *	CLSIZE of 2, USRSTACK of 0x7ffff000, any bit fields
 *	in pte's or the core map
 */
	.text
	.globl	Fastreclaim
Fastreclaim:
	.
	.
	.
	subl2	_firstfree,r0
	ashl	$-1,r0,r0	
	incl	r0			# pgtocm(pte->pg_pfnum) 
#ifdef FLUKE
	/*
	 * changed size of cmap from 12 to 16 bytes to handle larger
	 * memories.
	 * 12-July-1984 jmk
	 */
	ashl	$4,r0,r0		# &cmap[pgtocm(pte->pg_pfnum)]
#else
	mull2	$12,r0
#endif FLUKE
	addl2	_cmap,r0		# &cmap[pgtocm(pte->pg_pfnum)] 
	tstl	r2
	jeql	2f			# if (type == CTEXT &&
#ifdef FLUKE
	/*
	 * rearranged fields within cmap for same reasons as above.
	 * 12-July-1984 jmk
	 */
/*	jbc	$0,12(r0),2f		#     c_intrans) */
	blbc	12(r0),2f		#     c_intrans)
#else
	jbc	$29,4(r0),2f		#     c_intrans)
#endif FLUKE
	POPR; rsb			# 	let pagein handle it
2:
#ifdef FLUKE
	/*
	 * ditto above
	 * 12-July-1984 jmk
	 */
	jbc	$1,12(r0),2f		# if (c_free)
#else
	jbc	$30,4(r0),2f		# if (c_free)
#endif FLUKE

It's nice that Fastreclaim is optimized, etc., but I wish there was
some way to symbolically refer to some of these constants.  Maybe I'll
add some #defines to cmap.h specifically for use in locore.s with some
comments in cmap.h and locore referring specifically to each other.
Note that I am assuming you are using the cmap.h structure posted by
Philib Bonesteele @ TRW.  norman at cithep also sent me a modified cmap.h
which has the fields rearranged differently.  Anyway, we've been
running on the above mods overnight and no random core dumps yet.  The
problem has always shown up very quickly in the past, so I feel
confident that I finally have the problem solved.  Now I can finally
use all 10 M bytes of memory!  Goodbye swapper!!!

/Joe