z390, MP instruction and Specification errors..

[Anthony Delosa]

I'm working through the John Ehrman book and looking at the MP instruction.

Section 29.5 MP Instruction

There is quite a bit of text dedicated to the fact that the receiving field needs to be bigger than the sending field. If the required receiving field sizes are not provided, then you are supposed to receive a "specification exception".

The example I have been playing with is Figure 299. Using ZAP to set correct decimal multiplicand length.

MP     SUBENTRY

       ZAP    R,MPCand      Move multiplicand

       MP     R,=P'101'     Multiply by 101

       RETURN

MPCand DC     PL4'0001234'  4-byte multiplicand

R      DS     PL5           Result must be 1 byte longer

       END

The point of the figure is that even though the PL4 field can fit the result, the instruction would not allow it because the receiving field needs to be bigger.

"It is important to remember that the number of bytes of high-order zeros in the first operand must not be less than the length of the second operand, even though the first operand may already contain enough high-order zeros."

 

I wanted to test this by setting the side of the receiving field to 4 and waiting for the error..

MP     SUBENTRY

       ZAP    R,MPCand      Move multiplicand

       MP     R,=P'101'     Multiply by 101

       RETURN

MPCand DC     PL4'0001234'  4-byte multiplicand

R      DS     PL4           Made the same size

       END

But this code still works on z390..

Am I reading this wrong and does z390 emulate the instruction as provided in the John Ehrman book? 

[d...@higgins.net]

Anthony

 

Sounds like a bug.  I’ll check it out, but it will probably be after new year’s. 

 

The POP says exactly what you said about the number of leftmost bytes of zeros in multiplicand being greater than length of multiplier.

 

Don Higgins

d...@higgins.net

www.donhiggins.org

--
You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/z390/aa035b42-1188-498c-b8eb-ab4a3aa0c21an%40googlegroups.com.

[Martin Ward]

On 28/12/2020 11:32, d...@higgins.net wrote:
> Sounds like a bug.  I’ll check it out, but it will probably be after new
> year’s.
>
> The POP says exactly what you said about the number of leftmost bytes of
> zeros in multiplicand being greater than length of multiplier.

The POP also says "The leftmost digit of the product is always zero":
this is a mathematical consequence of the length rule.

The add decimal (AP) instruction can overflow and simply sets
the condition code to 3 when overflow occurs, so I wonder why
the designers needed to go to such lengths to avoid the possibility
of overflow on the multiply instruction. I am guessing that there
was some hardware constraint which made it difficult to detect overflow
in a packed decimal multiplication.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

[John Ganci]

DP (Divide Decimal) can generate a specification exception. It should also be checked.

John Ganci

[MELVYN MALTZ]

Hi there,

 

I think what is being missed here is the fact that neither MP nor DP set the condition code. This implies that a valid math result is always expected and hence the rules on field lengths and leading zeroes

 

Compare to AP and SP which do set the CC and are far more likely to be involved in a BCT-type loop and therefore may overflow

 

Melvyn Maltz.

--

You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/z390/556d6d91-1b6d-408c-a7f1-dc6f09ccbd1bn%40googlegroups.com.

[Lin Lyons]

One might point out that the original #, P'1234' would fit into PL3 field, and the result of the multiply will fit into a pl4 field, so there is no overflow exception.  The machine does not know that you've moved what could have been a PL3 or PL4, into a PL4 or PL5 field, before the multiply.  If the original number had been something like  p'123456', then you would need a PL5 field to contain the result and not abend.

0C0 Imprecise location interupt. (360 95/97 only)
0C1 Operation exception.
0C2 Privileged-operation exception.
0C3 Execute of execute exception.
0C4 Protection exception.
0C5 Addressing exception.
0C6 Specification exception.
0C7 Packed data exception.
0C8 Fixed-point-overflow exception.
0C9 Fixed-point-divide exception.
0CA Decimal-overflow exception.
0CB Decimal-divide exception.
0CC Exponent-overflow exception.
0CD Exponent-underflow exception.
0CE Significance exception.
0CF Floating-point-divide exception.

To view this discussion on the web visit https://groups.google.com/d/msgid/z390/40343562D45C495489EEE8EE148BF822%40Mel.

[Paul Gorlinsky]

Mailbox Not Monitored!

> To view this discussion on the web visit https://groups.google.com/d/msgid/z390/40343562D45C495489EEE8EE148BF822%40Mel.

[Abe Kornelis]

All,

We had a meeting with the zVSAM development team.
I'd like to give you all an update of progress.

1) Melvyn has been making good progress to create
     dual-path macros for VSAM support.
     Depending on the zVSAM(n) option either the
     V1 version or the V2 version of each macro will be expanded.

2) Don and John are working on instruction support.
    Don is also working on QSAM support for variable length records
    up to 2GB in length. We're planning to create support for these
     records in zVSAM, so we also need to be able to unload/load
     these large records.

3) I will be creating a git repository.
     Currently I'm trying to get to better understand the git workings
     while building the history of z390 development into the repository.

We've agreed to take small steps.
One of these will be the transition to using the git repository once
it's completely up-to-date with current development, including
the various branches that already exist de facto.

Finally, we discussed the regression testing facility and the scripts
that use it. Until now only a few dozen such scripts have been
created. It would be great to have some help in creating more RT scripts.
Obviously, that would help us developers to improve the quality of
the code and to maintain that quality across versions.

Kind regards,
Abe
===

[Anthony Delosa]

I've have a bit of experience with the git tool as well as online code development platforms like github and bitbucket. 

I would be happy to assist in moving the codebase to one of these platforms if you need help.

Moving to something like github will allow you to manage changes through issues and pull requests. You could also automate the build pipeline to perform regression testing and create a distribution whenever code is committed or a version is nominated. 

I would also add the documentation to the build and publish it to something like "read the docs". It's documentation as code. 

IBM is now promoting this path for development on the mainframe with their Dependency based build tools and source control using Git.

[d...@higgins.net]

Anthony

 

That’s great.  We need a few more good folks with github experience.

 

I’d love to see the regression testing and docs handled as part of the github database with version control and automated distribution builds.

 

I’ve not used github so I have a lot to learn.

 

Don Higgins

d...@higgins.net

www.donhiggins.org

 

From: z3...@googlegroups.com <z3...@googlegroups.com> On Behalf Of Anthony Delosa
Sent: Saturday, January 23, 2021 8:53 PM
To: z390 <z3...@googlegroups.com>

--
You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/z390/cc492d36-1d9a-4015-8153-05a5e3dbb186n%40googlegroups.com.

[Abe Kornelis]

Anthony,

thanks for your offer to assist.
Adding the documentation - including the z390 site sources - was
one of the things I was considering. I think I'll push forward with
adding everything of relevance to the repository.

Obviously, I'll keep things separated out by putting them in
different directories ;-)

I notice you mentions github and bitbucket as distinct from git.
To my mind these are 'just' front-ends - but I'm only beginning to learn git stuff ...

So would you please elaborate on the distinction between these?
I'd like to get a better understanding of the differences and the trade-offs
involved. After all, at this point in time we're still free to choose.
Once we start  on one of these platforms, I guess changing becomes
more complex.

I've chosen git - rather than SubVersion with which I'm more acquainted -
because of its distributed nature, allowing all of us the maximum freedom
in creating our own extensions etc.

Kind regards,
Abe
===

Op 24/01/2021 om 02:52 schreef Anthony Delosa:

--
You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/z390/cc492d36-1d9a-4015-8153-05a5e3dbb186n%40googlegroups.com.

[Abe Kornelis]

Don,

for your info: I'm creating the repository from the distributions
you've made available. I'm excluding only the stuff that can be
regenerated using the java compiler, the z390 assembler, etc.

So all the docs included with the distributions will be in the
repository from day one.

Based on Anthony's suggestion I'll add the contents of the
z390 site as well - it's good to have the repository as complete
as possible.

By the time we get to zVSAM, I'll definitely include the
Design and Logic manual as well as other documentation
we created in the process.

Kind regards,
Abe
===

Op 24/01/2021 om 04:09 schreef d...@higgins.net:

To view this discussion on the web visit https://groups.google.com/d/msgid/z390/006801d6f1fe%2446ad7b90%24d40872b0%24%40higgins.net.

[Anthony Delosa]

Here is my overview on Git vs Online Git services like Github.

Git is the source control management system.. Outside of mainframe and other proprietary platforms it is THE source control system used everywhere.

The Git model is very different than Subversion. There is no central node or check in/out logic in Git. Git is distributed - Everyone has their own repository. Changes are made by merging changes from another (remote) repository. Even though you don't have to, people usually create a central repository and use that for hosting their code and becoming the master that everyone clones from.   

Github, Gitlab, Bitbucket and countless other services provide a hosted software development platform that includes Git repository hosting -- i.e that central repository of the code. But these platforms also provide many other services that are not provided by the core Git tool:

1. Pull requests - a mechanism for someone to submit a change to be pulled into the central repository. This will include tools to review the changes being proposed. The great thing about these is anyone can submit them and they don't need to have access to the master repository

2. Issue tracking systems - Ability to raise issues, and then link the fixes to a pull request

3. Pipelines/Actions - Ability to run actions when code is committed to a repository. These may process unit tests, build a distribution or update online documentation.

So Git is an awesome tool, but with these services that make it a one stop shop for code development.

Which one you choose depends on what you need, the costs and your own personal preferences. 

The obvious choice is Github. It's the original and has a lot of support and features.

I like Bitbucket, but thats because I am Australian and its created by an Australian company.. but it does the same things.

I have not looked at Gitlab, but its probably good as well.

Amazon, MS and Google also have their own services attached to their cloud offerings but these tend to be used more for internal rather than open projects. 

Microsoft owns Github now and is pushing people to use Github over their own service which is currently called Azure DevOps.. its had a few names over the years.

Hopefully this makes sense.

Anthony

[Peter Lund]

I think this "moving to github" thing sounds great!

I'd like to add a few things:

Git is not the easiest version control system to use -- but its usability has improved a lot over the years.  There are also pretty good git plugins for various editors + pretty good standalone GUI frontends for git.  I don't use any of them, though.  Git works natively on Linux, Windows, OS X.

Github has something called "github pages".  It is a free webhosting service backed by github repositories.  That means that Don doesn't have to rebuild his third (or fourth or fifth?) version of the website for z390 AND it means that others can update the looks and organization without everything having to go through Don.  Others may or may not have commit rights to such a repository, but it is fairly easy to clone it, do whatever editing, and then put in a pull request that Don (or any of the other committers) can then pull.  You can use a github provided domain or you use a custom domain if you really wish.

https://pages.github.com/

Not only does Github have various "actions" that can be triggered by commits -- they have a full-fledged continuous integration service, free for open source projects!
There's no need to try and create actions that communicate with a CI service elsewhere.  It is an integrated part of github.

https://docs.github.com/en/actions
https://docs.github.com/en/actions/guides/about-continuous-integration

-Peter

PS: for those who helped me with S/360 information last month, I can say that the S/360 emulator is progressing nicely but slowly, as I don't put that many hours into it per week.  Getting the ALU instructions right with respect to overflow/carry was a bit finicky, especially without invoking any undefined behaviour in C.  I am currently working on the "interruptions" and proper channel I/O for tape is next.  Thank you to the guy who told me that the OS distribution tapes were bootable -- I had figured it out myself just a few hours before that email was sent, but thank you anyway from the bottom of my heart!  The CPU itself *was* indeed pretty easy, there *were* indeed issues with documentation (parts of the S/360 POP are not written well), and the device I/O stuff is indeed a bit of a jungle (but easier than a C64 or an Amiga).

To view this discussion on the web visit https://groups.google.com/d/msgid/z390/8adacd07-e34b-44cf-8970-2e9c5953b37an%40googlegroups.com.

[Anthony Delosa]

Agree on the steep learning curve of Git but once you understand the model and master a few basic operations, the rest you can google. I've been using it for the last 5 years and I still use Google.

Good point on the doc publishing - that is very handy. I recently built some doco using mkdocs and github pages.

Github really is becoming a one stop shop for all your development needs and it would be my recommendation for project hosting.

OK, so assuming everyone thinks moving to a platform like Github is a good idea, I'm going to propose an implementation approach assuming the current model is Don has the master of the source code and all committers send their changes to Don and he incorporates them into the master and creates the releases.

I think the first step is to get the z390 source hosted on Github and all future changes are made there. 

This will start with Don being the only committer to the repo and he will push all development changes to Github. Everyone can continue to send their changes to him (via patches or whatever method is being used today). He would incorporates those changes into his local copy of the code base and push the changes back to Github.

Once Don is comfortable with the Git process, we can then start using Github pull requests to receive changes from other committers. Instead of getting changes via email, they will be presented in the Github pull request process. This will of course require that committers start using Git and Github.. people can continue to send their changes to Don directly, but we will have a new method that will become the standard way over time.

You will need to decide who will approve changes to be merged into the code base. Initially just Don, but additional people can be added.

If we have that, we can then start adding changes to the repository to:

• Add an automated build of the Jar file
• Add unit tests and coverage to the Java code (Not sure if current code base has unit tests)
• Add automated run of the ASM regression tests including checking results
• Add creation of the distribution zip and publish as a Github release (hosted on Github) 
• Add publish of documentation to Github pages

But the first step is to start using Git and Github to manage the source.. It is a big first step, but I think it will make many parts of the management of the project easier over time.

I am always available for any assistance you need to get started with this. That includes getting onto chat/Zoom to get the current source up into Github and how to add changes to the repository... As I mentioned, I'm more familiar with Bitbucket but most of the concepts can be translated across.

Let me know how you want me to assist.

Anthony