Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!rutgers!umn-d-ub!umn-cs!herndon
From: herndon@umn-cs.CS.UMN.EDU (Robert Herndon)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Summary: More self-modifying codes
Message-ID: <16454@umn-cs.CS.UMN.EDU>
Date: 20 Oct 89 15:15:14 GMT
References: <1080@mipos3.intel.com> <6481@pt.cs.cmu.edu>
Organization: University of Minnesota, Minneapolis
Lines: 40


Another very common use for self-modifying codes that I have not
seen mentioned at all is bootstraps.  These are typically a block
of code copied into low/high memory at start-up time.  On most
machines, excepting the many workstations and micros that have
the bootstrap in ROM, the bootstrap is usually loaded where the
operating system is eventually supposed to go.

  The bootstrap, then, is usually forced to copy itself elsewhere
before reading in the operating system.  Since it typically doesn't
know how big memory is, it often opts to use heuristics to find out,
then copies itself to high/low memory, relocating itself in the process.
[No pun intended.]  If the machine supports position-independent-code,
this is an ideal place to use it.  If it doesn't, one has to diddle
instructions.  Either way, the bootstrap has to know enough about
itself to move itself somewhere and resume execution there (like
some of the 'core-wars' creatures described in Scientific American).
The PDP-11 block 0 bootstrap worked this way with position
independent code.  Since the PDP-11 supported position independent
code, it didn't have to diddle instructions.  It was easy, however,
to forget to strip the header (8 words) off.  The original UNIX
"magic number" is a tribute to this fact -- a 407 instruction
[the original magic number] would jump over the header, and the
bootstrap was off and running in spite of your omission.

  Another option, seen on some machines with instruction caches,
is to read the whole operating system into memory at some location
not overlapping the bootstrap.  At this point, all that has to
be done is to move the OS to the right location in memory and
jump to its start location.  The code to do this is typically
only a few instructions, and can be fit into a/the instruction
cache.

				Robert Herndon
				herndon@umn-cs.cs.umn.edu
-- 
Robert Herndon				Dept. of Computer Science,
...!ihnp4!umn-cs!herndon		Univ. of Minnesota,
herndon@umn-cs.ARPA			136 Lind Hall, 207 Church St. SE
herndon.umn-cs@csnet-relay.ARPA		Minneapolis, MN  55455