Mainframe OS (uDOS v0.1)

[wxwisiasdf]

I see mainframes getting no love on the OSDev scene, very scarce number of OSes made by hobbysts for mainframes.

So I decided to give mainframe some love

Fully Public domain so other people can also give it some love:
https://github.com/SuperLeaf1995/uDOS

Try it out! (You'll need Hercules):
https://github.com/SuperLeaf1995/uDOS/releases

Then simply run it with:

Code: Select all

hercules -f hercules.cnf

[eekee]

Nice! What kind of mainframe does it run on?

I admit I don't often think of mainframes when I think of OS dev, but sometimes I do get a hankering for a wall of technology, preferably with spinning tape drives, and old-style terminals. Or maybe that one minicomputer with a chrome cabinet monitor and keyboard. I just don't have anywhere to put one.

[wxwisiasdf]

Nice! What kind of mainframe does it run on?

I admit I don't often think of mainframes when I think of OS dev, but sometimes I do get a hankering for a wall of technology, preferably with spinning tape drives, and old-style terminals. Or maybe that one minicomputer with a chrome cabinet monitor and keyboard. I just don't have anywhere to put one.

Somewhat like that!, but add 64-bits and the "modern" stuff

It runs on z/Arch (the modern mainframe, big blocks with no funny spinning drives or retro terminals), and on the s/390 (the one with the funny terminals & spinning disks).

I admit I don't often think of mainframes when I think of OS dev

Awww , that's unfortunate. But understandable since the only hobby OSes for mainframes are:
- ZZSA, which is some sort of recovery disk intended to rescue MVS3.8j systems?
- uDOS
- PDOS
- z/Linux, if you call that hobby
That's it, that's the whole mainframe scene, so yeah.

[linguofreak]

I see mainframes getting no love on the OSDev scene, very scarce number of OSes made by hobbysts for mainframes.

Pretty much a given, seeing that physical hardware has never been really accessible to hobbyists, and that emulators that would run on hobbyist-accessible hardware didn't really become available until mainframes were pretty much irrelevant by number of units shipped.

Though I probably would count academically-developed OS as "hobby" OSes at the mainframe scale: Among buyers that can afford mainframe hardware, academic institutions (and specifically the faculty and students of their CS departments) are the closest thing to "hobbyists" that you'll find. So that would include things like MTS (on IBM) and ITS (on the PDP-10, which is sometimes classified as a mainframe rather than a mini). Still not a lot of "hobby" OSes as the market was never very big.

I'd really like to see a hobby, or otherwise source-available OS for z/Archictecture that makes use of the access register feature of the architecture, given that it's a feature that exists pretty much nowhere else. z/Linux goes with the Unix flat address space paradigm, z/OS is not made available to hobbyist users running hercules, MTS / MVS / VM/370 etc. date back to before ESA/390 (or, in the case of late versions of MVS, is not available to hobbyist users).

[wxwisiasdf]

I see mainframes getting no love on the OSDev scene, very scarce number of OSes made by hobbysts for mainframes.

Pretty much a given, seeing that physical hardware has never been really accessible to hobbyists, and that emulators that would run on hobbyist-accessible hardware didn't really become available until mainframes were pretty much irrelevant by number of units shipped.

Though I probably would count academically-developed OS as "hobby" OSes at the mainframe scale: Among buyers that can afford mainframe hardware, academic institutions (and specifically the faculty and students of their CS departments) are the closest thing to "hobbyists" that you'll find. So that would include things like MTS (on IBM) and ITS (on the PDP-10, which is sometimes classified as a mainframe rather than a mini). Still not a lot of "hobby" OSes as the market was never very big.

I'd really like to see a hobby, or otherwise source-available OS for z/Archictecture that makes use of the access register feature of the architecture, given that it's a feature that exists pretty much nowhere else. z/Linux goes with the Unix flat address space paradigm, z/OS is not made available to hobbyist users running hercules, MTS / MVS / VM/370 etc. date back to before ESA/390 (or, in the case of late versions of MVS, is not available to hobbyist users).

MVS 3.8j and PDOS offers those features

[linguofreak]

I see mainframes getting no love on the OSDev scene, very scarce number of OSes made by hobbysts for mainframes.

Pretty much a given, seeing that physical hardware has never been really accessible to hobbyists, and that emulators that would run on hobbyist-accessible hardware didn't really become available until mainframes were pretty much irrelevant by number of units shipped.

Though I probably would count academically-developed OS as "hobby" OSes at the mainframe scale: Among buyers that can afford mainframe hardware, academic institutions (and specifically the faculty and students of their CS departments) are the closest thing to "hobbyists" that you'll find. So that would include things like MTS (on IBM) and ITS (on the PDP-10, which is sometimes classified as a mainframe rather than a mini). Still not a lot of "hobby" OSes as the market was never very big.

I'd really like to see a hobby, or otherwise source-available OS for z/Archictecture that makes use of the access register feature of the architecture, given that it's a feature that exists pretty much nowhere else. z/Linux goes with the Unix flat address space paradigm, z/OS is not made available to hobbyist users running hercules, MTS / MVS / VM/370 etc. date back to before ESA/390 (or, in the case of late versions of MVS, is not available to hobbyist users).

MVS 3.8j and PDOS offers those features

I thought the sufficiently late versions of MVS were not hobbyist available?

[wxwisiasdf]

I thought the sufficiently late versions of MVS were not hobbyist available?

Oh yeah my bad, sorry, in such a case z/PDOS is the only MVS-like OS for the mainframe right now that runs on modern machines (it does not replicate z/OS).

[eekee]

Somewhat like that!, but add 64-bits and the "modern" stuff

It runs on z/Arch (the modern mainframe, big blocks with no funny spinning drives or retro terminals), and on the s/390 (the one with the funny terminals & spinning disks).

Ah, fun!

@linguofreak: Relevance isn't a consideration for every OS dev, but yeah, the rarity of mainframes must have a lot to do with it. The few hobbyists who have one are likely to be into retrocomputing and want to run the old OSs, so when it comes to new software, 2 new OSs, 1 port and a maintenance tool is pretty good.

[linguofreak]

wxwisiasdf : Do you know if there are any freely-available compilers (for any language) for S/390 / z/Arch that make use of the access-register feature? GCC almost certainly deals only with a flat address space, and I imagine that whatever IBM uses to write z/OS, etc. is proprietary and quite expensively licensed.

[wxwisiasdf]

wxwisiasdf : Do you know if there are any freely-available compilers (for any language) for S/390 / z/Arch that make use of the access-register feature? GCC almost certainly deals only with a flat address space, and I imagine that whatever IBM uses to write z/OS, etc. is proprietary and quite expensively licensed.

I only know of GCCMVS, it allows you to inline HLASM assembly onto it, there are also PL/I and FORTRAN compilers available for TK4 and MVS3.8J, all of that is free - however I don't know if they use access registers when compiling. z390 might use it but I haven't checked. I think you mostly have to do it by hand on HLASM. Since most compilers apparently assume only a single address space is used.

[linguofreak]

wxwisiasdf : Do you know if there are any freely-available compilers (for any language) for S/390 / z/Arch that make use of the access-register feature? GCC almost certainly deals only with a flat address space, and I imagine that whatever IBM uses to write z/OS, etc. is proprietary and quite expensively licensed.

I only know of GCCMVS, it allows you to inline HLASM assembly onto it,

I'm not really counting inline assembly, because even though that would allow you to load access registers, you'd then be presenting the compiler with an environment that it wouldn't know how to deal with.

there are also PL/I and FORTRAN compilers available for TK4 and MVS3.8J, all of that is free - however I don't know if they use access registers when compiling. z390 might use it but I haven't checked. I think you mostly have to do it by hand on HLASM. Since most compilers apparently assume only a single address space is used.

Yeah, pretty much what I'm afraid of.

I wonder if one could port OpenWatcom or something: having roots in the segmented x86 era, it knows how to deal with non-flat addressing...

[kerravon]

I wonder if one could port OpenWatcom or something: having roots in the segmented x86 era, it knows how to deal with non-flat addressing...

I'm not familiar with access registers, but I am familiar with normal S/370 code and also 8086 code.

SubC is getting some work done on it, and supports 8086. Although only small memory model so maybe that doesn't count?

For what reason do you want non-flat addressing?

[linguofreak]

I wonder if one could port OpenWatcom or something: having roots in the segmented x86 era, it knows how to deal with non-flat addressing...

I'm not familiar with access registers, but I am familiar with normal S/370 code and also 8086 code.

SubC is getting some work done on it, and supports 8086. Although only small memory model so maybe that doesn't count?

For what reason do you want non-flat addressing?

So ESA/390 and zArchitecture have "access registers" that allow a program to access multiple address spaces at the same time. It's kind of like x86 protected-mode segmentation, except that:

1) Unlike x86 segmentation, the address spaces are paged address spaces, not base+offset segments
2) The way the equivalents to the segment descriptor tables are defined, it's equivalent to the situation on x86 if programs couldn't load segments directly from the GDT, and if there was an extra LDT (let's call it LDT2), and if loading a new segment into CS caused an automatic LDT1 switch, while loading a new segment into SS caused an automatic LDT2 switch.

So why is this significant?

1) is just more performant than x86 segmentation if you want non-flat addressing.

But why do you want non-flat addressing? This is where 2) comes in:

Non-flat addressing by itself doesn't get you anything, but implementing it as in 2) turns your "segments" into capabilities at a granularity that I think is a lot more workable than other capability architectures I've seen (a lot of capability architectures try to do it at per-pointer granularity, which I think adds too much overhead.

But why do you want capabilities?

My opinion is that, if implemented in hardware at appropriate granularity, they're the secret to a really performant microkernel. This post in this thread outlines why I think the typical "every OS service in its own process" microkernel model is suboptimal, and a z/Architecture-style address-spaces-as-capabilities model is what I allude to when I say "There are ways hardware could be designed to allow services to still be called as libraries while isolating them not only from userspace but from each other, but such designs are not currently common."

Without having a good understanding of how the z/Architecture access register feature worked, I spent a number of years pondering why flat address spaces aren't good for microkernels, why x86 segmentation doesn't solve that problem, and what changes to x86 segmentation would be necessary to solve it (or, in general, what sort of MMU architecture would solve it). I eventually arrived at something that seemed to solve all the issues, and some time later I actually read through the sections of the z/Architecture principles of operation relevant to the access register mechanism, and found that it was quite close to what I had thought up.

So now, knowing that there's an architecture out there that has the sort of MMU I want, it would be really nice to find a non-proprietary HLL compiler that could make use of it.

[kerravon]

So now, knowing that there's an architecture out there that has the sort of MMU I want, it would be really nice to find a non-proprietary HLL compiler that could make use of it.

Thanks for your thoughts.

There is a new C compiler being actively worked on:

https://github.com/wxwisiasdf/cc23/tree/master

It is already generating S/370 code (but be clear, it is still in the middle of development - nearly 6000 lines of code so far), and the author (the OP in this thread actually) has agreed to add 8086 huge memory model support.

Sounds like you should ask him if he can support what you're after. He is documenting progress in the discord channel pointed to from http://pdos.org

BFN. Paul.

[linguofreak]

It is already generating S/370 code (but be clear, it is still in the middle of development - nearly 6000 lines of code so far), and the author (the OP in this thread actually) has agreed to add 8086 huge memory model support.

I mean, he's the guy I originally asked if he knew about any mainframe compilers that made use of access registers, so he already knows that there's at least one person that would like access register support. I myself wouldn't go so much for the larger memory models (since you aren't going to need non-flat addressing for the sole purpose of gaining extra address space with 64-bit addressing, and probably not with 31-bit addressing either), but would be mostly interested in seeing a small memory model (all pointers near by default) with support for explicitly declared far pointers, and for something like OpenWatcom based pointers (section 7.3.3 in the OW C Language Reference).