Talk:Single-level store

Is this memory-mapped I/O?

mmap call which is used for memory-mapped files works this way. Is this really the same principle?

Yes and no. All files are accessed via the data channel management, which optimally determines if the file should be fully buffered into RAM, accessed by the disk i/o controllers, or a combination of the two. This management of data resources is global, not by application or user, and dynamically being balanced continuously.

In most 'ordinary' systems (e.g. all variants of Unix), there is 'process memory/address space', which is really a very different kind of memory from files. Files (or portions of them) can be mapped into that address space, but the two are fundamentally different kinds of things. In SLS systems, there are no separate 'files' and 'process memory'; there are only segments, and a process' address space consists entirely of a collection of segments. Noel (talk) 16:32, 7 August 2014 (UTC)[reply]

paged virtual memory system?

How exactly is this distinguished from the (today) standard paged virtual memory system, as seen from a user process viewpoint? --ssd (talk) 04:12, 6 June 2013 (UTC)[reply]

See answer above; usually the segmentation is visible to the user code (e.g. pointers are two parts, a segment number and an offset within the segment, with a fixed boundary between them). Obviously, with a large enough single-space address spave (e.g. 64 bits) one could simulate segmentation, but up until now most systems that implemented SLS had hardware support for it, with two-part addresses. Noel (talk) 16:32, 7 August 2014 (UTC)[reply]

Necessary downtime.

There is a curious drawback to single-level store architecture, which was observed in practice at some of the very largest "beige box" a.k.a. CISC CPU AS/400 systems. Their total amount of 48-bit storage addresses was large but finite and in case of constant heavy system workload, it got filled up to 100% in app. 1.5 years of uptime, causing a halt and necessitating a reboot to return to work. IBM didn't anticipate that customers would treat the AS/400 as a "quasi mainframe" or "affordable Tandem Himalaya" and try to run it for 24 x 7 x Aeons (even neglecting the application of six-monthly OS/400 minor release updates, which would have guaranteed reboots at regular intervals, including the re-initialization of address space). When black-cased RISC CPU AS/400 systems arrived the address space was extended from 48 to 64 bits, which practically eliminated this problem. 158.88.16.2 (talk) 15:43, 29 August 2022 (UTC)[reply]

I saw something talking about this a while ago, but can't find it. I have the impression this is a consequence not just of single-level store, but of 1) persistent store addresses for files/objects (which Multics, for example, did not have - addresses were assigned when a segment was "initiated", i.e. mapped into the address space, and the assigned segment number became available when the segment was unmapped) and 2) a segmented address space, so that the size of the segment-number field mattered. At least at the hardware level, the 48-bit address was 32 bits of segment number and 16 bits of offset, so more than 2^32 (a little more than 4 billion) or so segments is a problem.

I also seem to remember that part of the problem was that segment numbers weren't reassigned, even for temporary objects, with a reboot being required to reclaim segment numbers for temporary objects.

So, while single-level store architecture with persistent addresses can run into this problem, depending on the design, it's not necessarily a problem that is inherent to single-level storage systems. Guy Harris (talk) 21:13, 29 August 2022 (UTC)[reply]

(The software may divide up 48-bit addresses differently, allowing fewer but larger objects, but the System/38 "native" instruction set, at least, has 16 16-bit "integer" (R) registers and 16 32-bit "segment identifier" (SID) registers, with the nth SID register and the nth R register acting together as the nth "base" (B) register, which contains an address. For example, the Load Halfword Register instruction specifies an R register as the destination and a combination of a B register and a 12-bit displacement as the source. Bitsavers doesn't have a manual for AS/400 IMPI, but if translated-to-IMPI MI code for S/38 didn't require a retranslation to run on a CISC AS/400, it presumably had to be binary-compatible with S/38 IMPI.) Guy Harris (talk) 21:48, 29 August 2022 (UTC)[reply]