Discussion:
S/370 as host and target
(too old to reply)
kerravon
2018-03-18 12:01:57 UTC
Permalink
Raw Message
Hi.

I have read this:

https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B

and it says that in 1984 a S/370 version was
released.

Is the source code for the 1984 version
available anywhere?

Regardless, it also says:

"The code is portable and, like many other open source compiler projects such as GCC or LCC the compiler backend (code generator) is retargetable."

So if a S370 backend existed in 1984, does
that mean it is in with a shot of working
with the current Open Watcom?

I downloaded the current Open Watcom source
code but didn't find any S/370 reference.

Note that I would be running this on the
equivalent of MVS/XA, so 2 GiB or 4 GiB
of memory would be available.

Thanks. Paul.
Steven Levine
2018-03-18 15:54:13 UTC
Permalink
Raw Message
On Sun, 18 Mar 2018 12:01:57 UTC, kerravon <***@w3.to> wrote:

Hi,
Post by kerravon
https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B
and it says that in 1984 a S/370 version was
released.
Is the source code for the 1984 version
available anywhere?
Unlikely. OpenWatcom is based on Watcom 11 or so. The way I read the
wikipedia article, the S/370 product was a totally different code
base.
Post by kerravon
"The code is portable and, like many other open source compiler projects such as GCC or LCC the compiler backend (code generator) is retargetable."
This is still true.
Post by kerravon
So if a S370 backend existed in 1984, does
that mean it is in with a shot of working
with the current Open Watcom?
If you are asking is it possible to reimplement a S370 backend, the
answer is yes, in the sense that the build system architecture will
allow it.
Post by kerravon
I downloaded the current Open Watcom source
code but didn't find any S/370 reference.
I've never seen anything that looks like it is related to the S/370 in
the current code base.

Steven
--
---------------------------------------------------------------------
Steven Levine <***@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
---------------------------------------------------------------------
Paul S. Person
2018-03-18 17:11:01 UTC
Permalink
Raw Message
On Sun, 18 Mar 2018 15:54:13 +0000 (UTC), "Steven Levine"
Post by Steven Levine
Hi,
Post by kerravon
https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B
and it says that in 1984 a S/370 version was
released.
Is the source code for the 1984 version
available anywhere?
Unlikely. OpenWatcom is based on Watcom 11 or so. The way I read the
wikipedia article, the S/370 product was a totally different code
base.
And, as such (that is, W11), was targeted entirely at PCs -- and
non-Linux PCs at that.
--
"Nature must be explained in
her own terms through
the experience of our senses."
Frank Beythien
2018-03-18 18:57:56 UTC
Permalink
Raw Message
Post by kerravon
Hi.
https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B
and it says that in 1984 a S/370 version was
released.
Is the source code for the 1984 version
available anywhere?
I don't think so.
Post by kerravon
"The code is portable and, like many other open source compiler projects such as GCC or LCC the compiler backend (code generator) is retargetable."
So if a S370 backend existed in 1984, does
that mean it is in with a shot of working
with the current Open Watcom?
No, there are some #ifdefs testing for 370, and about 5 sourcefiles with
370 in the filename, but Makefiles and 370 specific sourcefiles are
missing.

Frank
Marty Stanquist
2018-03-19 15:20:18 UTC
Permalink
Raw Message
Paul,

I think we'd want to get Linux/370 working first using a cpu emulator
running on an Intel host. This would be a useful product in itself.
Afterwards, we could then port it to MVS/XA.

Marty

"kerravon" wrote in message news:994c73e9-2916-470f-83ea-***@googlegroups.com...

Hi.

I have read this:

https://en.wikipedia.org/wiki/Watcom_C/C%2B%2B

and it says that in 1984 a S/370 version was
released.

Is the source code for the 1984 version
available anywhere?

Regardless, it also says:

"The code is portable and, like many other open source compiler projects
such as GCC or LCC the compiler backend (code generator) is retargetable."

So if a S370 backend existed in 1984, does
that mean it is in with a shot of working
with the current Open Watcom?

I downloaded the current Open Watcom source
code but didn't find any S/370 reference.

Note that I would be running this on the
equivalent of MVS/XA, so 2 GiB or 4 GiB
of memory would be available.

Thanks. Paul.
kerravon
2018-03-19 16:33:07 UTC
Permalink
Raw Message
Post by Marty Stanquist
I think we'd want to get Linux/370 working first using a cpu emulator
running on an Intel host. This would be a useful product in itself.
Afterwards, we could then port it to MVS/XA.
Hi Marty. Thanks for the interest.

Are you aware that there is an emulator
called Hercules?

There is a z/Linux available that runs
under that emulator. I'm not familiar
with it (but I can ask if helpful), but
it should accept pure S/370 instructions
as well as the z/Arch instructions.

There is also MVS 3.8j available to run
under the emulator, plus there's a
derivative of that called MVS/380 which
supports 31-bit addressing and 32-bit
addressing is on the cards too. This is
what I am involved with, and I run on
my PC under Windows 64-bit. Using this
system I have already ported GCC to MVS,
but I only provided the C90 runtime
library (called PDPCLIB), which could
be used by OW too. Someone else did the
machine definitions and the fixes for
EBCDIC. I also basically made GCC C90
compliant as far as runtime requirements.
It only generate assembler output and I
use the IBM assembler to produce the
object code.

BFN. Paul.
Marty Stanquist
2018-03-20 05:54:41 UTC
Permalink
Raw Message
Post by Marty Stanquist
I think we'd want to get Linux/370 working first using a cpu emulator
running on an Intel host. This would be a useful product in itself.
Afterwards, we could then port it to MVS/XA.
Hi Marty. Thanks for the interest.

Are you aware that there is an emulator
called Hercules?

There is a z/Linux available that runs
under that emulator. I'm not familiar
with it (but I can ask if helpful), but
it should accept pure S/370 instructions
as well as the z/Arch instructions.

There is also MVS 3.8j available to run
under the emulator, plus there's a
derivative of that called MVS/380 which
supports 31-bit addressing and 32-bit
addressing is on the cards too. This is
what I am involved with, and I run on
my PC under Windows 64-bit. Using this
system I have already ported GCC to MVS,
but I only provided the C90 runtime
library (called PDPCLIB), which could
be used by OW too. Someone else did the
machine definitions and the fixes for
EBCDIC. I also basically made GCC C90
compliant as far as runtime requirements.
It only generate assembler output and I
use the IBM assembler to produce the
object code.

BFN. Paul.

Thanks Paul,

Where is the current documentation for Hercules, zLinux, and the S/370
family instruction set?

Initially, we would have two options, both of which would build the tool
chain on a Windows host:

1). Using Windows, build a Windows hosted tool chain that includes an S/370
target code generator for zLinux. Develop the application code on Windows.
Debug the code using a Window hosted emulator, such as Hercules, that runs
zLinux and the application under emulation.

2). Using Windows, build a zLinux hosted tool chain, including the S/370
target code generator above, that runs in native mode. Develop and debug the
application directly on zLinux/370 without emulation.

Later on, we will have a third option to build the tool chain directly on
the S/370. But this is a ways out. As it stands, the tool chain requires
Open Watcom 1.90 or GCC 3.x without C99. The process for MVS/XA would be
similar.

Marty
kerravon
2018-03-20 06:36:10 UTC
Permalink
Raw Message
Post by Marty Stanquist
Where is the current documentation for Hercules, zLinux, and the S/370
family instruction set?
Hercules is here:

http://www.hercules-390.eu/

zLinux I have never run, but it is here:

http://www.hercules-390.eu/hercfaq.html#2.08
http://www.linuxvm.org/

and I see that it has an S/390 port as
well as z/Arch port.

Do you wish to produce 32-bit or 64-bit
instructions? Can I suggest you start
with 32-bit instructions, and in particular
S/370 instructions rather than ESA/390
instructions, as hobbyists are still
running on S/370 emulated hardware so
that they can use the old operating
systems.

If you target the S/370, everything is
upwardly compatible. That is what I did
with GCCMVS.

z/Arch introduced 64-bit instructions.

If you wish to go with S/370 instructions,
would the GCC machine definition be
helpful? If not, the definitive reference
is the Principle of Operations, which can
be obtained from here:

http://bitsavers.org/pdf/ibm/370/princOps/GA22-7000-10_370_Principles_of_Operation_Sep87.pdf

Note that someone else wrote the GCC
machine definition, I just tweaked it
a bit.
Post by Marty Stanquist
2). Using Windows, build a zLinux hosted tool chain, including the S/370
target code generator above, that runs in native mode. Develop and debug the
application directly on zLinux/370 without emulation.
I don't understand this "without emulation".
You always need to run z/Linux under an
emulator unless you have access to z/Arch
hardware.

Also note that when it comes to MVS/XA
or similar, unlike z/Linux, they operate
with EBCDIC, so the code generator would
need to know how to produce that.

Also the MVS-style assembler code is
different from z/Linux-style assembler.

Also note that it would be good if there
was one day an option to generate the
64-bit instructions so that "long" can
be 64 bits. That would need to be tested
on z/Linux or MVS/380, and at that point
you need the z/Arch Principles of Operation
instead. Basically the 32-bit register load
instruction "L" has a 64-bit counterpart
"LG", things like that.

Note that GCC 3.2.3 comes with a "i370"
target which produces MVS-style assembler
for S/370, while modern GCC only comes
with "s390" which is Linux-style assembler
and generates either S/390 instructions
(32-bit enhancements to S/370 that I
would prefer were not used), or the
64-bit z/Arch instructions where you can
see "LG" etc, if the "-m64" option is
used.

Let me know if any of that is unclear.

BFN. Paul.
kerravon
2018-03-20 10:11:07 UTC
Permalink
Raw Message
Another thing to note.

I have a product called "PDPCLIB" which
is a C90 runtime library for MVS (also
other environments like Windows, OS/2
etc).

If Watcom starts producing HLASM-style
S/370 assembler code, using EBCDIC rather
than ASCII, we should be able to get a
"hello world" up and running on MVS
soon afterwards.

Note that PDPCLIB is explicit notice
public domain, so it can be used in any
other project.

BFN. Paul.
Marty Stanquist
2018-03-20 17:31:55 UTC
Permalink
Raw Message
"kerravon" wrote in message news:74b36dbf-a05e-42d7-9164-***@googlegroups.com...

Another thing to note.

I have a product called "PDPCLIB" which
is a C90 runtime library for MVS (also
other environments like Windows, OS/2
etc).

If Watcom starts producing HLASM-style
S/370 assembler code, using EBCDIC rather
than ASCII, we should be able to get a
"hello world" up and running on MVS
soon afterwards.

Note that PDPCLIB is explicit notice
public domain, so it can be used in any
other project.

BFN. Paul.

Hi Paul,

Just a quick update. This is useful. You're answering many of my questions.
For option 2, you would develop and debug the application on zArch hardware
without emulation. And yes, we would need to output different object and
possibly assembler formats that work with the target system. Would you be
able to provide a brief overview of the changes made on the S/380 and S/390?
I'm not familiar with these. Thanks.

Marty
kerravon
2018-03-20 18:25:46 UTC
Permalink
Raw Message
Post by Marty Stanquist
For option 2, you would develop and
debug the application on zArch hardware
without emulation.
We're not likely to get access to real
z/Arch hardware for development. We will
need to do everything under Hercules.
Post by Marty Stanquist
And yes, we would need to output different object and
possibly assembler formats that work with the target system. Would you be
able to provide a brief overview of the changes made
on the S/380 and S/390?
I'm not familiar with these. Thanks.
True S/370 only provides 24-bit addressing,
meaning if an application needs more than
16 MiB of memory, it is technically
impossible to run.

There are two different paths that overcame
the 24-bit addressing limit, and increased
it to 31-bit. One is real hardware from IBM.
That's the S/390 route. If you wrote your
S/370 code "properly", all you need to do is
mark your load module "AM31/RMANY" and
suddenly your S/370 application has access
to 2 GiB of memory (31-bit addressing). As
well as doing that, IBM added more
instructions.

The second path is a modification to the
Hercules emulation software, called S/380.
In its simplest form, it simply adds the
same BSM instruction found in S/390. Also
the MVCLE and CLCLE instructions from S/390
are added so that if you are moving or
comparing a block of memory that is equal
to or greater than 16 MiB in length, you
can do so.

The compiler doesn't need to know about
BSM. So long as you generate S/370 instructions,
if a BSM is used, it goes into the
assembler portion of the C runtime library
for MVS. Ideally you would also emit
MVCLE/CLCLE, but only if you detect a length
greater than or equal to 16 MiB.

In practice, S/380 has been expanded to
include most instructions from S/390, so
if you aren't willing to stick with the
S/370 instruction set, well, even hobbyists
can access the required hardware. But
to do so they will need to run Hercules/380
instead of standard Hercules. Sort of.
I can explain in more detail if required.

In addition there is a beta Hercules/380
that includes most z/Arch instructions,
to produce a z/380, so even 64-bit
programming is available to hobbyists.

But from a code-generation point of view,
your major choices are last S/370, last
S/390 (all 32-bit only), first z/Arch
(my suggestion as lowest common
denominator), or most recent z/Arch.

If you want to know all the great
instructions they added in S/390 you
need to look at the ESA/390 Principles
of Operation instead of the S/370 one
which I already pointed you to. Let me
know if you'd like a pointer to that.

If you choose to use S/390 features
like long displacement, the old
assembler that hobbyists have access
to is not able to assemble that. So
I really do encourage you to do what
GCC on MVS does, which is generate
pure S/370 code.

Also note that I have batch run
facilities for MVS/380 under Hercules/380
such that you don't need to know
anything about MVS, you just stick with
your Windows editor, execute a Windows
batch file and wait half a minute for a
result in an output text file. I can get
you set up with that if you're interested
in doing MVS first.

BFN. Paul.
Marty Stanquist
2018-03-22 01:47:59 UTC
Permalink
Raw Message
Post by Marty Stanquist
For option 2, you would develop and
debug the application on zArch hardware
without emulation.
We're not likely to get access to real
z/Arch hardware for development. We will
need to do everything under Hercules.
Post by Marty Stanquist
And yes, we would need to output different object and
possibly assembler formats that work with the target system. Would you be
able to provide a brief overview of the changes made
on the S/380 and S/390?
I'm not familiar with these. Thanks.
True S/370 only provides 24-bit addressing,
meaning if an application needs more than
16 MiB of memory, it is technically
impossible to run.

There are two different paths that overcame
the 24-bit addressing limit, and increased
it to 31-bit. One is real hardware from IBM.
That's the S/390 route. If you wrote your
S/370 code "properly", all you need to do is
mark your load module "AM31/RMANY" and
suddenly your S/370 application has access
to 2 GiB of memory (31-bit addressing). As
well as doing that, IBM added more
instructions.

The second path is a modification to the
Hercules emulation software, called S/380.
In its simplest form, it simply adds the
same BSM instruction found in S/390. Also
the MVCLE and CLCLE instructions from S/390
are added so that if you are moving or
comparing a block of memory that is equal
to or greater than 16 MiB in length, you
can do so.

The compiler doesn't need to know about
BSM. So long as you generate S/370 instructions,
if a BSM is used, it goes into the
assembler portion of the C runtime library
for MVS. Ideally you would also emit
MVCLE/CLCLE, but only if you detect a length
greater than or equal to 16 MiB.

In practice, S/380 has been expanded to
include most instructions from S/390, so
if you aren't willing to stick with the
S/370 instruction set, well, even hobbyists
can access the required hardware. But
to do so they will need to run Hercules/380
instead of standard Hercules. Sort of.
I can explain in more detail if required.

In addition there is a beta Hercules/380
that includes most z/Arch instructions,
to produce a z/380, so even 64-bit
programming is available to hobbyists.

But from a code-generation point of view,
your major choices are last S/370, last
S/390 (all 32-bit only), first z/Arch
(my suggestion as lowest common
denominator), or most recent z/Arch.

If you want to know all the great
instructions they added in S/390 you
need to look at the ESA/390 Principles
of Operation instead of the S/370 one
which I already pointed you to. Let me
know if you'd like a pointer to that.

If you choose to use S/390 features
like long displacement, the old
assembler that hobbyists have access
to is not able to assemble that. So
I really do encourage you to do what
GCC on MVS does, which is generate
pure S/370 code.

Also note that I have batch run
facilities for MVS/380 under Hercules/380
such that you don't need to know
anything about MVS, you just stick with
your Windows editor, execute a Windows
batch file and wait half a minute for a
result in an output text file. I can get
you set up with that if you're interested
in doing MVS first.

BFN. Paul.

Paul,

I'd like to continue the discussion in the assembler newsgroup
(openwatcom.users.assembler). See you there.

Marty
kerravon
2018-03-22 04:00:25 UTC
Permalink
Raw Message
Post by Marty Stanquist
I'd like to continue the discussion in the assembler newsgroup
(openwatcom.users.assembler). See you there.
Hi Marty. That group doesn't show up
when I do a search:

https://groups.google.com/forum/#!forumsearch/openwatcom

Other groups do, but none assembler-related.

BFN. Paul.
Marty Stanquist
2018-03-22 15:48:32 UTC
Permalink
Raw Message
Post by Marty Stanquist
I'd like to continue the discussion in the assembler newsgroup
(openwatcom.users.assembler). See you there.
Hi Marty. That group doesn't show up
when I do a search:

https://groups.google.com/forum/#!forumsearch/openwatcom

Other groups do, but none assembler-related.

BFN. Paul.

Hi Paul,

You'll need a newsreader or email program. Point it to news.openwatcom.org,
protocol NNTP, port 119. No password or login ID are required. After
configuring your newsreader, subscribe to groups contributors and
users.assembler.

Marty
kerravon
2018-03-22 17:13:02 UTC
Permalink
Raw Message
Post by Marty Stanquist
Post by kerravon
Hi Marty. That group doesn't show up
You'll need a newsreader or email program.
Point it to news.openwatcom.org,
protocol NNTP, port 119. No password or
login ID are required.
Hi Marty. I didn't know very much about
this stuff, and I wondered what exactly
NNTP was, so I started writing some code
to interact with news.openwatcom.org and
I was successful. Then I bit the bullet
and implemented the bare minimum socket
functionality in Hercules/380 and I was
also successful.

So if you look here:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/18007

you can see your message. The first message
that MVS/380 has ever retrieved from the
internet.

In order to reply to you, I need some
RFC822 headers I believe. I'm also not
familiar with that. Is it OK if I reply
to your message with the bare minimum
RFC822 headers that your news server
will accept? Basically can I experiment
to see if you can read my messages?

Thanks. Paul.
Marty Stanquist
2018-03-23 14:32:04 UTC
Permalink
Raw Message
Post by Marty Stanquist
Post by kerravon
Hi Marty. That group doesn't show up
You'll need a newsreader or email program.
Point it to news.openwatcom.org,
protocol NNTP, port 119. No password or
login ID are required.
Hi Marty. I didn't know very much about
this stuff, and I wondered what exactly
NNTP was, so I started writing some code
to interact with news.openwatcom.org and
I was successful. Then I bit the bullet
and implemented the bare minimum socket
functionality in Hercules/380 and I was
also successful.

So if you look here:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/18007

you can see your message. The first message
that MVS/380 has ever retrieved from the
internet.

In order to reply to you, I need some
RFC822 headers I believe. I'm also not
familiar with that. Is it OK if I reply
to your message with the bare minimum
RFC822 headers that your news server
will accept? Basically can I experiment
to see if you can read my messages?

Thanks. Paul.

Hi Paul,

Use thread "test, please ignore" in group users.assembler for this purpose,
noting that you are testing MVS/380. I'll monitor the thread.

Marty
kerravon
2018-03-23 16:12:38 UTC
Permalink
Raw Message
Post by Marty Stanquist
Use thread "test, please ignore" in
group users.assembler for this purpose,
noting that you are testing MVS/380.
I'll monitor the thread.
Thanks Marty.

It seems to have worked successfully!

The only odd thing is that when I retrieve
the message, I see this:

From: Paul Edwards <***@gm
ail.com>

ie this line has been split in two. I have
no explanation for that.

Anyway, you can now move your reply to this
message in the other group, as I will be
monitoring for new messages every day
using my new program running under MVS/380.

So long as you can read my replies there,
anyway. That split "From" may make my
messages unreadable.

Thanks. Paul.
kerravon
2018-03-23 16:24:12 UTC
Permalink
Raw Message
Post by kerravon
The only odd thing is that when I retrieve
ail.com>
ie this line has been split in two. I have
no explanation for that.
I know what caused that now. A bug in
my program. I've fixed that and sent
a new message.

Please delete the old message because
it is technically invalid.

If you're happy with the latest message,
which has a valid "from", we can continue
in that group.

Thanks. Paul.
Marty Stanquist
2018-04-02 17:01:31 UTC
Permalink
Raw Message
Post by kerravon
The only odd thing is that when I retrieve
ail.com>
ie this line has been split in two. I have
no explanation for that.
I know what caused that now. A bug in
my program. I've fixed that and sent
a new message.

Please delete the old message because
it is technically invalid.

If you're happy with the latest message,
which has a valid "from", we can continue
in that group.

Thanks. Paul.

Hi Paul,

I'm still reviewing this and will let you know.

Marty
Marty Stanquist
2018-04-06 17:13:26 UTC
Permalink
Raw Message
Post by kerravon
The only odd thing is that when I retrieve
ail.com>
ie this line has been split in two. I have
no explanation for that.
I know what caused that now. A bug in
my program. I've fixed that and sent
a new message.

Please delete the old message because
it is technically invalid.

If you're happy with the latest message,
which has a valid "from", we can continue
in that group.

Thanks. Paul.

Hi Paul,

I'm still reviewing this and will let you know.

Marty

Paul,

You should be OK to continue here. If you need to make additional changes,
use the other thread.

Marty

Loading...