Pascal


Paul Edwards
 

Not sure if anyone is interested in Pascal, but this technique:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pascal/

has doubled the number of languages supported by PDOS/386,
for very low cost.

I checked already, and the project to get Free Pascal to generate
S/370 code stalled in 2012 it seems.

But if that is ever done, supporting Pascal on MVS should be
trivial. The exact same code can be used, just the assembler
"glue" needs to have a S/370 version.

Now that I think about it, maybe Fortran etc programs can
be supported on PDOS/3X0 using the same technique.
It depends what sort of code they generate. That would
be a really interesting exercise in fact. Get a Fortran
"hello world" to work using PDPCLIB. Or Cobol. How
complicated could they have made it?

BFN. Paul.


Mark Waterbury
 

Paul,

See:
       https://github.com/StanfordPascal

and see also:
      http://www.jaymoseley.com/hercules/compilers/Nstpascal.htm

Mark


Paul Edwards
 

On Thu, Jul 8, 2021 at 07:37 AM, Mark Waterbury wrote:

See: https://github.com/StanfordPascal
Thanks.

I couldn't find what the copyright status was of this package.
But that's not really important if I'm replacing the runtime
anyway.

I noticed that there is an AM24 restriction. I wonder what is
causing that. Anyway, I would hope that by replacing the
runtime I would end up with Pascal executables that are
AM24/31/32, and if the Pascal compiler doesn't generate
negative indexes, it would support AM64 too, making it
better than C programs.

But I didn't stumble across the runtime library to see what
the interface specs are.

If someone would like to work with me on this, please let
me know. Otherwise I might do it if/when my Filipino
programmers have been trained.

Note that one of them published a micro-emacs executable
for PDOS/386 yesterday:

http://pdos.org

Not previously available. I'm refusing to publish copyrighted
executables now, so it is dependent on others. A new version
of Hercules/380 will be dependent on that too.

BFN. Paul.


Joe Monk
 

"But that's not really important if I'm replacing the runtime
anyway."

Good luck with that. Bernd's compiler translates to p-code which is dependent on his runtime for the specific platform.

Joe

On Wed, Jul 7, 2021 at 7:08 PM Paul Edwards <mutazilah@...> wrote:
On Thu, Jul  8, 2021 at 07:37 AM, Mark Waterbury wrote:

> See: https://github.com/StanfordPascal

Thanks.

I couldn't find what the copyright status was of this package.
But that's not really important if I'm replacing the runtime
anyway.

I noticed that there is an AM24 restriction. I wonder what is
causing that. Anyway, I would hope that by replacing the
runtime I would end up with Pascal executables that are
AM24/31/32, and if the Pascal compiler doesn't generate
negative indexes, it would support AM64 too, making it
better than C programs.

But I didn't stumble across the runtime library to see what
the interface specs are.

If someone would like to work with me on this, please let
me know. Otherwise I might do it if/when my Filipino
programmers have been trained.

Note that one of them published a micro-emacs executable
for PDOS/386 yesterday:

http://pdos.org

Not previously available. I'm refusing to publish copyrighted
executables now, so it is dependent on others. A new version
of Hercules/380 will be dependent on that too.

BFN. Paul.






Paul Edwards
 

On Thu, Jul 8, 2021 at 07:20 PM, Joe Monk wrote:

But that's not really important if I'm replacing the runtime
anyway.
Good luck with that. Bernd's compiler translates to p-code which is
dependent on his runtime for the specific platform.
His website says it translates p-code into S/370
assembler.

Once I have S/370 assembler, I don't see how he could
have made life difficult for me. Just how many lines of
S/370 assembler code does a "hello.pas" translate into?

My experience with FPC is "not that much".

BFN. Paul.


Joe Monk
 

First off, this is Stanford Pascal. So every module contains:

***********************************************************************
*
*     Original comment from 1976:
*
***********************************************************************
*
*     COPYRIGHT 1976, STANFORD LINEAR ACCELERATOR CENTER.
*
*     THE FOLLOWING PROGRAMS CREATE  THE  RUN-TIME  ENVIRONMENT  AND
*     PROVIDE THE I/O INTERFACE FOR THE SLAC 'PASCAL' COMPILER.


Second:

"His website says it translates p-code into S/370
assembler."

No, The main translation is straight 370 object code.

Joe


On Thu, Jul 8, 2021 at 4:28 AM Paul Edwards <mutazilah@...> wrote:
On Thu, Jul  8, 2021 at 07:20 PM, Joe Monk wrote:

>> But that's not really important if I'm replacing the runtime
>> anyway.
>
> Good luck with that. Bernd's compiler translates to p-code which is
> dependent on his runtime for the specific platform.

His website says it translates p-code into S/370
assembler.

Once I have S/370 assembler, I don't see how he could
have made life difficult for me. Just how many lines of
S/370 assembler code does a "hello.pas" translate into?

My experience with FPC is "not that much".

BFN. Paul.






Paul Edwards
 

On Thu, Jul 8, 2021 at 10:35 PM, Joe Monk wrote:

First off, this is Stanford Pascal. So every module contains:

* COPYRIGHT 1976, STANFORD LINEAR ACCELERATOR CENTER.
Thanks.

His website says it translates p-code into S/370
assembler.
No, The main translation is straight 370 object code.
Ok. I can live with that. The disassembly output will show
what function calls are made. Once I know that, I should
be able to replace them quite easily. That was certainly
the case with Free Pascal. I can't conceive of how
Stanford could have made life difficult for me there.

BFN. Paul.


Mark Waterbury
 

Paul and Joe,

There should be no need to "disassemble" anything.  The Stanford Pascal compiler had an option to also generate the Assembler source code, as well as the object deck.

Also, there should be no system dependent code generated -- all the "runtime" dependencies should be isolated in a small runtime module that is linked into the program and sets up the environment, etc.  The so-called "sub-monitor" provides the I/O interface.  Also be aware that if you use floating point, you may need access to the IBM FORTRAN #IBCOM runtime library routines.

See this document:
   https://www.slac.stanford.edu/vault/collvault/greylit/cgtm/CGTM196.pdf  

for a good overview of how that compiler front-end, back-end translator (object code generator) and runtime monitor is structured.

Mark

 


Markus Loew
 

Could it be possible to reactivate the efforts to make available fpc to S/370.?
I would be willing to contribute to such a project. fpc is highly efficient.
rgds
Markus Loew


Paul Edwards
 

On Fri, Oct 22, 2021 at 08:01 AM, Markus Loew wrote:

Could it be possible to reactivate the efforts to make available fpc to
S/370.?
I would be willing to contribute to such a project. fpc is highly efficient.
I did a search, and the guy you need to contact is Paul Robinson
from Viridian Development Corporation. Start here:

https://wiki.lazarus.freepascal.org/ZSeries

I doubt you'll get anywhere though, as it sounds like it is a
company project that the company has abandoned rather
than a labor of love.

Is there a reason you want fpc instead of Stanford Pascal
from Bernd?

BFN. Paul.


Markus Loew
 

Hello Paul,

I tried to work with Stanford Pascal. But there are quite a number of incompatibilities
that do not allow a one to one usability of source code. If I want to compile and use
Stanford code in fpc, then I have to make changes, vice versa.
fpc comes with a huge collection of libraries, And it is enormously flexible.
Last but not least, it runs on a great number of operating systems.
Maybe you have noticed that I use it  (see Listing and LstLight, files section
of the TurnKey MVS group). I use it as much as PL/I(F) in TK4-. If I need some
data to be created, or to be modified, then with these two languages I can do it
within minutes in simple cases. It is much faster than looking for, and find a utility
eventually, that does what I want to do.

Contributing to a port of fpc to MVS 3.8j on a S/370 would be a great pleasure for me.
I would start it on my own. But I need some help. First I need to find people who already
did it for the other platforms, very good would be to get a hold of Mr Robinson.
I need to know, if there is a strategy, e.g. some kind of nucleus, or minimum you
have to prepare on the new target system, in order to use existing, well tested source
code, letting grow the S/370 fpc .I also need to know, how to get "on board" of the fpc
developers community, in order to learn about, how to proceed.

Ok, my first step is to try to speak to Paul Robinson.

Greetings
Markus Loew


Paul Edwards
 

On Fri, Oct 22, 2021 at 09:38 PM, Markus Loew wrote:

Contributing to a port of fpc to MVS 3.8j on a S/370 would be a great pleasure
for me.
I would start it on my own.
BTW, does this imply you have the skills to write a compiler?

If you could fix the i370 port to stop it from generating negative
indexes, that would be really great.

Or on the 80386 side there are some enhancements I would
like made to "subc".

BFN. Paul.


Markus Loew
 

On Fri, Oct 22, 2021 at 11:43 PM, Paul Edwards wrote:
BTW, does this imply you have the skills to write a compiler?
I hope it to be like that :-) I already have written interpreters, and the phases from source code to machine code are known to me as well.
The special challenge lies certainly in the 4Kb per base register addressing , making heap and stack oriented algorithms fairly spicy.
For me such a project is learning as well, doing things I have never done before. As I will not get any salary for that, I will be paid
by increasing my expertise, something more beneficial to me than money.

If you could fix the i370 port to stop it from generating negative
indexes, that would be really great.
does it concern GCCMVS?
what i370 port are you speaking about? what code do you speak about? where and how does appear that error?

Or on the 80386 side there are some enhancements I would
like made to "subc".
does it all concern GCCMVS as well?

My knowledge about the i686 instruction set is very reduced, and it will certainly take some effort
to reactivate my 370 assembler programming expertise (a question of a few days).

Finally I hope to find one or two experienced enthusiasts, inspired and motivated to take part in a
"fpc for MVS 3.8j port" project  team, I would like to create. Willing to learn is the best motivation.
And a good teacher is welcome as well. It IS an ambitious goal.

BTW I have started to look for Paul Robinson. I have written a mail to Kent Tessman (kent@...),
the creator of the Hugo programming language. It is well possible that he knows Mr Robinson, as I found his
compay's name mentioned together with Hugo. I sent a hidden copy to the owner of this group, in the hope
that it is you :-)

Actually I am studying the source code of Stanford Pascal, made available to MVS 3.8j by Bernd Oppolzer.

b rgds
Markus Loew


Paul Edwards
 

On Sat, Oct 23, 2021 at 12:41 PM, Markus Loew wrote:

If you could fix the i370 port to stop it from generating negative
indexes, that would be really great.
does it concern GCCMVS?
Yep.

what i370 port are you speaking about?
GCCMVS used/uses the existing i370 port of GCC. It was
decommissioned after 3.4.6.

what code do you speak about? where and
how does appear that error?
If you run this code (or similar):

F:\devel\gcc\gcc>type bug34.c
/* Demonstrate a 32-bit bug in GCC 3.2.3 v9.0 when
using a negative index. */

char buf[5];
char *end = &buf[4];

void foo(void)
{
end[-1] = 'X';
return;
}


through gcc -Os you will get:

L 2,=A(END)
L 3,4+=A(END)
L 3,0(2)
L 2,=F'-1'
L 4,=F'-25'
STC 4,0(2,3)

See that use of R2 being set to -1 as an index? That has been
screwing up 32-bit S/3X0 code for something like a decade.

It is preventing z/PDOS to be able to cope with 32-bit code
and 64-bit code running with no mode changes required
whatsoever. z/PDOS simply goes into AM64 at startup and
no further mode changes are required.

If you know how to constrain index registers to positive numbers
only, we're in business. There's very little code that uses negative
indexes, so it's not a performance problem. But just one line of
generated code that uses it and we're screwed.

IBM is being coy in the GCC mailing list about how to apply that
constraint, probably because they realize the ramifications of it.

I've tried various things myself without success.

The same problem affects the still-extant s390 target.

I can actually test it myself if you just tell me what to try.

Or on the 80386 side there are some enhancements I would
like made to "subc".
does it all concern GCCMVS as well?
No, "subc" is another compiler. You can get both the gccmvs
and the subc source code in custom.zip from http://pdos.org

It would be good if subc could be modified to produce S/370
code too. Note that subc is public domain, which is why I'm so
keen on it. If the 80386 version can be made sufficiently
functional I will build PDOS/386 with subc instead of gccwin.

My knowledge about the i686 instruction set is very reduced,
It's 386 that I want, and I think most of the problems in subc
are related to parsing C code, not instruction generation.

BTW, I believe there is a "GNU Pascal" but I don't know the
details. That might be another option instead of fpc.

and it will
certainly take some effort
to reactivate my 370 assembler programming expertise (a question of a few
days).
That's certainly quick.

Finally I hope to find one or two experienced enthusiasts, inspired and
motivated to take part in a
"fpc for MVS 3.8j port" project  team, I would like to create. Willing to
learn is the best motivation.
And a good teacher is welcome as well. It IS an ambitious goal.
Note that as part of the PDOS/386 project I have a "pascal"
target which provides a small runtime for fpc so that
executables you produce do not have copyrighted code in them.

BTW I have started to look for Paul Robinson. I have written a mail to Kent
Tessman ( kent@generalcoffee.com ),
the creator of the Hugo (
http://web.archive.org/web/20110611063518/http://wurb.com/if/devsys/4 )
programming language. It is well possible that he knows Mr Robinson, as I
found his
compay's name mentioned together with Hugo. I sent a hidden copy to the owner
of this group, in the hope
that it is you :-)
Yes, that came through, and I already replied.

Actually I am studying the source code of Stanford Pascal, made available to
MVS 3.8j by Bernd Oppolzer.
Ok.

BFN. Paul.


Joe Monk
 

"See that use of R2 being set to -1 as an index? That has been
screwing up 32-bit S/3X0 code for something like a decade.

"It is preventing z/PDOS to be able to cope with 32-bit code
and 64-bit code running with no mode changes required
whatsoever. z/PDOS simply goes into AM64 at startup and
no further mode changes are required.

"If you know how to constrain index registers to positive numbers
only, we're in business. There's very little code that uses negative
indexes, so it's not a performance problem. But just one line of
generated code that uses it and we're screwed."

Hmmm ....

S/360 PrincOps:

image.png

S/370 PrincOps:

image.png
S/370-XA PrincOps:

image.png



z/Arch PrincOps:

image.png

So, I am confused. Every PrincOps manual I can find says that a negative index in a register is irrelevant because the sign bit is ignored. So, how is this affecting you?

Joe




On Fri, Oct 22, 2021 at 9:33 PM Paul Edwards <mutazilah@...> wrote:
On Sat, Oct 23, 2021 at 12:41 PM, Markus Loew wrote:

> > If you could fix the i370 port to stop it from generating negative
> > indexes, that would be really great.
>
> does it concern GCCMVS?

Yep.

> what i370 port are you speaking about?

GCCMVS used/uses the existing i370 port of GCC. It was
decommissioned after 3.4.6.

> what code do you speak about? where and
> how does appear that error?

If you run this code (or similar):

F:\devel\gcc\gcc>type bug34.c
/* Demonstrate a 32-bit bug in GCC 3.2.3 v9.0 when
   using a negative index. */

char buf[5];
char *end = &buf[4];

void foo(void)
{
    end[-1] = 'X';
    return;
}


through gcc -Os you will get:

         L     2,=A(END)
         L     3,4+=A(END)
         L     3,0(2)
         L     2,=F'-1'
         L     4,=F'-25'
         STC   4,0(2,3)

See that use of R2 being set to -1 as an index? That has been
screwing up 32-bit S/3X0 code for something like a decade.

It is preventing z/PDOS to be able to cope with 32-bit code
and 64-bit code running with no mode changes required
whatsoever. z/PDOS simply goes into AM64 at startup and
no further mode changes are required.

If you know how to constrain index registers to positive numbers
only, we're in business. There's very little code that uses negative
indexes, so it's not a performance problem. But just one line of
generated code that uses it and we're screwed.

IBM is being coy in the GCC mailing list about how to apply that
constraint, probably because they realize the ramifications of it.

I've tried various things myself without success.

The same problem affects the still-extant s390 target.

I can actually test it myself if you just tell me what to try.

> > Or on the 80386 side there are some enhancements I would
> > like made to "subc".
>
> does it all concern GCCMVS as well?

No, "subc" is another compiler. You can get both the gccmvs
and the subc source code in custom.zip from http://pdos.org

It would be good if subc could be modified to produce S/370
code too. Note that subc is public domain, which is why I'm so
keen on it. If the 80386 version can be made sufficiently
functional I will build PDOS/386 with subc instead of gccwin.

> My knowledge about the i686 instruction set is very reduced,

It's 386 that I want, and I think most of the problems in subc
are related to parsing C code, not instruction generation.

BTW, I believe there is a "GNU Pascal" but I don't know the
details. That might be another option instead of fpc.

> and it will
> certainly take some effort
> to reactivate my 370 assembler programming expertise (a question of a few
> days).

That's certainly quick.

> Finally I hope to find one or two experienced enthusiasts, inspired and
> motivated to take part in a
> "fpc for MVS 3.8j port" project  team, I would like to create. Willing to
> learn is the best motivation.
> And a good teacher is welcome as well. It IS an ambitious goal.

Note that as part of the PDOS/386 project I have a "pascal"
target which provides a small runtime for fpc so that
executables you produce do not have copyrighted code in them.

> BTW I have started to look for Paul Robinson. I have written a mail to Kent
> Tessman ( kent@... ),
> the creator of the Hugo (
> http://web.archive.org/web/20110611063518/http://wurb.com/if/devsys/4 )
> programming language. It is well possible that he knows Mr Robinson, as I
> found his
> compay's name mentioned together with Hugo. I sent a hidden copy to the owner
> of this group, in the hope
> that it is you :-)

Yes, that came through, and I already replied.

> Actually I am studying the source code of Stanford Pascal, made available to
> MVS 3.8j by Bernd Oppolzer.

Ok.

BFN. Paul.






Paul Edwards
 

On Sat, Oct 23, 2021 at 09:29 PM, Joe Monk wrote:

So, I am confused. Every PrincOps manual I can find says that a negative
index in a register is irrelevant because the sign bit is ignored. So, how
is this affecting you?
The z/Arch quote talks of AM31. I'm running AM64.

BFN. Paul.


Joe Monk
 

"The z/Arch quote talks of AM31. I'm running AM64."

z/arch PrincOps says: "Unsigned binary arithmetic is used in address arithmetic for adding the X, B, and D fields."

Joe


On Sat, Oct 23, 2021 at 5:33 AM Paul Edwards <mutazilah@...> wrote:
On Sat, Oct 23, 2021 at 09:29 PM, Joe Monk wrote:

> So, I am confused. Every PrincOps manual I can find says that a negative
> index in a register is irrelevant because the sign bit is ignored. So, how
> is this affecting you?

The z/Arch quote talks of AM31. I'm running AM64.

BFN. Paul.






Paul Edwards
 

On Sun, Oct 24, 2021 at 04:36 AM, Joe Monk wrote:

"The z/Arch quote talks of AM31. I'm running AM64."

z/arch PrincOps says: "Unsigned binary arithmetic is used in address
arithmetic for adding the X, B, and D fields."
Right, so the negative index, typically -1, adds a whopping
4 GiB to my address, putting it into the 4 GiB - 8 GiB range
where there is no memory present, and thus it crashes.

BFN. Paul.


Joe Monk
 

"Right, so the negative index, typically -1, adds a whopping
4 GiB to my address, putting it into the 4 GiB - 8 GiB range
where there is no memory present, and thus it crashes."

Why isnt there memory there? DAT takes care of this mapping.

Joe

On Sat, Oct 23, 2021 at 12:41 PM Paul Edwards <mutazilah@...> wrote:
On Sun, Oct 24, 2021 at 04:36 AM, Joe Monk wrote:

> "The z/Arch quote talks of AM31. I'm running AM64."
>
> z/arch PrincOps says: "Unsigned binary arithmetic is used in address
> arithmetic for adding the X, B, and D fields."

Right, so the negative index, typically -1, adds a whopping
4 GiB to my address, putting it into the 4 GiB - 8 GiB range
where there is no memory present, and thus it crashes.

BFN. Paul.






Paul Edwards
 

On Sun, Oct 24, 2021 at 04:47 AM, Joe Monk wrote:

Right, so the negative index, typically -1, adds a whopping
4 GiB to my address, putting it into the 4 GiB - 8 GiB range
where there is no memory present, and thus it crashes.
Why isnt there memory there? DAT takes care of this mapping.
That's a really good idea. That will indeed solve my immediate
problem. But in the long term I don't want to map the 4 GiB
to 8 GiB region onto the 0 - 4 GiB region as that is a kludge.
I want the compiler to generate the code I want. And I want to
run with DAT off (as now), and be able to load 64-bit programs
into the 4 GiB to 8 GiB virtual region instead of having a hole.

But yes, I'll pencil this in as something to do in the short term,
to replace my other solution of using AM31 in z/Arch.

BFN. Paul.