I saw this article about a memory-proitection mechanism on ARM that
has been bypassed...
https://www.techspot.com/news/103440-researchers-crack-arm-memory-safety-mechanism-achieve-95.html
and I was struck by how similar it sounds to the memory keys used on
the 360.
I saw this article about a memory-proitection mechanism on ARM that
has been bypassed...
https://www.techspot.com/news/103440-researchers-crack-arm-memory-safety-mechanism-achieve-95.html
and I was struck by how similar it sounds to the memory keys used on
the 360.
John Savard
I saw this article about a memory-proitection mechanism on ARM that
has been bypassed...
https://www.techspot.com/news/103440-researchers-crack-arm-memory-safety-mechanism-achieve-95.html
and I was struck by how similar it sounds to the memory keys used on
the 360.
John Savard
It's not that close. S/360 had a single key in the PSW that it matched against
all of a program's storage refrences while this has the tag in a pointer, so it's more like a capability.
The x86 protection keys are more like S/360. There's a key for each
virtual page and a PKRU register that has to match.
John Levine <[email protected]> writes:
It's not that close. S/360 had a single key in the PSW that it matched against
all of a program's storage refrences while this has the tag in a pointer, so >> it's more like a capability.
The x86 protection keys are more like S/360. There's a key for each
virtual page and a PKRU register that has to match.
360s, each 2kbytes had 4bit storage protect key .... match executing psw >4kbit key to storage protect key. zero in psw 4kbit key reserved for
system and allowing access all storage ... non-zero allowing for
(isolating) up to 15 separated concurrently executing (mvt) regions.
The 4 seconds part leads me to believe the attackers are using brute
force, since in 4 seconds one can try something like 2^28 patterns.
In article <[email protected]>, [email protected] (MitchAlsup1) wrote:
The 4 seconds part leads me to believe the attackers are using brute
force, since in 4 seconds one can try something like 2^28 patterns.
Makes sense: there's probably a hash of the block address involved in generating those 4-bit tags, and they're brute-forcing the salt.
Memory Tagging Extension doesn't seem to have been heavily used as yet,
which may be why ARM aren't very worried about it.
Pointer Authentication Code in ARMv8.3 is usable within functions, but
has problems, in that compilers can't readily tell if stored pointers
have PAC signatures.
Branch Target Indicators in ARMv8.5 work quite well, but need linker
and
loader support.
PAC and BTI use instructions that are no-ops in earlier versions of
ARM64,
but you really ought to test that they work before releasing binaries
that include them. I've done that on Android, where I had the
combination
of hardware, OS and compiler to do it.
Once I can get an ARM Linux server with the hardware support, Linux
kernel 5.0 onwards and modern GCC will let me do it there. Windows and
macOS on ARM both lack some pieces, and iOS requires you to change ABIs
and drop support for older 64-bit devices.
John
a little over decade ago was asked to track down decision to add virtual memory to all 370s. basically MVT storage management was so bad that
required specifying region storage requirements four times larger than
used ...
Or the 3 years earlier LEO 3.
The difference was, with MFT, a program had to declare its memory
requirement before it could be started, and the only way to change that
was to stop the program and start it again. Whereas MVT allowed a program
to change its memory requirements while it was executing. (Whoah! Program >relocation requirement styleee!)
Eventually, the MFT→OS/VS1 line died a long-overdue death, and OS/VS2 >became “MVS”. Not sure what other name changes happened along the way, but >nowadays this is known as “z/OS”.
Does that make sense?
Not really. VS1 was basically MFT running in a single virtual address
space. The early versions of VS2 were SVS, MVT running in a single
virtual address space, and then MVS, where each job got its own
address space. As Lynn has often explained, OS chewed up so much of
the address space that they needed MVS to make enough room for
programs to keep doing useful work.
trivia: I was pontificating in the 70s about mismatch between increase
in system throughput (memory & CPU) and increase in disk throughput. In
early 80s wrote a tome that the relative system throughput of disk had declined by an order of magnitude since 360 was announced in the 60s
(systems increase 40-50 times, disks increased 3-5 times).
John Levine <[email protected]> writes:
Not really. VS1 was basically MFT running in a single virtual address
space. The early versions of VS2 were SVS, MVT running in a single
virtual address space, and then MVS, where each job got its own
address space. As Lynn has often explained, OS chewed up so much of
the address space that they needed MVS to make enough room for
programs to keep doing useful work.
... also SVS single 16mbyte virtual address space (sort of like running
MVT in CP67 16mbyte virtual machine) to "protect" regions from each
other still used the 360 4bit storage protection key ... so caped at 15 concurrent regions ... but systems were getting faster, much faster than disks were getting faster ... so needed increasing numbers of
concurrently executing regions ... so went to MVS ... gave each region
its own virtual address space (to keep them isolated/protected from each other). But MVS was becoming increasingly bloated both in real storage
and amount it took in each region's virtual address space .... so needed
more than 16mbyte real storage as well as more than 16mbyte virtual
storage.
trivia: I was pontificating in the 70s about mismatch between increase
in system throughput (memory & CPU) and increase in disk throughput. In
early 80s wrote a tome that the relative system throughput of disk had declined by an order of magnitude since 360 was announced in the 60s
(systems increase 40-50 times, disks increased 3-5 times). A disk
division executive took exception and assigned the division performance
group to refute my claims. After a couple of weeks, they basically came
back and said that I had slightly understated the problem.
They then respun the analysis for a (mainframe user group) SHARE
presentation for how to configure disks for increased system throughput (16Aug1984, SHARE 63, B874).
more recently there have been some references that cache-miss, memory
access latency, when measured in count of processor cycles, is
compareable to 60s disk access latency, when measure in count of 60s processor cycles (memory is new disk).
Not only is RAM the new disk ...
According to Lawrence D'Oliveiro <[email protected]d>:
The difference was, with MFT, a program had to declare its memory >>requirement before it could be started, and the only way to change that
was to stop the program and start it again. Whereas MVT allowed a program >>to change its memory requirements while it was executing. (Whoah! Program >>relocation requirement styleee!)
Nope. MFT partitioned memory into fixed sized areas when the system
started, MVT assigned each program as much memory as it said it
needed, and the areas could be reallocated between job steps. In every
case the JCL had to say how big a partition each job step needed.
When I first looked at the syntax for slurm, a workload manager for HPC clusters (did somebody say "Job Entry Subsystem"?),
I found it striking how similar its syntax and semantics are to JCL's
job cards. But then, they have a similar task.
Not only is RAM the new disk, but last level cache is the new RAM, and
you could argue that $L1 plays the role of a vector computer register array.
The result values forwarding network is the new register array.
Yeah, the comparison does break down a bit at the very end, but going in
the opposite direction, disk (of the spinning rust variety) is an almost perfect match for 60'ies tape: Getting to any particular spot takes a
long time, so when you get there you had better do a lot of sequential access!
On Mon, 24 Jun 2024 07:34:05 +0200, Terje Mathisen wrote:
Not only is RAM the new disk ...
That would be DRAM. Whatever happened to SRAM? Surely having a few
mebibytes of that can’t be a big cost these days.
Lawrence D'Oliveiro <[email protected]d> writes:
That would be DRAM. Whatever happened to SRAM? Surely having a few >mebibytes of that can't be a big cost these days.I'm not sure what a mebibyte is.
On Mon, 24 Jun 2024 07:34:05 +0200, Terje Mathisen wrote:
Not only is RAM the new disk ...
That would be DRAM. Whatever happened to SRAM? Surely having a few
mebibytes of that can’t be a big cost these days.
On Thu, 20 Jun 2024 14:28:04 -1000, Lynn Wheeler wrote:
a little over decade ago was asked to track down decision to add
virtual memory to all 370s. basically MVT storage management was so
bad that required specifying region storage requirements four times
larger than used ...
Let me see if I got this straight.
In the early days, the offshoots of OS/360 were “MFT” (“Multiple
Fixed Tasks”)
The “Multiple”
part had to do with this new-fangled thing called “multiprogramming”: basically, there was so much RAM available by that point that you
could typically keep multiple programs memory-resident at once, even
if only one was executing, instead of having to swap everybody but
the current program out.
The difference was, with MFT, a program had to declare its memory
requirement before it could be started, and the only way to change
that was to stop the program and start it again. Whereas MVT allowed
a program to change its memory requirements while it was executing.
(Whoah! Program relocation requirement styleee!)
Then, when virtual memory came along, MFT became OS/VS1, while MVT
became OS/VS2.
Eventually, the MFT→OS/VS1 line died a long-overdue death, and OS/VS2 became “MVS”. Not sure what other name changes happened along the
way, but nowadays this is known as “z/OS”.
Does that make sense?
While a job could change its memory requirements with each task,IIRC
it was better to specify the largest requirement in the beginning, and releasing memory as the largest remaining requirement got smaller.
This was because if the memory requirement increased inn the middle of
the job, you were not quaranteed that the additional memory was
available, and if it wasn't, the job would have to be terminated or
"rolled out" until the required memory was available. Note, as John explained, since programs were not relocatable, if a program was
rolled out, it could only be rolled in to the same address it was
rolled out from.
How much of theoretical disk bandwidth was the filesystem capable of
using? Because I know early Unix systems were pretty terrible in that
regard, until Berkeley’s “Fast File System” came along.
According to Lawrence D'Oliveiro <[email protected]d>:
How much of theoretical disk bandwidth was the filesystem capable of
using? Because I know early Unix systems were pretty terrible in that
regard, until Berkeley’s “Fast File System” came along.
My recollection is that if you were using QSAM with multiple buffers and
full track records it wasn't hard to keep the disk going at full speed.
Later versions of OS do chained scheduling if you have enough buffers,
doing several disk operations with one cnannel program.
Even on (MS)DOS it was easy to saturate the hard drive from a single
program, you just needed large enough (i.e. at least a full track each) buffers.
According to Lawrence D'Oliveiro <[email protected]d>:
How much of theoretical disk bandwidth was the filesystem capable of
using? Because I know early Unix systems were pretty terrible in that
regard, until Berkeley’s “Fast File System†came along.
My recollection is that if you were using QSAM with multiple buffers
and full track records it wasn't hard to keep the disk going at full
speed. Later versions of OS do chained scheduling if you have enough
buffers, doing several disk operations with one cnannel program.
John Levine wrote:
According to Lawrence D'Oliveiro <[email protected]d>:
How much of theoretical disk bandwidth was the filesystem capable
of using? Because I know early Unix systems were pretty terrible
in that regard, until Berkeley’s “Fast File System†came
along.
My recollection is that if you were using QSAM with multiple buffers
and full track records it wasn't hard to keep the disk going at full
speed. Later versions of OS do chained scheduling if you have enough buffers, doing several disk operations with one cnannel program.
Even on (MS)DOS it was easy to saturate the hard drive from a single program, you just needed large enough (i.e. at least a full track
each) buffers.
I did end up making special file/record layouts which were optimized
for this, using exactly 4kB for each header+bitmap record.
Terje
On Tue, 25 Jun 2024 08:49:43 +0200, Terje Mathisen wrote:
Even on (MS)DOS it was easy to saturate the hard drive from a single
program, you just needed large enough (i.e. at least a full track each)
buffers.
That sounds more like a peak thing than a sustained thing. In between
filling the buffers, the disk is left idle. So on average you are
operating well below theoretical disk capacity.
After all, MS-DOS never suppported async I/O.
On Tue, 25 Jun 2024 04:04:31 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <[email protected]d>:
of >> using? Because I know early Unix systems were pretty terribleHow much of theoretical disk bandwidth was the filesystem capable
in that >> regard, until Berkeley’s “Fast File System” came along.
My recollection is that if you were using QSAM with multiple
buffers and full track records it wasn't hard to keep the disk
going at full speed. Later versions of OS do chained scheduling if
you have enough buffers, doing several disk operations with one
cnannel program.
Presumably the downside of that was there was no such thing as
“stream- oriented” I/O: it was all record-based, just like most of
the other OSes.
Unix was unique in hiding the need from applications/users to worry
about sector sizes when writing to files and reading from files. But
there was a significant overhead in that, at least in the early years.
Lawrence D'Oliveiro wrote:
Presumably the downside of that was there was no such thing as
“stream- oriented” I/O: it was all record-based, just like most of
the other OSes.
For the business oriented and even scientific oriented applications
typically run on S/360, "stream oriented" I/O would have been a
distinct disadvantage. COBOL I/O (and even Fortran I/O) is "record >oriented". "byte oriented" I/O would ha made things harder for the
programer as well as much less efficient.
Unix was unique in hiding the need from applications/users to worry
about sector sizes when writing to files and reading from files. But
there was a significant overhead in that, at least in the early years.
There still is additional overhead. But the application amd
programming language mix has changed, so stream oriented I/O is now the >default.
On Tue, 25 Jun 2024 08:49:43 +0200
Terje Mathisen <[email protected]> wrote:
John Levine wrote:
According to Lawrence D'Oliveiro <[email protected]d>:Even on (MS)DOS it was easy to saturate the hard drive from a single
How much of theoretical disk bandwidth was the filesystem capableMy recollection is that if you were using QSAM with multiple buffers
of using? Because I know early Unix systems were pretty terrible
in that regard, until Berkeley’s “Fast File System†came
along.
and full track records it wasn't hard to keep the disk going at full
speed. Later versions of OS do chained scheduling if you have enough
buffers, doing several disk operations with one cnannel program.
program, you just needed large enough (i.e. at least a full track
each) buffers.
I am not sure that "saturate the hard drive" is a correct wording.
According to my understanding, [when within track] hard drives used in
early PCs were more capable than hard disk controllers (Xebec 1210 in
XT, I don't know what was used before XT). In turn, disk side interface
of disk controller was likely more capable than its system bus side.
Now, those are just feelings, I can't find hard data to back it up.
I did end up making special file/record layouts which were optimized
for this, using exactly 4kB for each header+bitmap record.
Terje
Scott Lurndal wrote:
And even on the mainframes, the records were blocked and read
in larger chunks and the application deblocked them.
Sure. But lets use a typical example of reading 80 column card images >blocked 10, so an 800 byte disk record (remember, this is IBM, CKD type >disks, so really 800 byte records on the disk). So for ten out of
every eleven reads, the read verb just meant a single load of the base >address of the next record in the block.
"Stephen Fuld" <[email protected]d> writes:
Lawrence D'Oliveiro wrote:
most of >> the other OSes.Presumably the downside of that was there was no such thing as
“stream- oriented” I/O: it was all record-based, just like
For the business oriented and even scientific oriented applications typically run on S/360, "stream oriented" I/O would have been a
distinct disadvantage. COBOL I/O (and even Fortran I/O) is "record oriented". "byte oriented" I/O would ha made things harder for the programer as well as much less efficient.
But >> there was a significant overhead in that, at least in theUnix was unique in hiding the need from applications/users to worry
about sector sizes when writing to files and reading from files.
early years.
There still is additional overhead. But the application amd
programming language mix has changed, so stream oriented I/O is now
the default.
Is there? It's trivially easy to impose a record structure
on a stream of bytes,
and all the unix file access APIs allow
direct access to the device without extra buffering if desired,
subject to some alignment constraints.
And even on the mainframes, the records were blocked and read
in larger chunks and the application deblocked them.
My recollection is that if you were using QSAM with multiple buffers
and full track records it wasn't hard to keep the disk going at full
speed. Later versions of OS do chained scheduling if you have enough
buffers, doing several disk operations with one cnannel program.
Michael S wrote:
On Tue, 25 Jun 2024 08:49:43 +0200
Terje Mathisen <[email protected]> wrote:
John Levine wrote:
According to Lawrence D'Oliveiro <[email protected]d>:Even on (MS)DOS it was easy to saturate the hard drive from a
How much of theoretical disk bandwidth was the filesystem capableMy recollection is that if you were using QSAM with multiple
of using? Because I know early Unix systems were pretty terrible
in that regard, until Berkeley’s “Fast File System†came
along.
buffers and full track records it wasn't hard to keep the disk
going at full speed. Later versions of OS do chained scheduling
if you have enough buffers, doing several disk operations with
one cnannel program.
single program, you just needed large enough (i.e. at least a full
track each) buffers.
I am not sure that "saturate the hard drive" is a correct wording. According to my understanding, [when within track] hard drives used
in early PCs were more capable than hard disk controllers (Xebec
1210 in XT, I don't know what was used before XT). In turn, disk
side interface of disk controller was likely more capable than its
system bus side. Now, those are just feelings, I can't find hard
data to back it up.
I did end up making special file/record layouts which were
optimized for this, using exactly 4kB for each header+bitmap
record.
Terje
According to this the interface to the ST506/ST412 drives from early
1980's could handle 5 Mb/s and the avg track seek time was 170 ms
(later 85 ms).
https://en.wikipedia.org/wiki/ST-506#History
The 8-bit PC bus was 8 MB/s so there should be no
technical reason for not keeping *multiple* such drives fully busy
(seeking or transferring) while concurrently executing code.
There still is additional overhead. But the application amd
programming language mix has changed, so stream oriented I/O is now the >>default.
Is there? It's trivially easy to impose a record structure
on a stream of bytes, and all the unix file access APIs allow
direct access to the device without extra buffering if desired,
subject to some alignment constraints.
But if you are using the "standard" Unix file system, doesn't it read
the block(S) into its cache, then when the user program does the read, transfer the data from its cache into the user's variables? That is the extra overhead to which I was referring.
"Stephen Fuld" <[email protected]d> writes:
Scott Lurndal wrote:
And even on the mainframes, the records were blocked and read
in larger chunks and the application deblocked them.
Sure. But lets use a typical example of reading 80 column card images
blocked 10, so an 800 byte disk record (remember, this is IBM, CKD type
disks, so really 800 byte records on the disk). So for ten out of
every eleven reads, the read verb just meant a single load of the base
address of the next record in the block.
Same thing on Unix. Read 800 bytes at a time and treat it as 10
80-byte records.
Modern unix/linux systems will anticipate sequential accesses
and do anticipatory loads such that data is already in memory
when the next "record" is needed.
On Tue, 25 Jun 2024 11:24:03 -0400
EricP <[email protected]> wrote:
Michael S wrote:
On Tue, 25 Jun 2024 08:49:43 +0200
Terje Mathisen <[email protected]> wrote:
John Levine wrote:
According to Lawrence D'Oliveiro <[email protected]d>:Even on (MS)DOS it was easy to saturate the hard drive from a
How much of theoretical disk bandwidth was the filesystem capableMy recollection is that if you were using QSAM with multiple
of using? Because I know early Unix systems were pretty terrible
in that regard, until Berkeley’s “Fast File System†came
along.
buffers and full track records it wasn't hard to keep the disk
going at full speed. Later versions of OS do chained scheduling
if you have enough buffers, doing several disk operations with
one cnannel program.
single program, you just needed large enough (i.e. at least a full
track each) buffers.
I am not sure that "saturate the hard drive" is a correct wording.
According to my understanding, [when within track] hard drives used
in early PCs were more capable than hard disk controllers (Xebec
1210 in XT, I don't know what was used before XT). In turn, disk
side interface of disk controller was likely more capable than its
system bus side. Now, those are just feelings, I can't find hard
data to back it up.
I did end up making special file/record layouts which were
optimized for this, using exactly 4kB for each header+bitmap
record.
Terje
According to this the interface to the ST506/ST412 drives from early
1980's could handle 5 Mb/s and the avg track seek time was 170 ms
(later 85 ms).
https://en.wikipedia.org/wiki/ST-506#History
Thank you. I didn't realize that PC HDs of early 80s were *that*
slow.
The 8-bit PC bus was 8 MB/s so there should be no
technical reason for not keeping *multiple* such drives fully busy
(seeking or transferring) while concurrently executing code.
8 MB/s sounds fast. I think, even for XT 2 MB/s is more realistic. Less
than that for original PC.
On Tue, 25 Jun 2024 11:24:03 -0400
EricP <[email protected]> wrote:
Michael S wrote:
On Tue, 25 Jun 2024 08:49:43 +0200According to this the interface to the ST506/ST412 drives from early
Terje Mathisen <[email protected]> wrote:
John Levine wrote:I am not sure that "saturate the hard drive" is a correct wording.
According to Lawrence D'Oliveiro <[email protected]d>:Even on (MS)DOS it was easy to saturate the hard drive from a
How much of theoretical disk bandwidth was the filesystem capableMy recollection is that if you were using QSAM with multiple
of using? Because I know early Unix systems were pretty terrible
in that regard, until Berkeley’s “Fast File System†came
along.
buffers and full track records it wasn't hard to keep the disk
going at full speed. Later versions of OS do chained scheduling
if you have enough buffers, doing several disk operations with
one cnannel program.
single program, you just needed large enough (i.e. at least a full
track each) buffers.
According to my understanding, [when within track] hard drives used
in early PCs were more capable than hard disk controllers (Xebec
1210 in XT, I don't know what was used before XT). In turn, disk
side interface of disk controller was likely more capable than its
system bus side. Now, those are just feelings, I can't find hard
data to back it up.
I did end up making special file/record layouts which were
optimized for this, using exactly 4kB for each header+bitmap
record.
Terje
1980's could handle 5 Mb/s and the avg track seek time was 170 ms
(later 85 ms).
https://en.wikipedia.org/wiki/ST-506#History
Thank you. I didn't realize that PC HDs of early 80s were *that*
slow.
The 8-bit PC bus was 8 MB/s so there should be no
technical reason for not keeping *multiple* such drives fully busy
(seeking or transferring) while concurrently executing code.
8 MB/s sounds fast. I think, even for XT 2 MB/s is more realistic. Less
than that for original PC.
According to Scott Lurndal <[email protected]>:
There still is additional overhead. But the application amd
programming language mix has changed, so stream oriented I/O is now the >>>default.
Is there? It's trivially easy to impose a record structure
on a stream of bytes, and all the unix file access APIs allow
direct access to the device without extra buffering if desired,
subject to some alignment constraints.
At the time Unix was written, the big advantage of byte stream text was
that there weren't any trailing blanks so you fit a lot more data onto
a disk than you did with 80 or 132 character fixed records.
These days although Unix-ish systems still let you read or write
arbitrary text chunks, in practice everyone uses I/O libraries that do
reads and writes aligned to disk blocks, or map tthe file and let the
pager handle it. The logical file format is an application thing on
top of that.
On 6/25/2024 8:41 AM, Scott Lurndal wrote:
"Stephen Fuld" <[email protected]d> writes:
Scott Lurndal wrote:
And even on the mainframes, the records were blocked and read
in larger chunks and the application deblocked them.
Sure. But lets use a typical example of reading 80 column card images
blocked 10, so an 800 byte disk record (remember, this is IBM, CKD type
disks, so really 800 byte records on the disk). So for ten out of
every eleven reads, the read verb just meant a single load of the base
address of the next record in the block.
Same thing on Unix. Read 800 bytes at a time and treat it as 10
80-byte records.
But if you are using the "standard" Unix file system,
Is there? It's trivially easy to impose a record structure
on a stream of bytes, and all the unix file access APIs allow
direct access to the device without extra buffering if desired,
subject to some alignment constraints.
At the time Unix was written, the big advantage of byte stream text was >>that there weren't any trailing blanks so you fit a lot more data onto
a disk than you did with 80 or 132 character fixed records.
That was one advantage. Consider, however, that byte streams fit
quite well into the unix pipeline paradigm and that may have been
the driving force behind the non-record-based I/O facilities in
Unix,...
These days although Unix-ish systems still let you read or write
arbitrary text chunks, in practice everyone uses I/O libraries that do
I've been writing unix and unix-like operating systems for almost
four decades now. I would disagree with the "everyone uses I/O libraries"; >while stdio provides buffering, high-performance applications such
as the Oracle RDMB don't use stdio - they directly access the device
(unix raw devices, or linux O_DIRECT) and handle all their own buffering.
possible to request “locate mode”, where it returns the address of a >record directly within its internal buffers. But there are many
restrictions on this, among other things:
* It only works for reads, not for writes
* It doesn’t work for records crossing block boundaries
* It doesn’t work for compressed records
On Tue, 25 Jun 2024 22:28:40 -0700, Stephen Fuld wrote:
But if you are using the "standard" Unix file system, doesn't it
read the block(S) into its cache, then when the user program does
the read, transfer the data from its cache into the user's
variables? That is the extra overhead to which I was referring.
That tends to happen anyway, even on OSes which insist on
record-oriented I/O. For example, on DEC’s VMS, the record blocking
layer is called “RMS” (“Record Management Services”), and that usually copies records between the user’s buffers and its own
internal buffers (“move mode”). It is possible to request “locate mode”, where it returns the address of a record directly within its internal buffers. But there are many restrictions on this, among
other things:
* It only works for reads, not for writes
* It doesn’t work for records crossing block boundaries
* It doesn’t work for compressed records
So this record-copying overhead is not, in itself, a point against
Unix- style streaming I/O.
understand why not for writes. The no crossing block boundries is a
side effect of fixed block disks. This couldn't happen in OS/360 with
CKD disks.
According to Stephen Fuld <[email protected]d>:
understand why not for writes. The no crossing block boundries is a
side effect of fixed block disks. This couldn't happen in OS/360
with CKD disks.
Actually, it did. OS had a Variable Block Spanned record format that
could split a logical record over several physical disk blocks. I
don't think it was very widely used, but it's still there in z/OS:
According to Lawrence D'Oliveiro <[email protected]d>:
possible to request “locate mode”, where it returns the address of a >>record directly within its internal buffers. But there are many >>restrictions on this, among other things:
* It only works for reads, not for writes
It works fine for writes on IBM systems. PL/I even has a LOCATE
statement to get a buffer to write into.
possible to request “locate mode”, ...
* It only works for reads, not for writes
It works fine for writes on IBM systems. PL/I even has a LOCATE
statement to get a buffer to write into.
I found this manual ><http://bitsavers.trailing-edge.com/pdf/ibm/360/tss/GC28-2045-1_Time_Sharing_System_PLI_Language_Reference_Manual.pdf>.
On page 96, it says
The LOCATE Statement
--------------------
...
So it has its own limitations on applicability. For example, it only
seems to work for writes, not reads.
Lawrence D'Oliveiro wrote:
On Tue, 25 Jun 2024 22:28:40 -0700, Stephen Fuld wrote:
But if you are using the "standard" Unix file system, doesn't it
read the block(S) into its cache, then when the user program does
the read, transfer the data from its cache into the user's
variables? That is the extra overhead to which I was referring.
That tends to happen anyway, even on OSes which insist on
record-oriented I/O. For example, on DEC’s VMS, the record blocking
layer is called “RMS” (“Record Management Services”), and that
usually copies records between the user’s buffers and its own
internal buffers (“move mode”). It is possible to request “locate
mode”, where it returns the address of a record directly within its
internal buffers. But there are many restrictions on this, among
other things:
* It only works for reads, not for writes
* It doesn’t work for records crossing block boundaries
* It doesn’t work for compressed records
So this record-copying overhead is not, in itself, a point against
Unix- style streaming I/O.
The fact that other OSs "made the same mistake" :-) isn't a point for treating all I/O as a stream of bytes. I don't know VAX, but I don't understand why not for writes. The no crossing block boundries is a
side effect of fixed block disks. This couldn't happen in OS/360 with
CKD disks. I agree about compression, of course, as unless you do the compression in the I/O hardware stream, you need to "move" the data
anyway.
According to Scott Lurndal <[email protected]>:
Is there? It's trivially easy to impose a record structure
on a stream of bytes, and all the unix file access APIs allow
direct access to the device without extra buffering if desired,
subject to some alignment constraints.
At the time Unix was written, the big advantage of byte stream text was >>>that there weren't any trailing blanks so you fit a lot more data onto
a disk than you did with 80 or 132 character fixed records.
That was one advantage. Consider, however, that byte streams fit
quite well into the unix pipeline paradigm and that may have been
the driving force behind the non-record-based I/O facilities in
Unix,...
Pipelines work equally well with fixed length records. They were
familar with byte streams from PDP-10, Multics, and other systems
they'd worked with.
Consider, however, that byte streams fit quite well into the
unix pipeline paradigm and that may have been the driving force
behind the non-record-based I/O facilities in Unix, and allowed
record-based or block-based file handling if the application
desired it ...
Pipelines work equally well with fixed length records. They were
familar with byte streams from PDP-10, Multics, and other systems
they'd worked with.
Did these systems actually feature byte streams? Both the PDP-10
and the GE 635 were word-oriented machines with 36 bits, so I
assume it must have been word streams at least.
Never used GCOS and never did non-trivial programming on DTSS so I
couldn't tell you what they did. DTSS had communication files which
were a lot like pipes. See https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf
According to Lawrence D'Oliveiro <[email protected]d>:
possible to request “locate mode”, ...
* It only works for reads, not for writes
It works fine for writes on IBM systems. PL/I even has a LOCATE
statement to get a buffer to write into.
I found this manual >><http://bitsavers.trailing-edge.com/pdf/ibm/360/tss/GC28-2045-1_Time_Sharing_System_PLI_Language_Reference_Manual.pdf>.
On page 96, it says
The LOCATE Statement
--------------------
...
So it has its own limitations on applicability. For example, it only
seems to work for writes, not reads.
Well, yeah. Keep reading and on page 97 you'll find the SET option
which is how a you get the pointer for a locate mode READ. It was more
common when defining based data to say in the declaration what the
default pointer to the data was, so if you said to READ or LOCATE the
item, it'd automatically set the pointer.
That TSS manual is rather estoteric since hardly anyone ever used TSS
and even those of use who did, didn't write much PL/I.
Here's the regular PL/I manual which explains locate mode for
reading and writing on page 168.
https://bitsavers.org/pdf/ibm/360/pli/C28-8201-1_PLIrefMan_Jan69.pdf
DTSS had communication files which were a lot like pipes. See https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf
A line was anything up to CR/LF
(and maybe form feed and other control characters) with the convention
that you ignored null bytes.
Don't forget that the original use case for Unix was document
production, where record-based i/o is not very useful.
I did; TSS 360/67 CMU, and I did; both PL/C and PL/1.
On Thu, 27 Jun 2024 09:14 +0100 (BST), John Dallman wrote:
Don't forget that the original use case for Unix was document
production, where record-based i/o is not very useful.
Thinking of the kinds of documents: consider that, well into the 1980s and >1990s, sending out letters to mailing lists was a common scenario, and
that requires the ability to handle both text (the letter form) and
database (the address list) functions, and merge the two. ...
According to Lawrence D'Oliveiro <[email protected]d>:
On Thu, 27 Jun 2024 09:14 +0100 (BST), John Dallman wrote:
Don't forget that the original use case for Unix was document
production, where record-based i/o is not very useful.
Thinking of the kinds of documents: consider that, well into the 1980s and >>1990s, sending out letters to mailing lists was a common scenario, and
that requires the ability to handle both text (the letter form) and >>database (the address list) functions, and merge the two. ...
The killer app for Unix and nroff was typing up patent applications,
and the killer feature was putting line numbers every Nth line of the formatted output the way the patent office wanted. At the time, it was
the only document system that could do that.
On Thu, 27 Jun 2024 17:39:46 +0000, MitchAlsup1 wrote:
I did; TSS 360/67 CMU, and I did; both PL/C and PL/1.
Did you make much use of LOCATE-style I/O?
Lawrence D'Oliveiro wrote:
On Thu, 27 Jun 2024 17:39:46 +0000, MitchAlsup1 wrote:
I did; TSS 360/67 CMU, and I did; both PL/C and PL/1.
Did you make much use of LOCATE-style I/O?
No, I fond VSAM completely adequate for my needs.
On Fri, 28 Jun 2024 15:08:20 +0000, MitchAlsup1 wrote:
Lawrence D'Oliveiro wrote:
On Thu, 27 Jun 2024 17:39:46 +0000, MitchAlsup1 wrote:
I did; TSS 360/67 CMU, and I did; both PL/C and PL/1.
Did you make much use of LOCATE-style I/O?
No, I fond VSAM completely adequate for my needs.
This tends to confirm my suspicion that LOCATE-style I/O is too hedged
round with restrictions to be useful outside some limited set of
situations. Most of the time, it’s just not worth the trouble.
On 6/28/2024 2:55 PM, Lawrence D'Oliveiro wrote:
On Fri, 28 Jun 2024 15:08:20 +0000, MitchAlsup1 wrote:
Lawrence D'Oliveiro wrote:
On Thu, 27 Jun 2024 17:39:46 +0000, MitchAlsup1 wrote:
I did; TSS 360/67 CMU, and I did; both PL/C and PL/1.
Did you make much use of LOCATE-style I/O?
No, I fond VSAM completely adequate for my needs.
This tends to confirm my suspicion that LOCATE-style I/O is too hedged
round with restrictions to be useful outside some limited set of
situations. Most of the time, it’s just not worth the trouble.
It really depends upon what you are doing. ...
... more often than not locate I/O is faster and easier.
When you touched the address, the page fault caused the I/O.
On Sat, 29 Jun 2024 18:22:04 -0000 (UTC), John Levine wrote:
... more often than not locate I/O is faster and easier.
Given all the caveats and restrictions, “easier” is not how I would describe it.
But perhaps we’re talking at cross-purposes. If Mitch did his TSS and
PL/I
stuff in the 1970s, while you’re talking about the 1960s, then that
could
explain it. By the 1970s, CPU/RAM speeds had improved to the point where copying records a few hundred bytes at a time between buffers was not
the
performance bottleneck; disk I/O was.
When you touched the address, the page fault caused the I/O.
There seems to be this assumption that the paging mechanism is some kind
of clever way of doing I/O. It’s not.
On Sat, 29 Jun 2024 18:22:04 -0000 (UTC), John Levine wrote:
... more often than not locate I/O is faster and easier.
Given all the caveats and restrictions, “easier” is not how I would describe it.
But perhaps we’re talking at cross-purposes. If Mitch did his TSS and
PL/I stuff in the 1970s, while you’re talking about the 1960s, then
that could explain it. By the 1970s, CPU/RAM speeds had improved to
the point where copying records a few hundred bytes at a time between
buffers was not the performance bottleneck; disk I/O was.
Lawrence D'Oliveiro wrote:
By the 1970s, CPU/RAM speeds had improved to the
point where copying records a few hundred bytes at a time between
buffers was not the performance bottleneck; disk I/O was.
Yes, but given multiprogramming, even in the 1970s, you would typically
have several batch programs running at the same time, so during waits
for I/O, another program could use the CPU. But using the CPU to move records meant it couldn't be doing anything else at the same time.
Work out the numbers. The CPU time necessary to copy a single record is
most likely a small fraction of the time it takes to service an I/O interrupt.
And this is not taking into account the fact that I/O interrupts run at a higher priority than user-level tasks like copying buffers, anyway.
back to IBM decision to add virtual memory to every 370 ... aka MVT
storage management was so bad that regions had to be specified four
times larger than used
John Dallman <[email protected]> schrieb:
In article <87ed8e7os5.fsf@localhost>, [email protected] (Lynn
Wheeler) wrote:
back to IBM decision to add virtual memory to every 370 ... aka MVT
storage management was so bad that regions had to be specified four
times larger than used
What was the problem with the memory management? My experience of
systems without virtual memory doesn't include any that shared the
machine among several applications, so I have trouble guessing.
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
The /360 tried to solve this via base pointers, which all addresses
were supposed calculated relative to to. Hence the RX and RS
instraction all had a base register + 12 bit offset for their
addressing modes - swapping out the base registers (if you knew
which ones they were, was this info in the executable?) should have
worked. But the SS instructions for decimal arithmetic did not have
base pointers, so that solution did not work in the general casse.
Going to virtual memory from the start would have saved the
base pointer issue, and would have allowed 16-bit displacements,
also saving registers in the case where 12-bit displacements were
not enough.
In article <87ed8e7os5.fsf@localhost>, [email protected] (Lynn Wheeler)
wrote:
back to IBM decision to add virtual memory to every 370 ... aka MVT
storage management was so bad that regions had to be specified four
times larger than used
What was the problem with the memory management? My experience of systems without virtual memory doesn't include any that shared the machine among several applications, so I have trouble guessing.
On Sun, 30 Jun 2024 10:44:34 -0000 (UTC)
Thomas Koenig <[email protected]> wrote:
John Dallman <[email protected]> schrieb:
In article <87ed8e7os5.fsf@localhost>, [email protected] (Lynn
Wheeler) wrote:
back to IBM decision to add virtual memory to every 370 ... aka MVT
storage management was so bad that regions had to be specified four
times larger than used
What was the problem with the memory management? My experience of
systems without virtual memory doesn't include any that shared the
machine among several applications, so I have trouble guessing.
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
Why would I want to use different address?
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
The /360 tried to solve this via base pointers, which all addresses
were supposed calculated relative to to. Hence the RX and RS
instraction all had a base register + 12 bit offset for their
addressing modes - swapping out the base registers (if you knew
which ones they were, was this info in the executable?) should have
worked. But the SS instructions for decimal arithmetic did not have
base pointers, so that solution did not work in the general casse.
Going to virtual memory from the start would have saved the
base pointer issue, and would have allowed 16-bit displacements,
also saving registers in the case where 12-bit displacements were
not enough.
As I think I said before, these days you map the file into your
address space and read or write it like a long string, so its all
locate all the time.
John Levine <[email protected]> writes:
As I think I said before, these days you map the file into your
address space and read or write it like a long string, so its all
locate all the time.
Reading with mmap() appears to be quite common, either directly or
through libaries like glibc which use mmap() for buffered input where >possible. For writing, using mmap() poses some difficulties:
* Writing to an mmap()ed region has weaker atomicity semantics than
write().
* mmap() works on pages (not in the interface, fortunately, but
internally), but for writing you want byte granularity. The
difference is not a big problem for reading, but it is a bigger one
for writing.
* You have to extend the file length with a separate system call, and
then mmap() the new area, so you might just as well use write().
Michael S <[email protected]> schrieb:
On Sun, 30 Jun 2024 10:44:34 -0000 (UTC)
Thomas Koenig <[email protected]> wrote:
MVT >> >> storage management was so bad that regions had to beJohn Dallman <[email protected]> schrieb:
In article <87ed8e7os5.fsf@localhost>, [email protected] (Lynn
Wheeler) wrote:
back to IBM decision to add virtual memory to every 370 ... aka
specified four >> >> times larger than used
the >> > machine among several applications, so I have trouble
What was the problem with the memory management? My experience of
systems without virtual memory doesn't include any that shared
guessing. >>
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
Why would I want to use different address?
Memory overlap and fragmentation after having started and stopped
(or swapped out) too many processes. Remember, these were
physical-memory machines. You could load a process to a certain
place, but you had more running, and one of them was swapped out
or terminated, it left block of available memory where the next
process didn't necessarily fit.
They would have fared better by assigning a base register (or two,
one for data and one for code) invisible from problem state
and handled by the OS.
Not sure why they didn't do so, but
reading the literature seems to imply that they did not think it
through.
Now, of course, we have the benefit of hindsight.
On Sun, 30 Jun 2024 04:33:11 -0000 (UTC), Stephen Fuld wrote:
Lawrence D'Oliveiro wrote:
By the 1970s, CPU/RAM speeds had improved to the
point where copying records a few hundred bytes at a time between
buffers was not the performance bottleneck; disk I/O was.
Yes, but given multiprogramming, even in the 1970s, you would
typically have several batch programs running at the same time, so
during waits for I/O, another program could use the CPU. But using
the CPU to move records meant it couldn't be doing anything else at
the same time.
Scraping the bottom of the barrel, much?
Work out the numbers. The CPU time necessary to copy a single record
is most likely a small fraction of the time it takes to service an
I/O interrupt.
And this is not taking into account the fact that I/O interrupts run
at a higher priority than user-level tasks like copying buffers,
anyway.
On Sun, 30 Jun 2024 10:44:34 -0000 (UTC)
Thomas Koenig <[email protected]> wrote:
John Dallman <[email protected]> schrieb:
In article <87ed8e7os5.fsf@localhost>, [email protected] (Lynn
Wheeler) wrote:
back to IBM decision to add virtual memory to every 370 ... aka MVT
storage management was so bad that regions had to be specified four
times larger than used
What was the problem with the memory management? My experience of
systems without virtual memory doesn't include any that shared the
machine among several applications, so I have trouble guessing.
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
Why would I want to use different address?
The /360 tried to solve this via base pointers, which all addresses
were supposed calculated relative to to. Hence the RX and RS
instraction all had a base register + 12 bit offset for their
addressing modes - swapping out the base registers (if you knew
which ones they were, was this info in the executable?) should have
worked. But the SS instructions for decimal arithmetic did not have
base pointers, so that solution did not work in the general casse.
Going to virtual memory from the start would have saved the
base pointer issue, and would have allowed 16-bit displacements,
also saving registers in the case where 12-bit displacements were
not enough.
Michael S <[email protected]> schrieb:
On Sun, 30 Jun 2024 10:44:34 -0000 (UTC)
Thomas Koenig <[email protected]> wrote:
John Dallman <[email protected]> schrieb:
In article <87ed8e7os5.fsf@localhost>, [email protected] (Lynn
Wheeler) wrote:
back to IBM decision to add virtual memory to every 370 ... aka MVT
storage management was so bad that regions had to be specified four
times larger than used
What was the problem with the memory management? My experience of
systems without virtual memory doesn't include any that shared the
machine among several applications, so I have trouble guessing.
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
Why would I want to use different address?
Memory overlap and fragmentation after having started and stopped
(or swapped out) too many processes. Remember, these were
physical-memory machines.
You could load a process to a certain
place, but you had more running, and one of them was swapped out
or terminated, it left block of available memory where the next
process didn't necessarily fit.
They would have fared better by assigning a base register (or two,
one for data and one for code) invisible from problem state
and handled by the OS. Not sure why they didn't do so, but
reading the literature seems to imply that they did not think it
through. Now, of course, we have the benefit of hindsight.
In article <v5rcui$fqgj$[email protected]>, [email protected] (Thomas Koenig) wrote:
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
The /360 tried to solve this via base pointers, which all addresses
were supposed calculated relative to to. Hence the RX and RS
instraction all had a base register + 12 bit offset for their
addressing modes - swapping out the base registers (if you knew
which ones they were, was this info in the executable?) should have
worked. But the SS instructions for decimal arithmetic did not have
base pointers, so that solution did not work in the general casse.
And only a 12-bit offset, to boot. I've read of systems with base and
limit registers, where all accesses were offsets from the base (or
separate base registers for code and data). Real-mode 8086 code can work
that way, although I don't think you can limit the size of a segment to
less than 64KB. It looks as if /360 tried to construct that kind of
operation style from more general base register address modes, but
didn't do the job thoroughly.
Going to virtual memory from the start would have saved the
base pointer issue, and would have allowed 16-bit displacements,
also saving registers in the case where 12-bit displacements were
not enough.
Virtual memory was pretty new technology at the time, and required a
disk
or drum. The central idea of /360 was having the same ISA across a wide
range of machines, and virtual memory wasn't affordable at the low end
at the time, AFAICS.
So the problem wasn't with MFT memory management APIs or their implementation, but that a /360 site had to find a set of partition
sizes that allowed for all the combinations of programs that they needed
to
run simultaneously. This was inevitably wasteful of memory, because each partition had to allow for the largest program that could be required to
run in it.
Is that correct?
John
In article <v5rcui$fqgj$[email protected]>, [email protected]
(Thomas Koenig) wrote:
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
The /360 tried to solve this via base pointers, which all addresses
were supposed calculated relative to to. Hence the RX and RS
instraction all had a base register + 12 bit offset for their
addressing modes - swapping out the base registers (if you knew
which ones they were, was this info in the executable?) should have worked. But the SS instructions for decimal arithmetic did not have
base pointers, so that solution did not work in the general casse.
And only a 12-bit offset, to boot. I've read of systems with base and
limit registers, where all accesses were offsets from the base (or
separate base registers for code and data).
Real-mode 8086 code can
work that way, although I don't think you can limit the size of a
segment to less than 64KB. It looks as if /360 tried to construct
that kind of operation style from more general base register address
modes, but didn't do the job thoroughly.
Going to virtual memory from the start would have saved the
base pointer issue, and would have allowed 16-bit displacements,
also saving registers in the case where 12-bit displacements were
not enough.
Virtual memory was pretty new technology at the time, and required a
disk or drum. The central idea of /360 was having the same ISA across
a wide range of machines, and virtual memory wasn't affordable at the
low end at the time, AFAICS.
So the problem wasn't with MFT memory management APIs or their implementation, but that a /360 site had to find a set of partition
sizes that allowed for all the combinations of programs that they
needed to run simultaneously. This was inevitably wasteful of memory,
because each partition had to allow for the largest program that
could be required to run in it.
Is that correct?
[email protected] (Anton Ertl) writes:
John Levine <[email protected]> writes:
As I think I said before, these days you map the file into your
address space and read or write it like a long string, so its all
locate all the time.
Reading with mmap() appears to be quite common, either directly or
through libaries like glibc which use mmap() for buffered input where >>possible. For writing, using mmap() poses some difficulties:
* Writing to an mmap()ed region has weaker atomicity semantics than
write().
That depends - if all writers are using mmap, atomicity is provided
by other mechanisms (process-scope mutex, sysv or posix semaphores,
etc).
An application where one writes via mmap and others read
using stdio or read/write/pread/pwrite simulataneously
is poorly designed.
* mmap() works on pages (not in the interface, fortunately, but
internally), but for writing you want byte granularity. The
difference is not a big problem for reading, but it is a bigger one
for writing.
In my experience, mmap is most often used when record-granularity
is required, rather than treating the mapped region as a
stream-of-bytes.
* You have to extend the file length with a separate system call, and
then mmap() the new area, so you might just as well use write().
False economy. ftruncate is a single system call.
Thomas Koenig wrote:
They would have fared better by assigning a base register (or two,
one for data and one for code) invisible from problem state
and handled by the OS.
Precisely! This is what the, roughly contemporary, Univac 1108 did.
It
worked will for several decades. Eventually the 1108's successors went
to a paging scheme (but with ~ 16 KB pages), to avoid the fragmentation >issues from using variable sized chunks (called banks in 1100
terminology) of memory.
Lawrence D'Oliveiro wrote:
On Sun, 30 Jun 2024 04:33:11 -0000 (UTC), Stephen Fuld wrote:
Lawrence D'Oliveiro wrote:
By the 1970s, CPU/RAM speeds had improved to the
point where copying records a few hundred bytes at a time between
buffers was not the performance bottleneck; disk I/O was.
Yes, but given multiprogramming, even in the 1970s, you would
typically have several batch programs running at the same time, so
during waits for I/O, another program could use the CPU. But using
the CPU to move records meant it couldn't be doing anything else at
the same time.
Scraping the bottom of the barrel, much?
Work out the numbers. The CPU time necessary to copy a single record
is most likely a small fraction of the time it takes to service an
I/O interrupt.
And this is not taking into account the fact that I/O interrupts run
at a higher priority than user-level tasks like copying buffers,
anyway.
The thing you are missing is that (in the common scenario I was talking >about) locate mode costs absolutely zero. No overhead in the I/O
system, no changes to the source code, nothing. And not using it has
no, i.e. zero, advantages. So while the savings might be small, there
are no costs, so why no use it.
And BTW, not that it effects the calculation, but you only have one I/O >interrupt per physical block, not per logical record.
John Dallman wrote:
Virtual memory was pretty new technology at the time, and
required a disk or drum. The central idea of /360 was having
the same ISA across a wide range of machines, and virtual
memory wasn't affordable at the low end at the time, AFAICS.
But IIRC even low end S/360s required a disk, at least to IPL(boot)
from.
But Virtual memory is more expensive than the hidden base
registers, as you need page tables. probably a TLB, etc.
So the problem wasn't with MFT memory management APIs or their implementation, but that a /360 site had to find a set of
partition sizes that allowed for all the combinations of
programs that they needed to run simultaneously. This was
inevitably wasteful of memory, because each partition had
to allow for the largest program that could be required to
run in it.
Is that correct?
That is correct for OS/MFT, but not for OS/MVT.
In article <v5s173$jl70$[email protected]>, [email protected]d (Stephen Fuld) wrote:
John Dallman wrote:
Virtual memory was pretty new technology at the time, and
required a disk or drum. The central idea of /360 was having
the same ISA across a wide range of machines, and virtual
memory wasn't affordable at the low end at the time, AFAICS.
But IIRC even low end S/360s required a disk, at least to IPL(boot)
from.
Are you sure? Per Wikipedia, the lowest-end real S/360, the Model 30,
could run with only card equipment, running BPS, or with only tape
drives, under TOS.
John Dallman wrote:tape
Are you sure? Per Wikipedia, the lowest-end real S/360, the Model
30, could run with only card equipment, running BPS, or with only
drives, under TOS.You, and John are right. I got that wrong and apologize for doing
so.
John Dallman wrote:
In article <v5rcui$fqgj$[email protected]>, [email protected]
(Thomas Koenig) wrote:
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
The /360 tried to solve this via base pointers, which all addresses
were supposed calculated relative to to. Hence the RX and RS
instraction all had a base register + 12 bit offset for their
addressing modes - swapping out the base registers (if you knew
which ones they were, was this info in the executable?) should have
worked. But the SS instructions for decimal arithmetic did not have
base pointers, so that solution did not work in the general casse.
And only a 12-bit offset, to boot. I've read of systems with base and
limit registers, where all accesses were offsets from the base (or
separate base registers for code and data).
Yes, e.g. Univac 1108.
Are you sure? Per Wikipedia, the lowest-end real S/360, the Model 30,
could run with only card equipment, running BPS, or with only tape drives, under TOS.
<https://en.wikipedia.org/wiki/IBM_System/360_Model_30#System_software>
BOS was a really minimal OS for an 8KB RAM machine with one disc drive,
and DOS was less minimal.
The Model 30 was apparently one of the most popular machines in the early days of S/360. Being able to build such small machines was a strong commercial consideration for the company, and thus the architecture.
What was the problem with the memory management? My experience of systems without virtual memory doesn't include any that shared the machine among several applications, so I have trouble guessing.
Stephen Fuld wrote:
John Dallman wrote:
In article <v5rcui$fqgj$[email protected]>, [email protected]
(Thomas Koenig) wrote:
Imagine a process which resides at a certain address. It contains
code, data, and pointers to data. Now you swap it out and want
to reload it. You can use the same base address, then everything
is fine. Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
The /360 tried to solve this via base pointers, which all addresses
were supposed calculated relative to to. Hence the RX and RS
instraction all had a base register + 12 bit offset for their
addressing modes - swapping out the base registers (if you knew
which ones they were, was this info in the executable?) should have
worked. But the SS instructions for decimal arithmetic did not have
base pointers, so that solution did not work in the general casse.
And only a 12-bit offset, to boot. I've read of systems with base and
limit registers, where all accesses were offsets from the base (or
separate base registers for code and data).
Yes, e.g. Univac 1108.
S.E.L 32/65 but not 32/67 or 32/87
CDC 6600 7600
CRAY-1 1/S
Lawrence D'Oliveiro wrote:
On Sat, 29 Jun 2024 18:22:04 -0000 (UTC), John Levine wrote:
... more often than not locate I/O is faster and easier.
Given all the caveats and restrictions, “easier” is not how I would
describe it.
Again, it depends. For COBOL, you didn't have to specify anything. The compiler set up everything for you for you, and it "just worked".
Again, it depends. For COBOL, you didn't have to specify anything. The
compiler set up everything for you for you, and it "just worked".
Maybe it didn’t. Given the way locate-mode I/O is set up, it should >automatically fall back to copy-mode if the conditions are not right. So >maybe you were in fact using copy-mode, not locate-mode, most of the time, >without realizing it.
According to Lawrence D'Oliveiro <[email protected]d>:
Again, it depends. For COBOL, you didn't have to specify anything.
The compiler set up everything for you for you, and it "just worked".
Maybe it didn’t. Given the way locate-mode I/O is set up, it should
automatically fall back to copy-mode if the conditions are not right.
So maybe you were in fact using copy-mode, not locate-mode, most of the
time, without realizing it.
You know, you could admit that just once you're wrong.
On Tue, 2 Jul 2024 01:02:07 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <[email protected]d>:
Again, it depends. For COBOL, you didn't have to specify anything.
The compiler set up everything for you for you, and it "just worked".
Maybe it didn’t. Given the way locate-mode I/O is set up, it should
automatically fall back to copy-mode if the conditions are not right.
So maybe you were in fact using copy-mode, not locate-mode, most of the
time, without realizing it.
You know, you could admit that just once you're wrong.
Admit that you never checked whether locate mode was actually engaged or
not. You just assumed that it was.
On Tue, 2 Jul 2024 01:02:07 -0000 (UTC), John Levine wrote:
According to Lawrence D'Oliveiro <[email protected]d>:
Again, it depends. For COBOL, you didn't have to specify anything.Maybe it didn’t. Given the way locate-mode I/O is set up, it should
The compiler set up everything for you for you, and it "just worked". >>>>
automatically fall back to copy-mode if the conditions are not right.
So maybe you were in fact using copy-mode, not locate-mode, most of the >>>> time, without realizing it.
You know, you could admit that just once you're wrong.
Admit that you never checked whether locate mode was actually engaged or >>not. You just assumed that it was.
Huh, you can't admit you're wrong. Well, whatever.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 40:36:20 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,399 |