The problem of the /360 was that they put their base registers in
user space. The other machines made it invisible from user space
and added its contents to every memory access. This does not take
up opcode space and allows swapping in and out of the whole process,
which was a much better solution for the early 1960s. (Actually, I
believe the UNIVAC had two, one for program and one for data).
As for the base and range mechanism, that is what much of this
discussion is about. S/360 used arbitrary GPRs for the base registers,
which prevented programs from being moved once they were initially
loaded, whereas other contemporaneous systems used hidden base registers >visible only to the OS. That is precisely what I regard, and have
stated before as a mistake.
According to Thomas Koenig <[email protected]>:
The problem of the /360 was that they put their base registers in
user space. The other machines made it invisible from user space
and added its contents to every memory access. This does not take
up opcode space and allows swapping in and out of the whole process,
which was a much better solution for the early 1960s. (Actually, I
believe the UNIVAC had two, one for program and one for data).
The PDP-6, which was designed around the same time as the 360, had
base and bounds relocation registers which indeed allowed swapping.
The follow-on KA10 had two, the low half of the address space for
private data and the high half for shared code. Later PDP-10s all had
paging.
Base and bounds is OK, but I gather that the PDP-6 and KA10 spent
a lot of time shuffling memory to consolidate free space. An underappreciated advantage of paging is that you don't have to do
that, since one page frame is as good as another.
According to Stephen Fuld <[email protected]d>:
[ base and bounds vs paging
An interesting question is whether it is worthwhile to do both.
Multics had segments of variable size, with each segment paged.
That worked, give or take the inevitable problem of running out of
address bits.
I think that is an insoluble problem with base and bounds. However
you divide up the address space into sections, some sections will
be too small.
... It frees up
the system to optimize page size for just memory management, but it
seems to incur a penalty of requiring two "lookups", one for the
permissions, the other to get the physical address.
Most paging systems have multiple levels of page tables, so they're
doing some of that.
IBN's zSeries has up to five levels of tables
each with permission bits that apply to lower level tables and some
other complications like an optional bit that says a segment table
pointer isn't to a segment table, it's directly to a 2G or 1M byte
contiguous segment.
According to Stephen Fuld <[email protected]d>:
As for the base and range mechanism, that is what much of this
discussion is about. S/360 used arbitrary GPRs for the base registers,
which prevented programs from being moved once they were initially
loaded, whereas other contemporaneous systems used hidden base registers
visible only to the OS. That is precisely what I regard, and have
stated before as a mistake.
I don't think it was a mistake.
The low end 360s were too underpowered to do
time sharing and any sort of dynamic relocation would have just made them more
expensive with no practical benefit. A 360/30 was a lot slower than a PDP-8 but
made up for it with much better I/O devices.
Remember that S/360 was mostly aimed at batch processing where each program starts and runs until it's done. The higher end systems did multiprogramming so
they could run some other batch program in the short interval while waiting for
a disk or tape or card operation.
They included what they called teleprocessing but those systems were transaction
monitors built in the SAGE model with a queue of short chunks of code running to
completion. Relocation and swapping wouldn't help there either.
By the 1970s things had changed. Computers had gotten cheap enough that the batch
applications were moving to time sharing, and as Lynn Wheeler has often told us,
OS/360 got so bloated that they needed virtual memory to give it enough address
space to leave room for applications.
[ base and bounds vs paging
An interesting question is whether it is worthwhile to do both.
... It frees up
the system to optimize page size for just memory management, but it
seems to incur a penalty of requiring two "lookups", one for the
permissions, the other to get the physical address.
According to Stephen Fuld <[email protected]d>:
[ base and bounds vs paging
An interesting question is whether it is worthwhile to do both.
Multics had segments of variable size, with each segment paged.
That worked, give or take the inevitable problem of running out of
address bits.
I think that is an insoluble problem with base and bounds. However
you divide up the address space into sections, some sections will
be too small.
Multics had segments of variable size, with each segment paged.
That worked, give or take the inevitable problem of running out of
address bits.
I didn't know that about Multics. Thanks John. ISTM that their
approach is the opposite of Unisys's approach. They put the pages
within the base and bounds, whereas Unisys puts the base and bounds
"over" the pages. I think the Mill's approach is to put them "side by
side".
On Sun, 15 Jun 2025 19:44:41 +0000, John Levine wrote:
According to Stephen Fuld <[email protected]d>:
[ base and bounds vs paging
An interesting question is whether it is worthwhile to do both.
Multics had segments of variable size, with each segment paged.
That worked, give or take the inevitable problem of running out of
address bits.
I think that is an insoluble problem with base and bounds. However
you divide up the address space into sections, some sections will
be too small.
Who was it that said:: The worst error a computer architect
can make is to specify insufficient number of address bits ??
Gordon Bell ?
Base and bunds simply doubles down on avoiding this rule.
On Sun, 15 Jun 2025 19:44:41 +0000, John Levine wrote:
According to Stephen Fuld <[email protected]d>:
[ base and bounds vs paging
An interesting question is whether it is worthwhile to do both.
Multics had segments of variable size, with each segment paged.
That worked, give or take the inevitable problem of running out of
address bits.
I think that is an insoluble problem with base and bounds. However
you divide up the address space into sections, some sections will
be too small.
Who was it that said:: The worst error a computer architect
can make is to specify insufficient number of address bits ??
Gordon Bell ?
Base and bunds simply doubles down on avoiding this rule.
... It frees up
the system to optimize page size for just memory management, but it
seems to incur a penalty of requiring two "lookups", one for the
permissions, the other to get the physical address.
Most paging systems have multiple levels of page tables, so they're
doing some of that.
Nested paging with 48-bits has 25-levles of page tables (worst case)
5-levels translate each Guest Virtual to Guest Physical.
5-levles translate each Guest Physical to Host Physical.
5×5 = 25
According to Thomas Koenig <[email protected]>:
The problem of the /360 was that they put their base registers in
user space. The other machines made it invisible from user space
and added its contents to every memory access. This does not take
up opcode space and allows swapping in and out of the whole process,
which was a much better solution for the early 1960s. (Actually, I
believe the UNIVAC had two, one for program and one for data).
The PDP-6, which was designed around the same time as the 360, had
base and bounds relocation registers which indeed allowed swapping.
The follow-on KA10 had two, the low half of the address space for
private data and the high half for shared code. Later PDP-10s all had
paging.
Base and bounds is OK, but I gather that the PDP-6 and KA10 spent
a lot of time shuffling memory to consolidate free space. An >underappreciated advantage of paging is that you don't have to do
that, since one page frame is as good as another.
(Yeah, I know some sysems have big pages and small pages but those
don't seem very popular. And some systems don't run I/O through a page
map so you have to coonsolidate space for large I/O operations.)
On Mon, 16 Jun 2025 4:02:26 +0000, Stephen Fuld wrote:
On 6/15/2025 1:09 PM, MitchAlsup1 wrote:
Who was it that said:: The worst error a computer architect
can make is to specify insufficient number of address bits ??
Gordon Bell ?
Base and bunds simply doubles down on avoiding this rule.
I am not sure what you are saying here. There are different "limits"
involved. One is the maximum addressable by a single program, another
is the maximum memory the architecture can support, another is the
maximum size of a section. This last is related to the design of the
ISA, i.e., register size, number of bits used for displacement, etc.
These limits don't have to be the same.
The first two are the ones that were being considered. If an ISA doesn't allow you to run big programs on it - the first - and even more so if it
only works on a computer with a small memory, then, when you go out and
get a shiny new computer, it's going to have a different ISA.
The second, though, has often been gotten around while retaining compatibility. If you have base and bounds, the base isn't visible to
the user, so making the base bigger on a newer version of the computer doesn't break compatibility, except for needing to update the operating system.
(Yeah, I know some sysems have big pages and small pages but those
don't seem very popular. And some systems don't run I/O through a page
map so you have to coonsolidate space for large I/O operations.)
Large pages are problematic in that they must be naturally aligned
(i.e. a 4MB page must be aligned on a 4MB physical address boundary).
This makes it difficult to find sufficent aligned space for dynamic >allocation. Initially, large pages were allocated at boot for use
by database applications. Linux later developed transparent
huge pages (THP) which moved data around to create sufficiently
sized and aligned regions.
According to Scott Lurndal <[email protected]>:
(Yeah, I know some sysems have big pages and small pages but those
don't seem very popular. And some systems don't run I/O through a page >>>map so you have to coonsolidate space for large I/O operations.)
Large pages are problematic in that they must be naturally aligned
(i.e. a 4MB page must be aligned on a 4MB physical address boundary).
Indeed.
This makes it difficult to find sufficent aligned space for dynamic >>allocation. Initially, large pages were allocated at boot for use
by database applications. Linux later developed transparent
huge pages (THP) which moved data around to create sufficiently
sized and aligned regions.
IBM 370 had 1MB secttions which could either be paged or one chunk,
to which z added 2GB regions, same thing.
IBM has invested a lot in z linux, should take a look and see what page >aanagement they offer. 2GB contiguous regions seem rather large, but on
a machine that can have 16TB of RAM, maybe not
On Mon, 16 Jun 2025 4:02:26 +0000, Stephen Fuld wrote:
On 6/15/2025 1:09 PM, MitchAlsup1 wrote:
On Sun, 15 Jun 2025 19:44:41 +0000, John Levine wrote:
According to Stephen Fuld <[email protected]d>:
[ base and bounds vs paging
An interesting question is whether it is worthwhile to do both.
Multics had segments of variable size, with each segment paged.
That worked, give or take the inevitable problem of running out of
address bits.
I think that is an insoluble problem with base and bounds. However
you divide up the address space into sections, some sections will
be too small.
Who was it that said:: The worst error a computer architect
can make is to specify insufficient number of address bits ??
Gordon Bell ?
Base and bunds simply doubles down on avoiding this rule.
I am not sure what you are saying here.
Often base ends up with too few address bits,
almost always bounds ends up with too few size bits.
On a machine today, wanting byte alignment and bite sizing of
memory areas, you need 64-bits of base, 64-bits of bounds and
about 5 more bits to control things. {{Now while I would not
call someone doing base-bounds sane today--I would claim that
knocking a couple bits off the top of bounds and another couple
of bits of bounds to make the control point fit a control register
container might be considered "sane"}}
On 6/15/2025 1:09 PM, MitchAlsup1 wrote:
On Sun, 15 Jun 2025 19:44:41 +0000, John Levine wrote:
According to Stephen Fuld <[email protected]d>:
[ base and bounds vs paging
An interesting question is whether it is worthwhile to do both.
Multics had segments of variable size, with each segment paged.
That worked, give or take the inevitable problem of running out of
address bits.
I think that is an insoluble problem with base and bounds. However
you divide up the address space into sections, some sections will
be too small.
Who was it that said:: The worst error a computer architect
can make is to specify insufficient number of address bits ??
Gordon Bell ?
Base and bunds simply doubles down on avoiding this rule.
I am not sure what you are saying here.
There are different "limits" involved. One is the maximum addressable by a single program, another
is the maximum memory the architecture can support, another is the
maximum size of a section. This last is related to the design of the
ISA, i.e., register size, number of bits used for displacement, etc.
These limits don't have to be the same. And a use of base and bounds
can make the first as large as you want, provided you don't want to
address all of it "simultaneously". That is if you have a way for the
user program to, within appropriate limits change the contents of the
base and bounds registers. As I said before, it is somewhat awkward,
but certainly doable.
On Mon, 16 Jun 2025 4:02:26 +0000, Stephen Fuld wrote:
On 6/15/2025 1:09 PM, MitchAlsup1 wrote:
On Sun, 15 Jun 2025 19:44:41 +0000, John Levine wrote:
According to Stephen Fuld <[email protected]d>:
[ base and bounds vs paging
An interesting question is whether it is worthwhile to do both.
Multics had segments of variable size, with each segment paged.
That worked, give or take the inevitable problem of running out of
address bits.
I think that is an insoluble problem with base and bounds. However
you divide up the address space into sections, some sections will
be too small.
Who was it that said:: The worst error a computer architect
can make is to specify insufficient number of address bits ??
Gordon Bell ?
Base and bunds simply doubles down on avoiding this rule.
I am not sure what you are saying here.
Often base ends up with too few address bits,
almost always bounds ends up with too few size bits.
On a machine today, wanting byte alignment and bite sizing of
memory areas, you need 64-bits of base, 64-bits of bounds and
about 5 more bits to control things.
On Mon, 16 Jun 2025 17:56:40 +0000, Stephen Fuld wrote:
But since these can be/should be/are hidden from the user, they can be
expanded at will.
This could be clearer. How about:
These can be hidden from the user. Since they should be, the fact that
if they are, they can be expanded at will, solves the issue.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:52:01 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,330 |