Pre-fetch

[Stanley Friesen]

In article <891 at bunker.UUCP> reno at bunker.UUCP (Jim Reno) writes:
>We ran into an interesting problem here that I haven't seen mentioned
>anywhere previously.
>
>The kernel happens to relocate some parts of itself during initialization.
>It turned out that a routine for a driver was being relocated to the
>absolute end of physical memory, such that the last two bytes of
>memory contained an RTS (return from subroutine). When this
>instruction was executed the fault occurred because the 68K prefetches
>2 to 4 bytes ahead of where it's executing. The prefetch was into
>nonexistent memory, hence the external logic produced the fault.
>This is a classic problem with pipelined systems.
>
>However, the problem exists for user-mode programs as well. Suppose
>you have a shared text program where the code is exactly some multiple
>of the basic block size used by the MMU (1k on our system). Further
>suppose that your kernel allocates exactly that amount of memory.
>If the processor prefetches, the MMU will fault (and the
>program dump core) when the very last instruction is executed.
>The MMU, of course, has no way of knowing that the processor would
>never have actually used those bytes.
>
>There are a number of solutions. The loader could always pad shared text
>images by a few bytes. Perhaps a better solution is to have the exec
>code in the kernel check to see if the shared text segment is exactly a
>multiple of the MMU block size, and allocate an extra block.

	Actually, I think a better solution would be to patch the
kernel to check if the fault occured on the last byte of memory and
simply *ignore* it the first time! This would avoid having to do
strange things to user programs to make them work. After all it is
the kernel which translates the fault into a signal.
-- 

				Sarima (Stanley Friesen)

{trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen
or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen