Base and bounds - Revision history

Jnc: +cat

2018-12-15T19:34:23Z

+cat

Jnc: Proper cat

2018-10-18T14:30:55Z

Proper cat

Jnc: Alt term

2018-06-11T15:08:07Z

Alt term

Jnc: Move content to new Memory management page

2017-12-14T15:00:52Z

Move content to new Memory management page

Jnc: avoid redir

2017-11-11T17:16:42Z

avoid redir

Jnc: Mention second park of name

2017-09-28T01:02:25Z

Mention second park of name

Jnc: An OK start

2017-09-27T13:27:28Z

An OK start

New page

'''Base and bounds''' is the term for one of the earliest mechanism used in [[time-sharing]] [[operating system]]s 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 [[register]]s 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. (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 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}}

← Older revision		Revision as of 19:34, 15 December 2018
Line 6:		Line 6:

	{{semi-stub}}		{{semi-stub}}
		+
		+	[[Category: CPU Basics]]

@@ Line 1: / Line 1: @@
-'''Base and bounds''' (also '''base and limits''') is the term for one of the earliest [[memory management]] mechanisms. As the name suggests, it consisted of a pair of [[register]]s 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').
+'''Base and bounds''' (also '''base and limits''') is the term for one of the earliest [[memory management]] mechanisms. As the name suggests, it consisted of a pair of [[register]]s 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 [[operating system]].)
-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 [[address]]es, which potentially had a performance impact (unless the delay caused could be overlapped with some other necessary operation).
-{{stub}}
+{{semi-stub}}

← Older revision		Revision as of 15:08, 11 June 2018
Line 1:		Line 1:
−	'''Base and bounds''' is the term for one of the earliest [[memory management]] mechanisms. As the name suggests, it consisted of a pair of [[register]]s 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').	+	'''Base and bounds''' (also '''base and limits''') is the term for one of the earliest [[memory management]] mechanisms. As the name suggests, it consisted of a pair of [[register]]s 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 [[operating system]].)		(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 [[operating system]].)

@@ Line 1: / Line 1: @@
-'''Base and bounds''' is the term for one of the earliest mechanism used in [[time-sharing]] [[operating system]]s 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.
+'''Base and bounds''' is the term for one of the earliest [[memory management]] mechanisms. As the name suggests, it consisted of a pair of [[register]]s 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').
-As the name suggests, it consisted of a pair of [[register]]s 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.)
+(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 [[operating system]].)
 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).
 {{stub}}

@@ 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).
-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}}