Subject: Re: demand-loding etc Date: Mon, 18 Nov 1991 17:09:17 +1100 From: Bruce Evans <bde@runx.oz.au>
Linus:
>Re: sticky bits, shared text...
>I don't like sticky bits (in the meaning that they lock something into
>memory). I doubt it's really that useful on a small machine, that is
>essentially single-user. It's easy to grow the cache to 6M or more if
Shared text helps a lot with recursive commands. I'm surprised linux
doesn't already have it. Fork is most naturally done by sharing text and
making it copy-on-write or no-write.
>you have the memory, and currently I don't see much unnecessary disk I/O
>in a heavy 'make'. Besides - sticky bits are hard to keep track of.
The cache i/o that you don't see hurts (there should be a LED for it :).
Building the library under Minix-386-cached-text takes 25% longer when
the shell is bash. The overhead is actually for something else - copying
40K data from the cache and zeroing 200K bss. Under another version of
Minix with copy-on-access forks, building the library takes another 10%
longer. There is only slightly less copying because a lot of text gets
copied, and more overhead from page faults.
The other thing that hurts without cached text is that heavily-used programs
will be duplicated in the disk cache and as text. Perhaps mapping the disk
cache to text instead of copying it would be almost as good as managing
text separately.
[big program sizes]
>> The culprit here is the floating point library (i.e., the soft floats);
>> even if your program isn't using floats, printf() drags large portions
>Yes. The right way to do this is to add an floating-point emulator in
>the kernel, even if shared libraries are added. This is a real b**ch.
You would need a printf-emulator in the kernel :-(. The floating point
emulation itself shouldn't be that big.
>I'll probably take a look at the djgpp package, but I'd really rather do
>it myself (it's an interesting project). I don't really have the time
The djgpp emulator (in 32-bit C) is 14+ times slower than my library
routines (in 32-bit asm) (the emulator in Turbo C++ is only 7 times
slower :-). It takes a large amount of code to the emulation compared
with doing the guts of the library.
>John T Kohl <jtkohl@cs.berkeley.edu>
>> [486/33 bootup problem]
>This would suggest to me that you have one of those braindead "slowdown"
>devices which aren't really completely hardware, but due to some
>software solution. At least some Gateway-2000's had this, which meant
This doesn't explain why the slow mode worked to boot. Perhaps the fast
mode is done in software ;-). I guess the bug is really in the BIOS+linux
with a hot interrupt.
>nicholas@cs.uwa.oz.au (Nicholas Yue)
>> I then proceeded to write a small C program with a sin() and tan() call.
>>
>> device not available: 0000
>This should happen only on a 386-system with no 387. "dd 44..." is some
>math instruction (fld? whatever). However, linux depends on the BIOS to
>set the %cr0 bits for a coprocessor, and doesn't test for one itself, so
>even with 387 you might get this error if you BIOS doesn't set it up
>correctly.
The error seems normal. You are lucky to get it instead of a crash. My
1987 Award BIOS and 1990 AMI BIOS can be relied on to set up the %CR0 bits
_incorrectly_ (Award always clears them, on a machine without an x87).
After booting, AMI on my 486 has set %CR0 to 0x10. The relevant bits are
0x01: MP (Math Present): should be set (WRONG)
0x02: EM (Emulation): should be clear to use x87/486
this is what gives the device not available trap -
linux must be setting it
0x04: ET (Extension Type): should be set (always set by 486 h/w so BIOS
gets this one right :)
0x08: NE (Numeric Error): 486 s/w should use this to get error reporting
via exception 16 instead of the crufty IRQ 13
necessary for 286-386/287-387 systems
Perhaps Linus meant the coprocessor bits in the parameter RAM. These had
a reuputation for being unreliable for distinguishing between 287's and
no-coprocessor but I think they are OK for 387's.
Bruce