OS Design for Hercules

Tim Pinkawa

Sep 16, 2007

Some of the discussions on the list over the past week have sparked
interest in trying to write something very basic that I can IPL
Hercules with.

In the simplest terms, I believe I would need an assembler that
outputs plain object code, correct? Is there an easy (and free) way to
develop this on an x86 PC and test with Hercules or would I need to
use something like IFOX00 and transfer the object code back to my PC
to test?

I've never really done anything like this before so I apologize for
the dumb questions. :)

Tim

7:33 pm

Re: OS Design for Hercules

Roger Bowler

Sep 16, 2007

--- In hercules-390@yahoogroups.com, Tim Pinkawa wrote:
> Some of the discussions on the list over the past week have sparked
> interest in trying to write something very basic that I can IPL
> Hercules with.

I'm pleased to see some interest in this. It was exactly what I had in
mind in 1999 when I said "You will have to write the operating system
or standalone program yourself, unless you can manage to obtain a
license from IBM to run one of their operating systems on your PC"
- http://www.hercules-390.org/hercfaq.html#1.02

When I wrote those words 8 years ago, I did imagine that Hercules
might inspire a few people to write some kind of standalone program or
operating system, spurred on by the non-availability of IBM software
licenses for personal use. However it did not work out like that in
practice.

So I was delighted to read Josef Sipek's recent message describing his
experiments in this area
- http://tech.groups.yahoo.com/group/hercules-390/message/51518

> In the simplest terms, I believe I would need an assembler that
> outputs plain object code, correct?

Well, the assembler outputs object deck format (80 byte card images),
which isn't exactly plain object code, but is usable as an IPL deck
for standalone programs if you stick a 3-card loader on the front of
it [1]

> Is there an easy (and free) way to
> develop this on an x86 PC and test with Hercules or would I need to
> use something like IFOX00 and transfer the object code back to my PC
> to test?

One way would be to do the assemblies with IFOX00 on MVS 3.8 and punch
the output directly to a file on your PC, by coding PARM='DECK,NOLOAD'
(or is it NOOBJECT which replaced NOLOAD at some point) and by coding
a //SYSPUNCH DD UNIT=00D statement, where 00D is defined as a card
punch (00D 3525 /home/tim/ipldeck.ebcdic) No need for a separate
MVS-to-PC transfer. You could punch the 3-card loader to 00D in a
preceding IEBGENER step.

Alternatively, some time back Harry Wahl was talking about a method of
generating standalone object code from a C program on the PC, but I
never saw this thing in action.
- http://tech.groups.yahoo.com/group/hercules-390/message/42652

Regards,
Roger Bowler
Hercules "the people's mainframe"

[1] I think the 3 card loader can be found somewhere in SYS1.SAMPLIB
Lynn Wheeler has an article about it:
- http://www.garlic.com/~lynn/2007f.html#1

9:36 pm

Re: OS Design for Hercules

Tim Pinkawa

Sep 17, 2007

Thanks for the help, everyone! I've been going off Jeff's code, some
of Rafael's code, and the Principles of Operation trying to figure
this out. At the moment I'm using xdd to dump ASCII hex to binary
files.

I've been trying to get the three card loader working, but my IPL has
been failing.

HHCCP029E S/370 mode IPL failed: CSW status=0E40
Sense=80000000

Card 1:

PSW:
000C000080000018

This is based off Jeff's code with some minor modifications. Since I
have a program on card 2, I set the next instruction to 0x18 which
should be the first byte of the second card, assuming the PSW, CCW 1,
and CCW 2 occupy the first 24 (0x18) bytes.

CCW1:
0200001860000050

Read 80 bytes, store at location 0x18. This card has a small loop program.

CCW2:
0200006860000050

Read 80 bytes, store at location 0x68. This card is just a dummy card
filled with 0x40.

The rest of the first card is filled with 0x40.

At this point, I think I should have cards 2 and 3 (160 bytes of data)
in memory beginning at 0x18. The CPU should branch to 0x18 and start
executing my code and go into an infinite loop. This is merely what I
THINK should be happening, apparently it's not.

I have a feeling I'm not understanding some part of this with relation
to where stuff ends up in memory. Anyone have an idea what I'm trying
to get at? :)

Thanks,
Tim

2:06 am

Re: OS Design for Hercules

Tony Harminc

Sep 17, 2007

On 16/09/2007, Tim Pinkawa <timpinkawa@...> wrote:

> I've been trying to get the three card loader working, but my IPL has been
failing.

I gather you've got this resolved, but just a suggestion...

Stay well away from low core except for those things that have to be
there. You can directly address higher address in CCWs, and you can
set up a base register in your code right at the start using BALR or
the like (you don't have to save your caller's registers because you
weren't exactly called...). So load your code out of the way of
nasties like the interval timer and the various old PSWs and related
baggage that may "happen" to you if you are down in the bottom 1K or
so.

Tony H.

6:00 pm

Re: OS Design for Hercules

Harold Grovesteen

Sep 18, 2007

The area from 0x200-0x11FF (4K) is available for programming.
0x1200-0x13FF is the z/Architecture Store-Status/Machine-Check save
area. You are safe to use from 0x1400 and above. Prefixing will drive
its own set of issues, but these values are safe in the context of a
single running CPU as is the case after IPL.

Harold Grovesteen

Tony Harminc wrote:

> On 16/09/2007, Tim Pinkawa <timpinkawa@...
> <mailto:timpinkawa%40gmail.com>> wrote:
>
> > I've been trying to get the three card loader working, but my IPL
> has been failing.
>
> I gather you've got this resolved, but just a suggestion...
>
> Stay well away from low core except for those things that have to be
> there. You can directly address higher address in CCWs, and you can
> set up a base register in your code right at the start using BALR or
> the like (you don't have to save your caller's registers because you
> weren't exactly called...). So load your code out of the way of
> nasties like the interval timer and the various old PSWs and related
> baggage that may "happen" to you if you are down in the bottom 1K or
> so.
>
> Tony H.
>
>

10:53 am

Re: OS Design for Hercules

Josef Sipek

Sep 18, 2007

On Tue, Sep 18, 2007 at 05:53:37AM -0500, Harold Grovesteen wrote:
> The area from 0x200-0x11FF (4K) is available for programming.

That's just far too painful. In my design, I decided to have the 0-8K area
per-cpu via prefixing (I haven't looked into it more as I want to have the
thing running on one cpu first).

> 0x1200-0x13FF is the z/Architecture Store-Status/Machine-Check save
> area. You are safe to use from 0x1400 and above. Prefixing will drive
> its own set of issues,

Oh? Like what?

Josef 'Jeff' Sipek.

--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan

1:20 pm

Re: OS Design for Hercules

Harold Grovesteen

Sep 19, 2007

When you assign multiple prefix areas to different CPU's, the prefix
area of one CPU is physically available to the other CPU's, just at
their normal real==absolute addresses. So the program running needs to
understand where all of the prefix areas are physically located and that
when it mucks around with its own swapped region it is really mucking
around with absolute 0-4095 (or 0-8191) as seen by the other CPU's in
some other spot. In other words, what is safe for your program (from
the perspective of the assigned storage locations) is really a whole lot
more complicated when prefixing enters the picture.

By the way, read the sections on interrupts. You need to understand
interrupts to do any of this work.

Harold Grovesteen

Josef Sipek wrote:

> On Tue, Sep 18, 2007 at 05:53:37AM -0500, Harold Grovesteen wrote:
> > The area from 0x200-0x11FF (4K) is available for programming.
>
> That's just far too painful. In my design, I decided to have the 0-8K area
> per-cpu via prefixing (I haven't looked into it more as I want to have the
> thing running on one cpu first).
>
> > 0x1200-0x13FF is the z/Architecture Store-Status/Machine-Check save
> > area. You are safe to use from 0x1400 and above. Prefixing will drive
> > its own set of issues,
>
> Oh? Like what?
>
> Josef 'Jeff' Sipek.
>
> --
> Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are, by
> definition, not smart enough to debug it.
> - Brian W. Kernighan
>
>

10:38 am

Re: OS Design for Hercules

Josef Sipek

Sep 19, 2007

On Wed, Sep 19, 2007 at 05:38:44AM -0500, Harold Grovesteen wrote:
> When you assign multiple prefix areas to different CPU's, the prefix
> area of one CPU is physically available to the other CPU's, just at
> their normal real==absolute addresses. So the program running needs to
> understand where all of the prefix areas are physically located and that
> when it mucks around with its own swapped region it is really mucking
> around with absolute 0-4095 (or 0-8191) as seen by the other CPU's in
> some other spot. In other words, what is safe for your program (from
> the perspective of the assigned storage locations) is really a whole lot
> more complicated when prefixing enters the picture.

It sounds like if you want to load-balance interrupt handlers, you have to
use prefixing.

> By the way, read the sections on interrupts. You need to understand
> interrupts to do any of this work.

I know. And I know interrupts will not be fun to deal with, but it needs to
be done.

Josef 'Jeff' Sipek.

--
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein

5:49 pm

Re: OS Design for Hercules

Ivan Warren

Sep 19, 2007

Josef Sipek wrote:
>
> It sounds like if you want to load-balance interrupt handlers, you have to
> use prefixing.
>
>
Nah nah nah...

PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
multi CPU environment.

Ok.. Here is a crash course on interrupts..

How interrupts are distributed among CPUs is not controlled by prefixing
but by the architecture and by CPU interrupt masking & subclass masking.

Interrupts come in 2 flavors : Floating and non-floating. Floating
interrupts are interrupts that can trigger a PSW switch on any
operational CPU in a configuration. Notably, I/O interrupts are floating
(and only in S/390 & z/Arch).. Some Machine Checks may also be floating
(External Damage may be floating).

There are 6 classes of interrupts :
- Program Interrupt : They relate to an exception or condition
encountered during execution of an instruction. They may be related to
the operation code, operation parameters, address translation, tracing,
etc..
- SVC Interrupt : Every time the SVC instruction is executed
- I/O : Pertains the a device meaning to present some status to the CPU
- which may be solicited - the result of an ongoing I/O operation, or
unsolicited (Attention or not-ready to ready state switch)
- External : Various non-damage conditions : Timing, inter-cpu
communication, Service Processor communication, the 'External' operator
button, etc.. (there are more)
- Machine check : Various possibly damage conditions : System damage,
instruction damage, External Damage (I/O damage goes there IIRC) and
some non damage conditions such as I/O reconfiguration.. Machine check
may also be presented to indicate an error occurred but was fixed
internally like when a single bit error in storage was fixed by ECC.
- Restart : Operator initiated non maskable interrupt (depending on the
Operating System, this may be used to trigger a dump when the system has
entered a disabled loop). Note that the RESTART new PSW is at the same
location as the IPL PSW - which means that on simple IPLable programs,
RESTART will actually restart the program from the beginning !

Now.. Interrupts are not THAT complicated. Some interrupts are
synchronous (and deal with the execution of instructions). These are the
Program and SVC interrupts. Others are asynchronous (in that they can
occur when executing instructions or when being in a wait state but are
not usually the direct consequence of the execution of a particular
instruction) : I/O, EXT and RESTART. Machine check can be both
(depending on the reason for the machine check).

Except for the RESTART Interrupt, asynchronous Interrupts may be masked.
The primary mask is in the PSW (and is called the System Mask which can
be manipulated with SSM, STNSM, STOSM and of course LPSW).. There are
also subclass masks that can more finely mask interrupts (CR0 contain
EXT related subclass masks while CR2 (in S/370) and CR6 (in S/390 &
z/Arch) contain I/O subclass masks. The primary reason why the control
register was changed is probably related to the fact that the masking
mechanism was changed from Channel number based to a subchannel
customizable parameter).

The interrupt process itself is fairly simple : The current PSW is
stored at the 'OLD PSW' location and the 'NEW PSW' is loaded in the
actual PSW. Those fields are located in the famous low storage area we
have been discussing. Each interrupt class has its own OLD/NEW PSW
locations and are defined by the architecture. Since z/Architecture has
128 bit PSWs (not to mention a fairly different format), they had to be
relocated in order not to conflict with previously existing locations.

Some interrupts are cleared simply by them firing : I/O, Machine Check,
Program, SVC, Restart. For External, it depends on the cause but
basically Clock Comparator and CPU Timer interrupts are NOT cleared by
taking the interrupt (they are only cleared when the respective reason
for the interrupt is cleared). For non self clearing interrupts - having
a NEW PSW that is enabled for the interrupt class will lead to an
interrupt loop.

The location of the interrupt code (the *reason* for the interrupt or
the I/O device causing the interrupt) is located, again, in the low
storage area. The location is dependent on both the architecture and the
PSW format used (BC or EC). This code allows the interrupt handler to
determine what action to take. This really IS the main reason that each
CPU needs its own low storage area and the primary reason for the Prefix
register & mechanism.

I/O interrupts for a specific device can also sometimes merge - and the
status bits in the CSW/SCSW will have been OR'd (there are some merging
conditions though.. they will not ALWAYS merge).

Interrupts also have defined priorities, so if more than 1 interrupt
class is pending, the order in which they will be presented to the CPU
is determined.

Although Machine Check interrupts can be masked, if the machine check is
a repressible machine check (like instruction damage or system damage)
then the system will enter a check stop state because it is no longer
safe to continue operations. This may also occur if a machine check
interrupt occurs while there is already a machine check interrupt being
processed (even with the machine check mask enabled).

If you look at it, interrupts on S/370, S/390 and z/Arch are a whole lot
simpler than it is on x86 for example (there is no need for internal
knowledge of PICs & bus interrupt mechanism) and the interrupt process
is perfectly well defined by the architecture itself - that is - it is
not implementation dependent.

Finally, here is a (not even tried) small sample program that can be
IPLed (it's 3CARD LOADER Compatible since there are no ADCONs) that will
loop for 1 second until the CPU Timer interrupt occurs and then loads a
disabled wait PSW. There may be some errors since I haven't even tried
to compile it - and it may not even work - but if it doesn't it
shouldn't be hard to fix ! It should give you an idea of how simple
handling interrupts is.

START1 CSECT *
ORG *+X'20000'
START DS 0H
BALR 12,0 * ESTABLISH ADDRESSABILITY
USING *,12
MVC EXTNPSW(8),MYEXTN * SET NEW EXT PSW
LA 1,EXTH * GET HANDLER ADDRESS
ST 1,EXTNPSW+4 * SAVE IN NEW PSW
STCTL 0,0,WORK1 * GET CR0
OI WORK1+2,X'04' * ENABLE CPU TIMER SUBCLASS
NI WORK1+2,X'7F' * DISABLE CLOCK COMP
LCTL 0,0,WORK1 * RELOAD MODIFIED CR0
SCPT SEC1SEC * SET THE CPU TIMER VALUE (~1SEC)
LA 1,CONT * LOAD LOOP ADDR
ST 1,CONTPSW+4 * SAVE IN PSW
LPSW CONTPSW * THAT WE LOAD NOW
CONT DS 0H
TM FIRED,X'80' * HAS THE CPU TIMER FIRE ?
BNZ CONT * NOPE.. LOOP SOME MORE
LPSW DISAWAIT * YES.. EOJ
*
* EXTERNAL INTERRUPT HANDLER
* (NOTE WE ASSUME WE HAVE ADDRESSABILITY)
*
EXTH DS 0H
CLC EXTINT(2),=XL2'1005' * CPT INT ?
BNZ NOTCPT * NOPE
OI FIRED,X'80' * INDICATE CPT FIRED
NOTCPT DS 0H
LPSW EXTOPSW * BACK WHENCE WE CAME FROM
*
* END OF EXT HANDLER
*
DS 0D
SEC1SEC DC AL4(1),AL4(0) *APPROX. 1 SEC
MYEXTN DC X'00080000',AL4(*-*)
CONTPSW DC X'02080000',AL4(*-*)
DISAPSW DC X'000A0000',AL4(0)
*
WORK1 DS F
FIRED DC X'00'
* SOME PSA LOCATIONS
EXTNPSW EQU X'58'
EXTOPSW EQU X'18'
EXTINT EQU X'86'
LTORG
END START

--Ivan

7:24 pm

Re: OS Design for Hercules

Tony Harminc

Sep 19, 2007

On 19/09/2007, Ivan Warren <ivan@...> wrote:

> PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
> multi CPU environment.

Actually there is a very cute use of prefixing on a single CPU, but
it's not what it was intended for.

> Ok.. Here is a crash course on interrupts..

Good crash (uh, course). :-)

> Now.. Interrupts are not THAT complicated. Some interrupts are
> synchronous (and deal with the execution of instructions). These are the
> Program and SVC interrupts. Others are asynchronous (in that they can
> occur when executing instructions or when being in a wait state but are
> not usually the direct consequence of the execution of a particular
> instruction) : I/O, EXT and RESTART. Machine check can be both
> (depending on the reason for the machine check).

Many architectures distinguish between these by calling the
instruction-related interrupts "traps", and only the externally
generated ones "interrupts". But don't try using this terminology
here; it may be confused with something else.

It's also worth stating a golden principle of the architecture that
says that a machine check (either interrupt or red light kind of
thing) cannot be caused by programming. No matter how badly you screw
up your code (even privileged code), you cannot make the machine
malfunction, or indicate that it has malfunctioned. This too is very
different from many other architectures. Some RISC machines can even
get red lights from a bad compiler-generated code sequence. (Well, of
course one can argue that this isn't strictly true, but it is true if
you stay away from the Diagnose instruction, and just possibly from
certain undocumented SIGP operations. And some early /370 models had
undocumented op codes that could get dangerous, e.g. the /168's Load
Micro Program (LMP) instruction.)

Perhaps even more generally, one must learn to read the PofO. It has
special terms that are defined at the front, and understanding them
makes life easier. For example, "undefined" is used very precisely to
describe the results of executing a certain instruction under certain
circumstances; it is not a vague "we don't know what will happen".

As Roger just said, the interrupt system, and indeed many other parts
of the architecture, are both elegant and programmer friendly. There
are warts that have sprouted here and there (and one or two congenital
ones), and it is often argued that S/360 is cleaner than S370, and so
on, but even z/Arch is pretty good.

Tony H.

10:46 pm

Re: OS Design for Hercules

Josef Sipek

Sep 19, 2007

On Wed, Sep 19, 2007 at 09:24:50PM +0200, Ivan Warren wrote:
> Josef Sipek wrote:
> >
> > It sounds like if you want to load-balance interrupt handlers, you have to
> > use prefixing.
> >
> >
> Nah nah nah...
>
> PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
> multi CPU environment.
>
> Ok.. Here is a crash course on interrupts..
>
> How interrupts are distributed among CPUs is not controlled by prefixing
> but by the architecture and by CPU interrupt masking & subclass masking.

Riiight. I remember bits and pieces about that from my reading of the PSW
format docs.

> Interrupts come in 2 flavors : Floating and non-floating. Floating
> interrupts are interrupts that can trigger a PSW switch on any
> operational CPU in a configuration. Notably, I/O interrupts are floating
> (and only in S/390 & z/Arch).. Some Machine Checks may also be floating
> (External Damage may be floating).

And non-floating must occur on CPU that triggered it?

> There are 6 classes of interrupts :
> - Program Interrupt : They relate to an exception or condition
> encountered during execution of an instruction. They may be related to
> the operation code, operation parameters, address translation, tracing,
> etc..

Makes sense.

> - SVC Interrupt : Every time the SVC instruction is executed

Simple, I like it.

> - I/O : Pertains the a device meaning to present some status to the CPU
> - which may be solicited - the result of an ongoing I/O operation, or
> unsolicited (Attention or not-ready to ready state switch)

Ok.

> - External : Various non-damage conditions : Timing, inter-cpu
> communication, Service Processor communication, the 'External' operator
> button, etc.. (there are more)

This reminds me of a "problem" I have with the whole architecture. It does
too many things. For example, how many different ways to address are there?
AR, Home, Primary, Secondary, ... I only skimmed through the Storage chapter
of the PoO. Trying to sort out what's best used where, and making sure that
the other cases are handled in case something checks/depends on some bits.
But overall, I still love it :)

> - Machine check : Various possibly damage conditions : System damage,
> instruction damage, External Damage (I/O damage goes there IIRC) and
> some non damage conditions such as I/O reconfiguration.. Machine check
> may also be presented to indicate an error occurred but was fixed
> internally like when a single bit error in storage was fixed by ECC.

Neat.

> - Restart : Operator initiated non maskable interrupt (depending on the
> Operating System, this may be used to trigger a dump when the system has
> entered a disabled loop). Note that the RESTART new PSW is at the same
> location as the IPL PSW - which means that on simple IPLable programs,
> RESTART will actually restart the program from the beginning !

Interesting.

> Now.. Interrupts are not THAT complicated. Some interrupts are
> synchronous (and deal with the execution of instructions). These are the
> Program and SVC interrupts. Others are asynchronous (in that they can
> occur when executing instructions or when being in a wait state but are
> not usually the direct consequence of the execution of a particular
> instruction) : I/O, EXT and RESTART. Machine check can be both
> (depending on the reason for the machine check).

Makes sense.

...
> The interrupt process itself is fairly simple : The current PSW is
> stored at the 'OLD PSW' location and the 'NEW PSW' is loaded in the
> actual PSW. Those fields are located in the famous low storage area we
> have been discussing.

:)

...
> I/O interrupts for a specific device can also sometimes merge - and the
> status bits in the CSW/SCSW will have been OR'd (there are some merging
> conditions though.. they will not ALWAYS merge).

Ouch! This sounds painful to deal with, but I guess I'll get to see when I
start poking around interrupts (probably sooner than later :) ).

> If you look at it, interrupts on S/370, S/390 and z/Arch are a whole lot
> simpler than it is on x86 for example (there is no need for internal
> knowledge of PICs & bus interrupt mechanism) and the interrupt process
> is perfectly well defined by the architecture itself - that is - it is
> not implementation dependent.

Agreed.

> Finally, here is a (not even tried) small sample program that can be
> IPLed (it's 3CARD LOADER Compatible since there are no ADCONs) that will
> loop for 1 second until the CPU Timer interrupt occurs and then loads a
> disabled wait PSW.

Neat!

Josef 'Jeff' Sipek.

--
A CRAY is the only computer that runs an endless loop in just 4 hours...

11:26 pm

Re: OS Design for Hercules

Josef Sipek

Sep 19, 2007

On Wed, Sep 19, 2007 at 06:46:57PM -0400, Tony Harminc wrote:
> On 19/09/2007, Ivan Warren <ivan@...> wrote:
>
> > PREFIX is irrelevant when only 1 CPU is active and MUST be used in a
> > multi CPU environment.
>
> Actually there is a very cute use of prefixing on a single CPU, but
> it's not what it was intended for.

You can't just say that there's a neat way to use prefixing and not say
_what_ it is.

> > Ok.. Here is a crash course on interrupts..
>
> Good crash (uh, course). :-)
>
> > Now.. Interrupts are not THAT complicated. Some interrupts are
> > synchronous (and deal with the execution of instructions). These are the
> > Program and SVC interrupts. Others are asynchronous (in that they can
> > occur when executing instructions or when being in a wait state but are
> > not usually the direct consequence of the execution of a particular
> > instruction) : I/O, EXT and RESTART. Machine check can be both
> > (depending on the reason for the machine check).
>
> Many architectures distinguish between these by calling the
> instruction-related interrupts "traps", and only the externally
> generated ones "interrupts". But don't try using this terminology
> here; it may be confused with something else.
>
> It's also worth stating a golden principle of the architecture that
> says that a machine check (either interrupt or red light kind of
> thing) cannot be caused by programming.

One would hope that's true :)

> And some early /370 models had undocumented op codes that could get
> dangerous, e.g. the /168's Load Micro Program (LMP) instruction.)

I want to be comfortable with the documented bits before I start venturing
to the uncharted^Wundocumented territories.

> Perhaps even more generally, one must learn to read the PofO.

Agreed. About a month and a half ago, I found one website that did a tour of
the S/370 (IIRC) PoO. But that alone didn't help me in some cases; for
example, it came to me as a nasty surprise that bit 0 is the _most_
significant bit. Only after two days of reading random (well, not random,
but jumping from place to place to build a mental picture of what's
happening) sections of the z Poo,

> As Roger just said, the interrupt system, and indeed many other parts
> of the architecture, are both elegant and programmer friendly.

The IPL process is beautiful compared to say x86 :)

> There are warts that have sprouted here and there (and one or two
> congenital ones), and it is often argued that S/360 is cleaner than S370,
> and so on, but even z/Arch is pretty good.

I haven't looked specifically, but it seems like there are rather major
differences between S/360 and 370. Or at least they feel like "oh, that
didn't work as well as we hoped, let's change this".

Backwards compatibility always causes pain...just look at the evolution of
x86.

Josef 'Jeff' Sipek.

--
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein

11:42 pm

Re: OS Design for Hercules

Tony Harminc

Sep 20, 2007

On 19/09/2007, Josef Sipek <jsipek@...> wrote:

> > Perhaps even more generally, one must learn to read the PofO.
>
> Agreed. About a month and a half ago, I found one website that did a tour of
> the S/370 (IIRC) PoO. But that alone didn't help me in some cases; for
> example, it came to me as a nasty surprise that bit 0 is the _most_
> significant bit.

Which part of 'Within each group of bytes, bits are numbered in a
left-to-right sequence. The leftmost bits are sometimes referred to as
the "high-order" bits and the rightmost bits as the "low-order" bits.
Bit numbers are not storage addresses, however. Only bytes can be
addressed. To operate on individual bits of a byte in storage, it is
necessary to access the entire byte. The bits in a byte are numbered 0
through 7, from left to right.' did you not understand...? :-)

> Only after two days of reading random (well, not random, but jumping from
place
> to place to build a mental picture of what's happening) sections of the z Poo,

Well, while the PofO is not really an instruction manual, it does make
sense to mostly read it in order.

Tony H.

3:46 pm

Re: OS Design for Hercules

Josef Sipek

Sep 20, 2007

On Thu, Sep 20, 2007 at 11:46:19AM -0400, Tony Harminc wrote:
> On 19/09/2007, Josef Sipek <jsipek@...> wrote:
>
> > > Perhaps even more generally, one must learn to read the PofO.
> >
> > Agreed. About a month and a half ago, I found one website that did a tour of
> > the S/370 (IIRC) PoO. But that alone didn't help me in some cases; for
> > example, it came to me as a nasty surprise that bit 0 is the _most_
> > significant bit.
>
> Which part of 'Within each group of bytes, bits are numbered in a
> left-to-right sequence. The leftmost bits are sometimes referred to as
> the "high-order" bits and the rightmost bits as the "low-order" bits.
> Bit numbers are not storage addresses, however. Only bytes can be
> addressed. To operate on individual bits of a byte in storage, it is
> necessary to access the entire byte. The bits in a byte are numbered 0
> through 7, from left to right.' did you not understand...? :-)

Ah, you misunderstood me. What I meant to say, is that I did _not_ read that
part of the PoO, and when I looked at the PSW information, bit numbering was
reverse of what I expected (bit number 0 being least significant). :)

> > Only after two days of reading random (well, not random, but jumping from
place
> > to place to build a mental picture of what's happening) sections of the z
Poo,
>
> Well, while the PofO is not really an instruction manual, it does make
> sense to mostly read it in order.

I took the approach of there's no way I'm reading >1200 pages cover to
cover; let me read the sections as I need them. With that said, I did read
the beginning of the introduction (until it gets into the changes since last
revision part), and most of the organization chapter.

Josef 'Jeff' Sipek.

--
Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former.
- Albert Einstein

5:41 pm

Re: OS Design for Hercules

Roger Bowler

Sep 20, 2007

--- In hercules-390@yahoogroups.com, Josef Sipek wrote:
> This reminds me of a "problem" I have with the whole architecture.
> It does too many things. For example, how many different ways to
> address are there? AR, Home, Primary, Secondary, ... I only
> skimmed through the Storage chapter of the PoO. Trying to sort out
> what's best used where, and making sure that the other cases are
> handled in case something checks/depends on some bits.
> But overall, I still love it :)

What you have to remember is that you are looking at the result of an
evolutionary process spanning more than 40 years. AR, Home, Primary,
Secondary, 24 bits, 31 bits, 64 bits, program call, linkage stack, all
of these were added to the architecture piece by piece. If there seems
to be more than one way of doing some things, that's because many new
methods have superseded old methods, but the old methods have been
retained so that existing programs do not have to be rewritten (they
do not even need to be recompiled). IBM refers to this as "preserving
customer investment" and it's a feature of the traditional mainframe
operating systems which is absent in (for example) Linux [1]

The way I would tackle learning the architecture is this:

1. To get a solid grounding in the instruction set, start with the
System/360 Assembler Self Study books (the classic assembler course)
at pdf/ibm/360/training/ in bitsavers (although probably too
elementary for you Josef)

2. Supplement this with the S/360 Principles of Operation (also at
bitsavers). BC mode only, and at that time the architecture was still
simple enough that it's within the grasp of a single person to
understand everything in this book.

3. Move on to the S/370 Principles of Operation to learn about EC mode
and virtual storage. Here you can also learn about cross-memory (dual
address space) and this is when your head starts to hurt.

4. Study the 370-XA Principles of Operation to learn about 31-bit
addressing and the channel subsystem (SSCH, ORB, etc) which is where
the XA architecture diverges incompatibly from S/370 (while cleverly
maintaining problem state compatability). Not sure if this book is at
bitsavers, but if not then the ESA/390 Principles of Operation has the
same information because ESA/390 evolved from 370-XA.

5. Study the ESA/390 Principles of Operation (still current and
available from ibm bookmanager sites) to learn about data spaces,
access registers, linkage stack, and other stuff I cannot think of
right now.

6. Study the z/Architecture Principles of Operation to find out about
64 bit addressing, region tables, and hundreds upon hundreds of new
instructions. This mammoth size book mixes almost the whole 40 years
of evolution in its 1200 pages and I would not envy anyone who decides
to plunge into it as an introductory text.

Regards,
Roger Bowler

--
[1] The episode which prompted me to give up serious development under
Linux was in 2000 when I resurrected a program which I had written
about 3 years earlier but which I had not run for at least 2 years. To
my dismay, it no longer worked. IIRC, it had been linked with glibc
version 1 but Linux had since moved on to glibc version 2. So it would
not even load. Nor would it recompile against glibc version 2 without
modification. Linux is what I would call a moving target. MVS in
general is not. You can still get by as a programmer even if you have
never heard of the new things that have been added since 1990. Whether
this is a good or bad thing, of course, depends on your point of view :-)

9:31 pm

Re: OS Design for Hercules

Roger Bowler

Sep 20, 2007

--- In hercules-390@yahoogroups.com, Josef Sipek wrote:
> I did read the beginning of the introduction (until it gets into
> the changes since last revision part)

IMO it's worth also reading the sections headed "the ESA/390 base" and
"the ESA/370 and 370-XA base" later in that introductory chapter,
these will help you to identify what are the really basic features of
the architecture and what are the newer additions.

My point being that because it's an evolutionary architecture you can
still do a lot if you know the basics without necessarily knowing the
newer stuff, but not vice versa.

Roger Bowler

9:44 pm

Copyright 2007