The Talos II, Blackbird POWER9 systems support tagged memory
devever.net
devever.net
1. This point is worth drawing attention to; the abstraction of the machine's ISA was so effective in the case of the AS/400 that IBM never even documented the CPU's ISA, nor did they need to. Supposedly, the ISA was System 360-like.
2. The fact that AS/400 and its predecessor System/38 significantly predate Java demonstrates that there really is no “new” idea in computer science that IBM wasn't doing in the 70s, an observation I've become fond of. The explosion of “virtualisation” in IT in the 2000s/2010s is another example; to my knowledge, hardware virtualisation was first invented by IBM in the System 370.
Not every innovation happened at IBM first back in those days, any more than they happened at Microsoft first in the '90s, even if IBM (and Microsoft) were more successful at capitalizing on the innovations of others due to the advantage of being well-capitalized second movers.
This means that applications that bond channels together and read/write/ECC-check in 64-bit chunks can have 8 unassigned bits per 80-bit read, while still ECC protecting the full width. I haven't seen any discussion of this capability, but it's super interesting to me.
Hi, could you explain what it was that made them so good to do this, thanks.
The integral database, too?
"The term originally referred to what is now usually called virtual memory"
And seems to lead on to memory mapped files, so nothing apparently significant AFAICS.
I'll check out your slic link, thanks.
"With a single-level storage the entire storage of a computer is thought of as a single two-dimensional plane of addresses, pointing to pages. Pages may be in primary storage (RAM) or in secondary storage (disk); however, the current location of an address is unimportant to a process. The operating system takes on the responsibility of locating pages and making them available for processing. If a page is in primary storage, it is immediately available. If a page is on disk, a page fault occurs and the operating system brings the page into primary storage. No explicit I/O to secondary storage is done by processes: instead, reads from secondary storage are done as the result of page faults; writes to secondary storage are done when pages that have been modified since being read from secondary storage into primary storage are written back to their location in secondary storage."
IOW this is classic VM behaviour. Which bit of the wiki article is revelatory?
(NB. I've actually used multics).
With single level store, the program pages are mapped in, not copied. Writing to the page alters the disk image. All processes running the same program share the memory pages.
Umm, mmap'ed files on linux allow both https://www.man7.org/linux/man-pages/man2/mmap.2.html
MAP_SHARED
Share this mapping. Updates to the mapping are visible to
other processes mapping the same region, and (in the case
of file-backed mappings) are carried through to the
underlying file. (To precisely control when updates are
carried through to the underlying file requires the use of
msync(2).)
MAP_PRIVATE
Create a private copy-on-write mapping. Updates to the
mapping are not visible to other processes mapping the
same file, and are not carried through to the underlying
file. It is unspecified whether changes made to the file
after the mmap() call are visible in the mapped region.
The truth is, most of us that worked on top of OS/400 do not really know what a lot of this means ... just that it is good because IBM told us it was :)
In a way, that is what made this a great place to develop applications. You work in RPG (some use COBOL) in languages that are purpose built for working with the built-in database and do not worry about things like memory and where things are stored. The runtime environment and OS handle those details.
I was employee 1 at an ISV that made "Change Management" application, what would we be called DevOps today. The way the OS treats everything as objects that have properties we can manipulate and move around was just cool. It was just so straight forward to manage the applications people were creating and deploying, it is hard to explain because it is very different from the *nix/Windows world of how it is done. Even mainframe is not quite the same.
The overall system was ahead of its time in many ways. Recall arriving at work in AM (tiny company in a small town) and walking in and having our IBM rep also arrive. Ask why he is there? The system phoned home (via mode) to let IBM know a disk was failing. He has replacement with him to swap in.
These systems were expensive, especially for a small company. Recall we had to get a loan so we could buy a tape drive for $25K so we could then put our software onto $50 tapes that we had to mail to customers to let them try or update the software. Some of our bigger customers needed their tapes on a drive that was more like $100K to buy. Thankfully, there were other AS/400 customers within driving distance that would let us come over a couple of times a month and copy our software onto tapes using their drives.
When CD-ROM finally became standard it became a god-send for our business.
AFAIR, IBM used drives with 520 byte sectors. 512 bytes were the actual data. The remaining 64 bits were used to set tags in memory accordingly (you can fit 32 16-byte pointers in the sector, so each pointer had two tag bits and both had to be on for the pointer to be deemed valid). I thought that there was a special instruction to set all of a 512 byte memory region's tags at once. I don't see it mentioned. Maybe it's only a virtual instruction and it's implemented by just a bunch of SETTAG/STQ, which would destroy performance or negate most of the benefits of DMA I/O (you could skip this step if you know the block has no pointers...). You need to extract the tags from memory, pack them and save them separately when writing to persistent storage, of course.
It's correct that IBM originally used custom IBM disk drives with 520-byte sectors. I believe 528 byte sectors were also seen where both tags and parity (for some RAID-like technology, I don't recall the details) were desired. On devices with a 4096 byte sector size, this leads to equivalent sector sizes of 4160 or 4224 bytes respectively.
Nowadays you can also run IBM i on virtualised disks provided by IBM's Virtual I/O System (VIOS) under PowerVM. VIOS is AIUI basically a customised AIX install which runs as a VM under PowerVM and provides I/O functionality similar to that provided by a Xen dom0. In this case things are virtualised on top of normal hard drives with 512 byte sectors, so it's possible for these weird sector sizes to be emulated nowadays.
I believe you can still pass a hard drive directly to an IBM i VM, though, and that IBM still offers hard drives with these special sector sizes for this purpose. Of course IBM doesn't make drives nowadays, so these are obviously an IBM rebrand of some other manufacturer's hard drives.
What's really interesting though is that if you read the manuals for modern hard drives (yes, hard drives have manuals, who knew?), many of them advertise a selectable sector size, where you can reformat the drive to a new sector size. For example, see this manual, which says you can select a sector size of 512, 520, or 528 bytes (or 4096, 4160 or 4224 bytes): https://www.seagate.com/www-content/product-content/enterpri...
So theoretically most modern hard drives can be reformatted to support IBM i. I believe this functionality is also maintained to support modern hardware RAID systems, though.