On Monday, September 26, 2022 at 2:03:43 AM UTC-7, Lewis Cole wrote:
> As Mr. Fuld and Mr. Schroth said, welcome.
> Some piddly points of no real importance as the Really Important Stuff you probably need to know is coming from Mr. Fuld and Mr. Schroth (and probably Mr. Gunshannon Real Soon Now).
>
> 1. You mentioned the fact that Once Upon a Time, there used to be a Unix variant, SX-1100, that ran on top of OS1100 at Bell Labs (BELLCORE).
> You also mentioned that it had a "poor reputation for performance".
> I would like to point out that at the time (pre-1100/90 IIRC), I think that 1100 hardware was still running at only a few MIPS at best.
> To paraphrase Samuel Johnson, "If you see a dog's walking on his hind legs, it may not do so very well, but what you should be surprised at is that it is done at all."
>
> 2. As Mr. Schroth noted, the OS1100/OS2200 file system was (is?) a flat file system with program files just happening to have an internal structure that makes them look like they are a subdirectory.
> But just in case you haven't run into it yet, there were (are?) also file cycles (F-cycles) so that there can be multiple instances of a file with the "same" name.
> If you want to learn more about the joys of basic OS1100/OS2200 speak, I would recommend that you take a look at Volume 2 of one of the old Exec Programmer Reference Manuals like this one for Exec 36R2:
>
> < http://bitsavers.org/pdf/univac/1100/exec/UP-4144.23_R36r2_Executive_System_Vol_2_Jan80.pdf >
>
> Yes, I know it's older than dirt, but AFAIK, it's still applicable to today's OS2200 thanks to the joys of Backward Compatibility.
>
> 3. You mention file access being controlled via read/write keys.
> Well, things may have changed, but that isn't (or wasn't) the only way file access could be controlled.
> Once Upon a Time, a branch of OS1100 was hardened to be compliant with the B-1 Security Standard (the Orange Book?).
> AFAIK, this is just about as good as it gets in terms of security.
> (I think Microsoft at one time came up with some that was C-2 compliant.)
> So at least at one time, access could be controlled by ACRs as well as read/write keys.
>
> 4. From your previous questions, I suspected that you were probably writing some kind of article, especially based on your question about what were the most common programming language that programs running on OS2200 are written in.
> To be honest, I wasn't quite sure what you were getting at and to be quite honest, I not sure I do yet.
>
> To try to be clear on my part, every customer in sight since close to the beginning of time has wanted computers that supported high level languages so that they (the customers) could supposedly write machine independent code ... at least before they started using the machine specific language features that tied them in to one family of machines.
> No doubt in an attempt to keep its customers "happy", Univac/Sperry Univac/Sperry/Unisys provides and supports, and will continue to provide and support high level languages like COBOL, Fortran, and C or whatever other languages become the Language Du Jour so long as the Company exists.
>
> But the fact of the matter is that a lot of code from the Good Old Days which was and still is 1100 assembly language code, and is still presumably very much supported (even if its use is not really encouraged).
> If that wasn't the case, then the Company could have gotten rid of what amounts to an entirely different machine (a "Basic Mode" machine) that's tacked onto a newer machine with a similar architecture (an "Extended Mode" machine) which the OS switch between by way of a mode bit in the Unisys version of a PSW (DB16 in the Designator Register AKA DR).
> Also in addition to old Dusty Deck code, I suspect that a lot of Transaction Processing development is still actively being done in assembly language.
> Of course, if Mr. Fuld or Mr. Schroth say that I'm full of shit, I will defer to them and say that you should believe them, but my point is that I suspect that assembler is still very much alive and well as far as OS2200 is concerned and should be in your list.
>
> Also, in addition to assembly, COBOL, Fortran, and C, there's also the matter of what amounts to another Univac/Sperry Univac/Sperry/Unisys language known as Mapper (which I see you reference in the second part of your series).
> Mapper was renamed long, long ago to BL- or BS- something-something-something and was even ported to non-Univac/Sperry Univac/Sperry/Unisys machines..
> Considering that the Company once sort of tailored one of its 1100 systems to primarily run Mapper (i.e. a variant of the 1100/50 was referred to as Mapper10), I suspect that Mapper should also be added to your list.
>
> As for other languages that were customer written and not supported by the Company, there used to be a Pascal, a PL/1 variant (PLUM), and a LISP (written in Pascal IIRC).
> While they aren't Company processors, presumably they stand a decent chance of still running on an Dorado.
>
> 5. I think you are confusing the Unisys 2200 emulator software that the Company uses on its Intel boxes with PS/2200.
> Although it's been a few years now since I used PS/2200, I can definitely say that at the time I used it, it was *NOT* an emulator.
> It couldn't be.
> The host OS (Windows) prevented time keeping on the 1-usec granularity that the original M-Series dayclock hardware could deliver and so if you just left the simulated system run for awhile, its sense of wall time quickly went out of sync with actual wall time, making PS/2200 at best a simulator rather than an emulator.
> It's my understanding that the Company emulator basically runs on top of a Linux based hypervisor which presumably is in close communication with the guest OS.
> Again, I will defer to Mr. Fuld and Mr. Schroth if they say something different.
>
> 6. I think you haven't quite gotten a handle on the finer points of the basic 2200 Series IP (AKA CPU) architecture.
> So here are a few things that I'll throw at the wall for your consideration.
>
> * No, not all registers are visible in the (virtual) address space.
> The General Register Set (GRS) is divided into a User set and an Exec set, the visibility of which is determined by a mode bit (DB17).
> Even so, some instructions specify a register using a GRS offset (by combining the J- and A-fields of an instruction as in the case of the JGD instruction) and so are *NOT* affected by the mode bit, except to say that if you're a User and you try to access an Exec register, you won't get there from here but instead will take an interrupt.
> Furthermore, in the Good Old Days, there were some registers that were specifically for Exec use only and so you couldn't access them either no matter how tricky you might get.
> (They've largely/entirely disappeared.)
> And I think the rules for indirect addressing sometimes always reference storage rather than GRS no matter what, but I could be wrong.
>
> * There are basically three (3) kinds of registers in each of the two register sets in GRS: index registers (X-registers), accumulators (A-registers), and repeat counters (R-registers).
> To me, that's not all that "complex".
> I mean, the MC68000 used to have two (2) kinds of registers, index registers (A-registers) and accumulators (D-registers) and yet I don't recall the 68K architecture as being "complex".
>
> * When you compute the effective address of a "storage operand" whose value is less than 0200 (that's octal 0200), the processor *MAY* refer to a GRS register depending on the type of instruction being executed.
> Some instructions will *ALWAYS* reference storage no matter what, while some will reference a GRS register (assuming that you have the appropriate processor privilege to get there from here) if you're running in Basic Mode or if you're running in Extended mode and the B-register specified in the instruction is zero (AKA B0).
>
> * I would quibble about how you describe the address of a storage operand..
> Assuming that we're not talking about a literal/immediate value, it's specified by an offset (u) and an index value from an index (X-) register in Basic Mode or an offset (u) and index value from an index (X-) register and base value (from a Base [B-] register) in Extended Mode.
> The size of the offset varies between Basic mode and Extended mode, and there's a mode bit that controls the size of the index value (DB11) if you're the Exec (DB14 || DB15 < 2).
> In the Good Old Days, the effective address U was turned directly into an actual storage address (called an absolute address) via the additon of the base value from a base register, but since the introduction of M-Series (the 2200/900 and 2200/500) the absolute address specifies a location in a paged absolute address space and not an actual storage address.
> Paging hardware translates the absolute address into an actual storage address (called a real address) although on the emulated hardware, it's the host hardware that does the address translation.
> IOW, in the Good Old Days, 1100/2200 hardware used two layers of address translation, while the newer hardware uses three layers of address translation.
>
> * As Mr. Schroth has noted, OS1100/2200 basically uses Fieldata (6-bit characters) internally.
> The architecture just happens to support reading and writing sixth words which is to say 6-bits which is "nice".
> But the architecture also supports reading and writing either third words (12-bits) or quarter words (9-bits) based on the setting of a mode bit (DB32).
> I mention this because to the extent that the hardware supports a character other than Fieldata, that character is 9-bits wide, not 7-bits which is of course ASCII or 8-bits which is of course ANSI or one of the other 8-bit encodings.
> This something you need to be careful about if you're coming from an 8-bit byte addressable machine and if you happen to be conditioned to think that your characters are basically either 7-bits or 8-bits wide in an 8-bit cell.
>
> * Mr. Schroth said that arithmetic operations can't return a negative zero.
> Normally, you should always trust what Mr. Schroth says instead of what I say, but in this case, Mr. Schroth is mistaken as any of the IP PRMs indicate in their discussion of negative zero.
> In particular (-0) + (-0) = (-0) and (-0) - (+0) = (-0).
> But the only way for -0 to show up in such an operation is if a programmer to do something to explicitly put it there in a register, such as (I think), doing a load negative immediate of a positive zero before the arithmetic operation (e.g. "LN,U A0,0") which is kinda stupid.
>
> 7. Maybe I'm taking this all wrong, but I get the sense in the third part of your series that you're slamming OS2200 because you're having trouble coding up your Robot Finds Kitten app in C.
> I think this is more than a little unfair/biased as by pretty much by definition, there's no such thing as "standard I/O" that's part of the C language itself.
> Yes, there are I/O libraries, but in effect you seem to be assuming that all systems that support C must also have equivalent I/O devices which is not the case.
> I doubt that you could get your Robot Finds Kitten app running on an Atmel 8-bit AVR based system even though I'm sure that there's a C compiler for it.
> IOW you seem to be trying to construct a toy application that might be trivial on x86-64 box, but doing so on an OS2200 system doesn't pass the "So What?" test for me except to the extent that you're deliberately trying to suggest that 1100/2200 Series systems are not just weird, but also severely lacking in capability.
> My apologies in advance if this was not your intent.

I'm terribly sorry if it somehow came across like I was slamming OS 2200 in part 3. On the contrary, I'm very much enjoying OS 2200; I find it to be a well-thought-out platform, with good interfaces to the user and the programmer, and I don't know what I wrote that gave the impression that I was attacking the 2200 system.

I sincerely thank you for the rest of your informative post.