¿ªÔÆÌåÓý

  1. H390-Vm
  2. Messages
Expanded Topics Messages Polls
Date
Re: REXX programs and functions in VM/370

 

¿ªÔÆÌåÓý

Hi Tony,

I remember you mentioned SAA Rexx a few days ago - I found my 1992 copy of the OS/2 Procedures Language/2 Rexx SAA manual, and I put it under the scanner.
Here is the searchable PDF:?

best regards,

¸é±ð²Ô¨¦.

On 28 Mar 2020, at 02:23, Tony Harminc <tharminc@...> wrote:

On Fri, 27 Mar 2020 at 17:32, rvjansen@... <rvjansen@...> wrote:

Older source will generally work on newer interpreters.

Other than those *many* $variable that I have used for decades... Does
anyone think they are planned to be used as syntactic chars, or can we
petition ANSI to have them put back in?

VM (only) has index() in addition to pos().

z/OS REXX also has index(), listed as a "non SAA function. Hey,
there's an old standard... Is there a copy around somewhere? There is
a book "SAA Common Programming Interface REXX Level 2 Reference"
mentioned in the current z/OS TSO/E ?REXX Level 2 Reference.
Searching, I see that it's SC24-5549 or .boo file E04A2A01, but I'm
not so far finding an actual copy online.

Regardless, I believe that z/OS uses the same interpreter code as VM.

Tony H.
Re: Testing

 

Very sensible!
Testing

 

¿ªÔÆÌåÓý

Folks,

?

I think my next move is rather than to add new code, to develop some tests that check out everything that¡¯s included in 6-Pack?

Thoughts?

?

Dave Wade

G4UGM & EA7KAE

?
Re: Register Add - Quick Question

 

On Fri, Apr 17, 2020 at 05:04 PM, Tony Harminc wrote:
immediate
instructions
It was the lack of these that freaked me out a bit!

To be honest I am just doing the minimum in assembler before passing on to c where the heavy lifting is done.

For example assembler can make a new frame up the stack and detect an overrun. Can flip to an auxiliary stack so it can call a C MORESTAK ... but C handles finding a new stack bin, etc.

If folks are interested! :-)
Re: memset help

 

On Fri, 2020-04-17 at 20:38 +0100, Dave Wade wrote:
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Tony
Harminc
Sent: 17 April 2020 20:35
To: [email protected]
Subject: Re: [h390-vm] memset help

On Fri, 17 Apr 2020 at 15:17, Dave Wade <dave.g4ugm@...>
wrote:

When I first wrote the code to support "float.h" and floating
point printf I
worried about this.

I must admit that I have a vague recollection of this issue coming
up here
before.

I found that GCC uses its own internal representation for floats
during the
compile procedure.
So whilst it might be hard to write extreme constants as float
literals, and I had to resort to HEX, anything you do write as a
floating point
literal will be consistently handled regardless of the platform on
which you
run the compiler.
Note I say "consistently" not "correctly" so you might not get
what
you expect, but it will be the same regardless of which platform
you run
the compiler on.
With hindsight, given that GCC is inherently designed to be used
as a cross-
compiler, this should not be a surprise..

I'm still a bit unclear though on how the compiler can be
consistent in how it
translates a float decimal input constant expression such as
3.14159 into a suitable hex FP representation in a (compiler)
platform-
independent way. Probably I misunderstand how the compiler is
structured.
I had thought that the (loosely speaking) front end was platform
independent, and that only the very back end would be aware of
things like
the FP representation in use. Is that constant actually carried in
a
representation-independent way (which can pretty much only mean as
the
original string or some other truly decimal
representation) all the way through to where it is converted into a
hex FP
value somewhere near the end?

I hate to imagine how any optimisation could be carried out, e.g.
if you have x
= 3.14159 + 2.71828, where you would expect some fairly early
conversion
into a single constant value. Perhaps I remain to be pleasantly
surprised. I
wonder how the likes of LLVM manage this stuff. I'd guess they have
just
deemed IEEE to be *the* correct representation for FP numbers, much
as
twos complement is just assumed to be the only possible
representation for
signed binary these days.
There is a pile of code, including, if I remember properly floating
point emulation, so it can do floating point optimization on
platforms which don't support floating point at all...

The compiler needs to know something about floating point because it
will do "constant folding". That is, if I have an expression with
constants in it, it's going to try and evaluate all of the expressions
that evaluate to constants to a single value. Also has it does
optimizations (hoisting, etc) it may see situations that originally
didn't look like expressions of constants originally.

So, just like the compiler has an internal "instruction set" (for lack
of a better term), that also includes floating point. When the final
code generation happens, it will translate that into the final form
required by the target machine.

TTFN - Guy
Re: memset help

 

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Tony
Harminc
Sent: 17 April 2020 20:35
To: [email protected]
Subject: Re: [h390-vm] memset help

On Fri, 17 Apr 2020 at 15:17, Dave Wade <dave.g4ugm@...> wrote:

When I first wrote the code to support "float.h" and floating point printf I
worried about this.

I must admit that I have a vague recollection of this issue coming up here
before.

I found that GCC uses its own internal representation for floats during the
compile procedure.
So whilst it might be hard to write extreme constants as float
literals, and I had to resort to HEX, anything you do write as a floating point
literal will be consistently handled regardless of the platform on which you
run the compiler.
Note I say "consistently" not "correctly" so you might not get what
you expect, but it will be the same regardless of which platform you run
the compiler on.
With hindsight, given that GCC is inherently designed to be used as a cross-
compiler, this should not be a surprise..

I'm still a bit unclear though on how the compiler can be consistent in how it
translates a float decimal input constant expression such as
3.14159 into a suitable hex FP representation in a (compiler) platform-
independent way. Probably I misunderstand how the compiler is structured.
I had thought that the (loosely speaking) front end was platform
independent, and that only the very back end would be aware of things like
the FP representation in use. Is that constant actually carried in a
representation-independent way (which can pretty much only mean as the
original string or some other truly decimal
representation) all the way through to where it is converted into a hex FP
value somewhere near the end?

I hate to imagine how any optimisation could be carried out, e.g. if you have x
= 3.14159 + 2.71828, where you would expect some fairly early conversion
into a single constant value. Perhaps I remain to be pleasantly surprised. I
wonder how the likes of LLVM manage this stuff. I'd guess they have just
deemed IEEE to be *the* correct representation for FP numbers, much as
twos complement is just assumed to be the only possible representation for
signed binary these days.
There is a pile of code, including, if I remember properly floating point emulation, so it can do floating point optimization on platforms which don't support floating point at all...


Dave



Tony H.
Re: memset help

 

On Fri, 17 Apr 2020 at 15:17, Dave Wade <dave.g4ugm@...> wrote:

When I first wrote the code to support "float.h" and floating point printf I worried about this.
I must admit that I have a vague recollection of this issue coming up
here before.

I found that GCC uses its own internal representation for floats during the compile procedure.
So whilst it might be hard to write extreme constants as float literals, and I had to resort to HEX, anything you do write as a
floating point literal will be consistently handled regardless of the platform on which you run the compiler.
Note I say "consistently" not "correctly" so you might not get what you expect, but it will be the same regardless of which
platform you run the compiler on.
With hindsight, given that GCC is inherently designed to be used as a cross-compiler, this should not be a surprise..
I'm still a bit unclear though on how the compiler can be consistent
in how it translates a float decimal input constant expression such as
3.14159 into a suitable hex FP representation in a (compiler)
platform-independent way. Probably I misunderstand how the compiler is
structured. I had thought that the (loosely speaking) front end was
platform independent, and that only the very back end would be aware
of things like the FP representation in use. Is that constant actually
carried in a representation-independent way (which can pretty much
only mean as the original string or some other truly decimal
representation) all the way through to where it is converted into a
hex FP value somewhere near the end?

I hate to imagine how any optimisation could be carried out, e.g. if
you have x = 3.14159 + 2.71828, where you would expect some fairly
early conversion into a single constant value. Perhaps I remain to be
pleasantly surprised. I wonder how the likes of LLVM manage this
stuff. I'd guess they have just deemed IEEE to be *the* correct
representation for FP numbers, much as twos complement is just assumed
to be the only possible representation for signed binary these days.

Tony H.
Re: memset help

 

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Tony
Harminc
Sent: 17 April 2020 18:26
To: [email protected]
Subject: Re: [h390-vm] memset help

On Thu, 16 Apr 2020 at 13:45, adriansutherland67
<adrian@...> wrote:
On Thu, Apr 16, 2020 at 03:22 PM, Harold Grovesteen wrote:
How is GCC supported? Is there a team or just some adhoc approach?
I believe that it it did "self host" at least once. And why would we
not try again? Pragmatically however there is no particular problem with
cross compiling it (and I am guessing this might be faster!).

If you're considering cross-compiling on a non S/370 architecture machine
(rather than, say, a modern IBM zArch box), you'll need to consider the
parsing and generation of floating point constants. It's possible this just
works, but I'd be suspicious that the compiler uses library routines that are
tied to the FP number representation.

Tony H.
Tony,
When I first wrote the code to support "float.h" and floating point printf I worried about this. I found that GCC uses its own internal representation for floats during the compile procedure.
So whilst it might be hard to write extreme constants as float literals, and I had to resort to HEX, anything you do write as a floating point literal will be consistently handled regardless of the platform on which you run the compiler.
Note I say "consistently" not "correctly" so you might not get what you expect, but it will be the same regardless of which platform you run the compiler on.
With hindsight, given that GCC is inherently designed to be used as a cross-compiler, this should not be a surprise..
Dave
Re: memset help

 

On Thu, 16 Apr 2020 at 13:45, adriansutherland67
<adrian@...> wrote:
On Thu, Apr 16, 2020 at 03:22 PM, Harold Grovesteen wrote:
How is GCC supported? Is there a team or just some adhoc approach?
I believe that it it did "self host" at least once. And why would we not try again? Pragmatically however there is no particular
problem with cross compiling it (and I am guessing this might be faster!).
If you're considering cross-compiling on a non S/370 architecture
machine (rather than, say, a modern IBM zArch box), you'll need to
consider the parsing and generation of floating point constants. It's
possible this just works, but I'd be suspicious that the compiler uses
library routines that are tied to the FP number representation.

Tony H.
Re: memset help

 

On Thu, 16 Apr 2020 at 08:11, Peter Coghlan <groups@...> wrote:

Of course, it's harder to locate MVCL instructions (X'0E') in an object deck
but there seem to be a few in there, including this one in URMON:
LA R0,1456(R0,R13)
LA R1,1024(R0,R0)
SLR R3,R3
MVCL R0,R2
This one is clearly zeroing storage - not copying data. R3 is the
"from" length field, and it's zero, so the MVCL is padding only (and
that pad byte is zero). And the "from" address in R2 is irrelevant and
so not set.

Tony H.
Re: Register Add - Quick Question

 

On Thu, 16 Apr 2020 at 14:56, adriansutherland67
<adrian@...> wrote:

You are gentlemen ... thank you!

It is for a 24 bit address.
A couple of points...

In modern (i.e. z) architectural variants, there are new immediate
instructions that may help with this. Notably there is AHI (Add
Halfword Immediate), which adds a 16-bit signed number from within the
instruction to a register. These are not in S/370, but in practice
they are in Hercules as a retrofitted feature.

The topic of addressing arithmetic in S/370 and successors is worth
becoming familiar with, and will probably help you understand why some
things are done the way they are. Essentially this arithmetic is
unsigned binary, with either one or two 32-bit register and one 12-bit
immediate inputs, and an output that is either 24-bits (in original
370 24-bit mode) or 31-bits (in XA mode and above). It has also been
extended to 64-bits in zArch (and the 12-bit input can be 20-bit in
some instructions), but that's a larger change. Overflows are ignored.

An interesting thing about this arithmetic is that, although it's
unsigned, it can still subtract - this is a surprise to many people
until they think about how twos complement number representation is
defined.

There is a whole section in the Principles of Operation on this.
Higher end machine models typically had a separate addressing adder
just for this purpose, since it is such a common operation.

Tony H.
Re: memset help

 

Mark L. Gaubatz wrote:

You have to be careful in analysis. The MVC sequences are intentionally
moving and modifying parts of Page Zero. This is probably related to
swapping of the current running user on MUSIC, or status being maintained
for the current user. In addition, the sequences shown would require
MULTIPLE MVCLs, thus MVC was the proper choice in the example.
It somehow failed to dawn on me that the MVCs in URMON were going to/from zero
page and therefore there was no possibility of some of the code being repeated
in a loop to move a full page.

However, I did check that the sources and destinations of the sequences of
four 256 byte MVCs are all consecutive, therefore each sequence of four 256
byte MVCs could have been replaced by a single MVCL to move 1024 bytes of
data at a one time, assuming availability of four suitable registers.


In addition, the two sequences are mirrors of each other. Basically, one
section is SAVE something and the other is RESTORE something. This is also
indicated by the moves/restores from FLC and the upper part of Page Zero.
Agreed.

These are not the only 256 byte MVCs in the MUSIC nucleus - they are just the
largest congregation of them in one place. I did some more hunting and I
found these in the TRACE module which move a total of 804 sequential bytes:

MVC 88(256,R5),0(R4)
MVC 344(256,R5),256(R4)
MVC 600(256,R5),512(R4)
MVC 856(36,R5),768(R4)

There are a few possible examples of one or two 256 byte MVCs, some of which
might be inside loops in all of these other modules:

FIOCS, SIOCS, MFIO USRSVC, LODSVC, TCS, COMAND, NEWTCB, FSIO, MCHINT, CDSRCH
and TRANTB.

However it is a bit of a chore to drag them all out and disassemble them to
find out when it is only of academic interest.

Regards,
Peter Coghlan


Mark


-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Peter Coghlan
Sent: Thursday, April 16, 2020 5:05 AM
To: [email protected]
Subject: Re: [h390-vm] memset help

Drew Derbyshire wrote:
On 4/14/20 11:32 PM, Peter Coghlan wrote:
I wonder could this have been the COBOL compiler abusing MVCL
instructions in situations where they were not the appropriate
instructions to use?

Perhaps instructions such as MVCL would be expected to be "hot
spots" because they can deliver a relatively large amount of work for a
single instruction?
Or is it that implementations of this instruction were sometimes
poorer than they ought to be and they were really not delivering bang
for buck?
I was told back in the 1980s that for performance reasons MUSIC moved
4096 bytes of data via a series of MVC commands in place of one MVCL.
My feeling is that something like this would be likely to have remained in
place forever more. I had a look through the "current" MUSIC nucleus object
deck for 256 byte MVC instructions (X'D2FF'). I found this section of code
in
the URMON module:

BR R14
LTR R4,R4
BZ 2224(R0,R12)
MVC 3112(4,R0),16(R0)
MVC 4056(4,R0),540(R0)
MVC 4060(4,R0),548(R0)
MVC 1456(256,R4),3072(R0)
MVC 1712(256,R4),3328(R0)
MVC 1968(256,R4),3584(R0)
MVC 2224(256,R4),3840(R0)
MVC 472(1,R4),3524(R12)
BR R14
MVC 3072(256,R0),1456(R13)
MVC 3328(256,R0),1712(R13)
MVC 3584(256,R0),1968(R13)
MVC 3840(256,R0),2224(R13)
MVC 16(4,R0),3112(R0)
MVC 540(4,R0),4056(R0)
MVC 548(4,R0),4060(R0)

Without doing a bit of work to figure out exactly what is going on, it is
not clear to me whether these code sections get called four times in a loop
or not but it could be the case.

Of course, it's harder to locate MVCL instructions (X'0E') in an object deck
but there seem to be a few in there, including this one in URMON:

ST R11,144(R0,R13)
XC 440(32,R13),440(R13)
LA R0,1456(R0,R13)
LA R1,1024(R0,R0)
SLR R3,R3
MVCL R0,R2
MVI 472(R13),32
L R5,3444(R0,R12)
ST R13,620(R0,R0)
LR R8,R12
L R12,3644(R0,R12)
BALR R14,R12

However, this could have been added later the lifetime of MUSIC.

Regards,
Peter Coghlan.

--
Drew Derbyshire

"All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
Re: memset help

 



MVC 3112(4,R0),16(R0)
MVC 4056(4,R0),540(R0)
MVC 4060(4,R0),548(R0)
For interest. Is that machine generated or hand crafted? If the latter must
have been very error prone and expensive!
In this particular case, it is the output of a disassembler. It's what we
have to cope with when we don't have the source code to look at.

Regards,
Peter Coghlan.
Re: memset help

 

On Fri, Apr 17, 2020 at 08:02 AM, Mark L. Gaubatz wrote:
MVC 3112(4,R0),16(R0)
MVC 4056(4,R0),540(R0)
MVC 4060(4,R0),548(R0)
For interest. Is that machine generated or hand crafted? If the latter must have been very error prone and expensive!
Re: memset help

 

You have to be careful in analysis. The MVC sequences are intentionally
moving and modifying parts of Page Zero. This is probably related to
swapping of the current running user on MUSIC, or status being maintained
for the current user. In addition, the sequences shown would require
MULTIPLE MVCLs, thus MVC was the proper choice in the example.

In addition, the two sequences are mirrors of each other. Basically, one
section is SAVE something and the other is RESTORE something. This is also
indicated by the moves/restores from FLC and the upper part of Page Zero.

Mark

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Peter Coghlan
Sent: Thursday, April 16, 2020 5:05 AM
To: [email protected]
Subject: Re: [h390-vm] memset help

Drew Derbyshire wrote:
On 4/14/20 11:32 PM, Peter Coghlan wrote:
I wonder could this have been the COBOL compiler abusing MVCL
instructions in situations where they were not the appropriate
instructions to use?

Perhaps instructions such as MVCL would be expected to be "hot
spots" because they can deliver a relatively large amount of work for a
single instruction?
Or is it that implementations of this instruction were sometimes
poorer than they ought to be and they were really not delivering bang
for buck?
I was told back in the 1980s that for performance reasons MUSIC moved
4096 bytes of data via a series of MVC commands in place of one MVCL.
My feeling is that something like this would be likely to have remained in
place forever more. I had a look through the "current" MUSIC nucleus object
deck for 256 byte MVC instructions (X'D2FF'). I found this section of code
in
the URMON module:

BR R14
LTR R4,R4
BZ 2224(R0,R12)
MVC 3112(4,R0),16(R0)
MVC 4056(4,R0),540(R0)
MVC 4060(4,R0),548(R0)
MVC 1456(256,R4),3072(R0)
MVC 1712(256,R4),3328(R0)
MVC 1968(256,R4),3584(R0)
MVC 2224(256,R4),3840(R0)
MVC 472(1,R4),3524(R12)
BR R14
MVC 3072(256,R0),1456(R13)
MVC 3328(256,R0),1712(R13)
MVC 3584(256,R0),1968(R13)
MVC 3840(256,R0),2224(R13)
MVC 16(4,R0),3112(R0)
MVC 540(4,R0),4056(R0)
MVC 548(4,R0),4060(R0)

Without doing a bit of work to figure out exactly what is going on, it is
not clear to me whether these code sections get called four times in a loop
or not but it could be the case.

Of course, it's harder to locate MVCL instructions (X'0E') in an object deck
but there seem to be a few in there, including this one in URMON:

ST R11,144(R0,R13)
XC 440(32,R13),440(R13)
LA R0,1456(R0,R13)
LA R1,1024(R0,R0)
SLR R3,R3
MVCL R0,R2
MVI 472(R13),32
L R5,3444(R0,R12)
ST R13,620(R0,R0)
LR R8,R12
L R12,3644(R0,R12)
BALR R14,R12

However, this could have been added later the lifetime of MUSIC.

Regards,
Peter Coghlan.

--
Drew Derbyshire

"All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
Re: memset help

 

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave
McGuire
Sent: 16 April 2020 22:28
To: [email protected]
Subject: Re: [h390-vm] memset help

On 4/16/20 4:47 PM, Steven Fosdick wrote:
(By the way, I replied to your recent "Inquiring minds" email but I
fear you may not have seen my reply as Google tends to route anything
I send these days isnto their recipients spam folder or otherwise
quarantine it. Apparantly Google regards me as a notorious source of
spam or something for some time now.
I also sent emails to other Google mail users both on the this list
not and these also seem to have disappeared into black holes...)
Oh dear. I have had the problem in the past of my e-mails being
picked up by spam filters and so has my brother. I think in our case
it was a case of the Scunthorpe problem
() - look at my
surname!
<keanu>
Whoa.
</keanu>

I sure wouldn't have wanted to be you in high school, Steve. ;)

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

Well a year or two ago a friend had trouble ordering train tickets from his employers preferred supplier because they were blocked in the firewall...
.. the supplier was of course Virgin Rail.....

On the other hand, of course when we managed the schools firewalls, we always dreaded the kids learning about Victoria and Albert.
Searching for images of "Prince Albert" may produce undesired results. If you are of a nervous disposition don't try it with safe search turned off...

Dave
Re: memset help

 

On 4/16/20 4:47 PM, Steven Fosdick wrote:
(By the way, I replied to your recent "Inquiring minds" email but I fear you
may not have seen my reply as Google tends to route anything I send these days
isnto their recipients spam folder or otherwise quarantine it. Apparantly
Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list not and
these also seem to have disappeared into black holes...)
Oh dear. I have had the problem in the past of my e-mails being
picked up by spam filters and so has my brother. I think in our case
it was a case of the Scunthorpe problem
() - look at my
surname!
<keanu>
Whoa.
</keanu>

I sure wouldn't have wanted to be you in high school, Steve. ;)

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA
Re: memset help

 

(By the way, I replied to your recent "Inquiring minds" email but I fear you
may not have seen my reply as Google tends to route anything I send these days
isnto their recipients spam folder or otherwise quarantine it. Apparantly
Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list not and
these also seem to have disappeared into black holes...)
Oh dear. I have had the problem in the past of my e-mails being
picked up by spam filters and so has my brother. I think in our case
it was a case of the Scunthorpe problem
() - look at my
surname!
Re: Register Add - Quick Question

 

On Thu, Apr 16, 2020 at 06:30 PM, Peter Coghlan wrote:
save two bytes:

AH R1,=H'8'
Peter ... You have taught me what F meant!
Re: Register Add - Quick Question

 

You are gentlemen ... thank you!

It is for a 24 bit address.

A
5501 - 5520 of 6546