Frank Breure <breure%ITIHP1.TNO.NL@pucc.princeton.edu> (04/30/91)
Hello, last weeks, a few people mentioned that you could easily increase the number of cache buffers on the 68K version. IMHO this is true WITH RESTRICTIONS, because the ACK - compiler uses 16bit the maximum size of an array is 64k. If you want more cache buffers than 62 (one cache buffer is bigger than 1k because it's hold in a struct with some other information about the buffer status). Anytime I try to boot a kernel with NR_CACHE_BUFS > 62 it hangs in the startup, on an ST (running Minix 1.5.10.3) this means that the screen will remain white. The solution to this can be to use a 32 bit integer compiler (I intend to try this but I'm not very sure this can be done without any modifications to the sources) QUESTION: Did anybode write some routines for the lib68k to make 'printf()' able to print float's ? As far as I know at least two (assembly) routines have to be rewritten, I tried to do it last weekend, but my knowledge of floating point was to minimal to handle this. Thanx -- Frank Breure (breure@itihp1.tno.nl) Instituut voor Toegepaste Informatica-TNO Delft, The Netherlands ---------------------------------------------------------------------- My opinions may be subject to change without notice.
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (04/30/91)
I am pretty sure that your message is pure garbage. There is no 64K limit on arrays with the ACK compiler, and the restriction on 16-bit ints does not impose this. All pointer calculations are done in 16 bit. Besides, I normally use about 150 Block buffers in my 68K MINIX, no problem. C.v.W.
ralf@ptavv.ka.sub.org (Ralf Wenk) (05/01/91)
In article <52171@nigel.ee.udel.edu> Frank Breure <breure%ITIHP1.TNO.NL@pucc.princeton.edu> writes: > last weeks, a few people mentioned that you could easily increase > the number of cache buffers on the 68K version. > IMHO this is true WITH RESTRICTIONS, because the ACK - compiler > uses 16bit the maximum size of an array is 64k. > If you want more cache buffers than 62 (one cache buffer is bigger > than 1k because it's hold in a struct with some other information > about the buffer status). > > Anytime I try to boot a kernel with NR_CACHE_BUFS > 62 it hangs in > the startup, on an ST (running Minix 1.5.10.3) this means that the > screen will remain white. > > The solution to this can be to use a 32 bit integer compiler > (I intend to try this but I'm not very sure this can be done without > any modifications to the sources) That is not the real solution for that problem. I use a 68K version with NR_BUFS == 110 and this version is compiled with the normal ACK. The system crashed with different problems until Bruce Evans noted that ldaddr in sys/tools/boot.s must be increased to be able to boot which such a big cache. Since then the system runs fine. -- -- Ralf Wenk -- ralf@ptavv.ka.sub.org
breure%ITIHP1.TNO.NL@pucc.princeton.edu (Frank Breure) (05/01/91)
> Hello, > > last weeks, a few people mentioned that you could easily increase > the number of cache buffers on the 68K version. > IMHO this is true WITH RESTRICTIONS, because the ACK - compiler > uses 16bit the maximum size of an array is 64k. > If you want more cache buffers than 62 (one cache buffer is bigger > than 1k because it's hold in a struct with some other information > about the buffer status). Sorry, sorry.. I'm WRONG about this, yesterday I wrote a small test program and it is possible to have arrays above 68k size, should have than this before posting BUT: > Anytime I try to boot a kernel with NR_CACHE_BUFS > 62 it hangs in > the startup, on an ST (running Minix 1.5.10.3) this means that the > screen will remain white. This is still true! I first had the origal NR_CACHE_BUFS (I guess it was 32), if I increase that above 62 I still can't boot, but if I make it 62 (with the hash_buf_size 64) I have no problems. I don't use a Ramdisk, and my boot device is on /dev/hd3, and I boot from floppy (/dev/fd0), if I have more than 62 cache-bufs the floppy drive will do a few seeks, and after that it remains turning without anything happening (no messages on the screen). Did anybody else have this problem ? and what are possible solutions ? Thanks -- Frank Breure (breure@itihp1.tno.nl) Instituut voor Toegepaste Informatica-TNO Delft, The Netherlands ---------------------------------------------------------------------- My opinions may be subject to change without notice. -- Frank Breure (breure@itihp1.tno.nl) Instituut voor Toegepaste Informatica-TNO Delft, The Netherlands ---------------------------------------------------------------------- My opinions may be subject to change without notice.
david@doe.utoronto.ca (David Megginson) (05/02/91)
In <52228@nigel.ee.udel.edu>, Christoph van Wuellen writes: > I am pretty sure that your message is pure garbage. > There is no 64K limit on arrays with the ACK compiler, and the restriction > on 16-bit ints does not impose this. All pointer calculations are done > in 16 bit. > > Besides, I normally use about 150 Block buffers in my 68K MINIX, no problem. > > C.v.W. I don't know about his reasons, but I have tried building a kernel with the Minix 386 buffer sizes on my ST, with ack, c68 and gcc. With the buffers that large, all three failed to boot. As soon as I put the buffers back to normal, everything was fine (I did a make clean in both cases first, just to be safe). -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
klamer@mi.eltn.utwente.nl (Klamer Schutte) (05/02/91)
In <52171@nigel.ee.udel.edu> breure%ITIHP1.TNO.NL@pucc.princeton.edu (Frank Breure) writes:
->Hello,
->last weeks, a few people mentioned that you could easily increase
->the number of cache buffers on the 68K version.
->IMHO this is true WITH RESTRICTIONS, because the ACK - compiler
->uses 16bit the maximum size of an array is 64k.
->If you want more cache buffers than 62 (one cache buffer is bigger
->than 1k because it's hold in a struct with some other information
->about the buffer status).
->Anytime I try to boot a kernel with NR_CACHE_BUFS > 62 it hangs in
->the startup, on an ST (running Minix 1.5.10.3) this means that the
->screen will remain white.
What you have to do is:
1) increase the hash size together with NR_CACHE_BUFS
2) be sure that the pointer arithmetic is done with longs. If you do that
the compiler will also do all in longs.
Klamer
--
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamerHBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (05/02/91)
You have perhaps read it already: the 'big buffer cache' problem originates in your boot preocedure.. Perhaps I should apologize, since I am running that system on a home -made 68K box, and of course, the boot procedure is different (but that is the only difference) C.v.W>
be@arium.stgt.sub.org (Bernd Ebach) (05/04/91)
In article <1991May1.182450.326@doe.utoronto.ca> david@doe.utoronto.ca (David Megginson) writes: > I don't know about his reasons, but I have tried building a kernel with > the Minix 386 buffer sizes on my ST, with ack, c68 and gcc. With the > buffers that large, all three failed to boot. Have you changed the LoadAdress in boot.s? At the moment I use a cache of 512 Blocks, 1024 Hashtable. Everything works fine... TschauTschau Bernd -- --------------------------------------------------------------- be@arium.stgt.sub.org | be@aragon.gtc.de | ud01@kauni2.bitnet ---------------------------------------------------------------