Difference between revisions of "Base and bounds"

From Computer History Wiki
Jump to: navigation, search
m (Mention second park of name)
m (avoid redir)
Line 5: Line 5:
 
What ''was'' visible to the user was whether the address space visible to the program started at 0, or at the actual physical address of the memory assigned to that user. Doing the latter simplified programming, but required an [[adder]] in the path of addresses, which potentially had a performance impact (unless the delay caused could be overlapped with some other necessary operation).
 
What ''was'' visible to the user was whether the address space visible to the program started at 0, or at the actual physical address of the memory assigned to that user. Doing the latter simplified programming, but required an [[adder]] in the path of addresses, which potentially had a performance impact (unless the delay caused could be overlapped with some other necessary operation).
  
Early [[IBM]] [[System/360]] machines exposed the actual hardware addresses to users (hence the ubiquitous use of BALR instructions to load indexing registers), although the protection mechanism in their case was not a bounds register, but [[protection key]]s on each block of memory. Also, the adder was not done away with entirely - to prevent the need to re-link a program each time it was loaded, indexing registers were used extensively, needing an adder there.
+
Early [[International Business Machines|IBM]] [[System/360]] machines exposed the actual hardware addresses to users (hence the ubiquitous use of BALR instructions to load indexing registers), although the protection mechanism in their case was not a bounds register, but [[protection key]]s on each block of memory. Also, the adder was not done away with entirely - to prevent the need to re-link a program each time it was loaded, indexing registers were used extensively, needing an adder there.
  
 
{{stub}}
 
{{stub}}

Revision as of 18:16, 11 November 2017

Base and bounds is the term for one of the earliest mechanism used in time-sharing operating systems to prevent one user's erroneous (or hostile) program from interfering with the memory of another user (or the OS itself); i.e. to confine it to that area of main memory to which it had been assigned.

As the name suggests, it consisted of a pair of registers which gave the location in main memory (the 'base') of the user's allocated memory area, and another which set a limit on the size of that area (the 'bound'). (Whether that limit was in terms of actual main memory, or in terms of the user's address space, depended on the details of the hardware implementation, and was only relevant to the OS.)

What was visible to the user was whether the address space visible to the program started at 0, or at the actual physical address of the memory assigned to that user. Doing the latter simplified programming, but required an adder in the path of addresses, which potentially had a performance impact (unless the delay caused could be overlapped with some other necessary operation).

Early IBM System/360 machines exposed the actual hardware addresses to users (hence the ubiquitous use of BALR instructions to load indexing registers), although the protection mechanism in their case was not a bounds register, but protection keys on each block of memory. Also, the adder was not done away with entirely - to prevent the need to re-link a program each time it was loaded, indexing registers were used extensively, needing an adder there.