pc532@bungi.com (pc532@bungi.com) (08/15/90)
GatorMail-Q Minix Especially if you have 8 MB memory, I suggest that you increase the size of the disk cache in the Minix kernel (NR_BUFS in fs/const.h). I changed the size to 2048 and the speed of compilation when making a Makefile increased drastically. With a small cache most of the time in a compilation was spent in reading the compiler and the like into memory. When the cache is large enough the compilation times are comparable to a sparc or similar. On the other hand it makes it more important to say sync before halting. It probably is a good idea to increase the size of the related hash table (NR_BUF_HASH (I use 1024)). 256 (NR_BUFS) and 128 seemed reasonable with 4MBs. Some other numbers I increased without problems: - number of processes (16 -> 128) NR_PROCS in h/const.h - number of superblocks (5 -> 32) NR_SUPERS in fs/const.h It is funny how most of the numbers seem somewhat underdimensioned when there are 8 MBs of memory, 1.4GB of disk, and around 10 MIPS in a Minix system :-), as we had at one time. Johannes ------------------ RFC822 Header Follows ------------------ Received: by mctgate.mct.anl.gov; 14 Aug 90 23:06:47 Received: from daver.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA05845; Wed, 15 Aug 90 00:00:34 -0400 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0i2E9R-00009Aa@daver.bungi.com>; Tue, 14 Aug 90 20:10 PDT X-Path: robin.hut.fi!jvh From: jvh@robin.hut.fi To: pc532@bungi.com Subject: Minix Date: Wed, 15 Aug 90 05:46:54 +0259 Message-Id: <9008150247.AA10799@robin.hut.fi> Reply-To: pc532@bungi.com Precedence: bulk
pc532@bungi.com (pc532@bungi.com) (09/18/90)
GatorMail-Q Running without an FPU I've had to struggle a bit, but I've managed to get MINIX up on my pc532 without an FPU. Some of the problems I encountered are: * The ROM needed a fix to get RUN and STEP to work. * MINIX saves FPU registers on a task switch * _begsig also saves FPU registers, causing any process which intercepts signals to dump core. * GCC uses floating point operations in global-alloc.c So far I've been able to fix these problems in an ad-hoc manner, but I'd like to co-ordinate efforts with other FPU-less pc532 owners (if there are any). I have several questions for the NS32K wizards out there: 1) Is there some way to reliably detect the physical presence or absence of an FPU? 2) Is there any way a user process can read the state of the F bit in the CFG register, given that SPRi CFG,Rn is a privileged instruction? 3) Are there any free (or nearly so) floating point emulation libraries for the NS32000 series? 4) Are there other traps I haven't stumbled into yet? -bert ------------------ RFC822 Header Follows ------------------ Received: by mctgate.mct.anl.gov; 17 Sep 90 20:24:14 Received: from daver.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA20781; Mon, 17 Sep 90 21:16:24 -0400 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0iEWPn-0000A9a@daver.bungi.com>; Mon, 17 Sep 90 18:06 PDT X-Path: Shiva.COM!bert From: Robert D. Vincent <bert@Shiva.COM> To: pc532@bungi.com Subject: Running without an FPU Date: Mon, 17 Sep 90 19:17:16 EST Message-Id: <9009180017.AA19520@Shiva.COM> Reply-To: pc532@bungi.com Precedence: bulk