Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 11:12:38 PM UTC+10, Paul Edwards wrote: > https://github.com/s390guy/SATK/commits/master/README > > and I can see that on 2014-08-13 he cited 3.3 as an > explicit requirement. Note that the work I was doing to make a C90-compliant version of Python 3.3 hasn't progressed since late June 2021. You can see my work to date in python*.zip in custom.zip at http://pdos.org C:\devel\python\Modules>pdmake -f makefile.w32 BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 8:12:52 PM UTC+10, jak wrote: > I looked at the "asma" folder and noticed that some files were touched 6 > years ago. I could deduce from this that the authors might have an older > version, perhaps developed for an older version of python, probably for > the 2.x versions. You could try contacting the authors to ask about > this. Python 2.x porting would probably be easier. I looked at the "README" history (where Python 3.3 is given as a requirement, down the bottom): https://github.com/s390guy/SATK/commits/master/README and I can see that on 2014-08-13 he cited 3.3 as an explicit requirement. BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 2:37:23 PM UTC+10, Dan Stromberg wrote: > > I want to produce EBCDIC executables that run on a > > S/3X0 (or z/Arch) machine (even if I personally do > > that via emulation). > > > I thought EBCDIC was analogous to ASCII? EBCDIC is an alternative to ASCII. E.g. the character '0' is at position x'F0' in EBCDIC compared to x'30' in ASCII. Note that in EBCDIC, the letters 'A' to 'Z' are not contiguous either, and the C90 standard has been carefully worded and designed so that you can rely on digits being contiguous, but not letters. > Is it also analogous to a.out, ELF and COFF? MVS 3.8J doesn't use any of those formats. The executable format is just called "MVS load module". And the object format is just called "object code". I'm not aware of any special names for them. PDOS/3X0 currently only runs MVS load modules, but I have plans for a PDOS-generic which will run under PDOS/3X0, and will use FAT instead of the MVS file system (basically just a VTOC, equivalent of a root directory, no subdirectories). So the VTOC would have one important flat file which PDOS-generic will access to provide a FAT facility to any applications running under PDOS-generic. Those applications will need to be specific to PDOS-generic and they may well be a.out/ELF/COFF - I haven't reached that point yet. I'm still preparing the assembler, I can't do what I want without that. :-) BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 7:52:07 AM UTC+10, jak wrote: > one thing is not clear to me, do you absolutely need to use "asma"? > > http://www.z390.org/ I forgot to mention that it also requires Java. So instead of porting Python to the S/3X0 I would need to port Java. Note that Java (and Python for that matter) are available for later versions of z/OS, but as far as I am aware, they are not available for the free MVS that hobbyists use, ie MVS 3.8J, and it's definitely not available for the environment I'm actually interested in, which is PDOS/3X0. BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 7:52:07 AM UTC+10, jak wrote: > Hi, > one thing is not clear to me, do you absolutely need to use "asma"? > > http://www.z390.org/ The link you provided is to something that runs on PC environments. I want to produce EBCDIC executables that run on a S/3X0 (or z/Arch) machine (even if I personally do that via emulation). The only way I currently have of doing that is to assemble and link using what comes with MVS 3.8J. But that's all written in S/370 assembler using features that only exist on MVS. PDOS/3X0 doesn't support all those features. It only supports C90-compliant applications. Meanwhile, 35,000 lines (or more) of lovingly handcrafted Python code are going to waste. :-) BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 6:18:29 AM UTC+10, Dan Stromberg wrote: > If asma runs there, it'd suggest you might do well to port micropython to > PDOS instead. > > Micropython has the dual benefits of being small and being supported. > CPython 3.3 doesn't even get security fixes anymore. Ok, thanks. I'll consider doing that as well. BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 5:13:31 AM UTC+10, Paul Rubin wrote: > Paul Edwards writes: > > I have succeeded in producing a Python 3.3 executable despite being > > built with a C library that only supports C90. > It seems to me that you might have an easier time porting MicroPython > than CPython, if MicroPython fills your requirements. The documentation for "asma" says it requires Python 3.3 or above, and I have no idea how accurate that claim is. I'll only know whether *my* flavor of Python 3.3 is good enough for "asma" when I reach that point. BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Wednesday, April 14, 2021 at 8:35:59 PM UTC+10, Paul Edwards wrote:
> ImportError: importlib requires posix or nt
> but I don't know what it needs to satisfy that.
>
> It's a bit strange that it can only be posix or nt when VMS is supported in
> 3.3 too.
The resolution to this problem was to include:
{"posix", PyInit_posix},
in config.c
and compile posixmodule.c.
I'm now on to the next problem.
BFN. Paul.
--
https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Thursday, April 15, 2021 at 4:32:51 AM UTC+10, Alan Gauld wrote: > On 14/04/2021 11:35, Paul Edwards wrote: > > I have succeeded in producing a Python 3.3 executable > ... > > However, the executable doesn't work yet. > Late to this party but how big is the assembler? Assuming the stuff in "asma" has no dependency on the other .py files, it is 35,000 lines of code! I think I might need a linker from them too. I haven't seen the output of asma yet. > It might be easier to translate the Python to C! I would also have a maintenance problem going that way. I think other people would like Python to be available on MVS/380 too, for other projects. BTW, my Python is a 1.5 MB executable. That is without optimization and without symbols. BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
I have succeeded in producing a Python 3.3 executable
despite being built with a C library that only supports
C90. I had to provide my own mini-posix wrappers that
convert open() into fopen() etc.
With that in place, plus a compiler where char = wchar_t,
there were not a lot of changes required to the Python
mainline (see below).
However, the executable doesn't work yet. Here's the
current state:
C:\devel\python\Modules>python
Traceback (most recent call last):
File "", line 1755, in _install
File "", line 1726, in _setup
ImportError: importlib requires posix or nt
Fatal Python error: Py_Initialize: importlib install failed
Current thread 0x:
That error message comes from here:
C:\devel\python\Python>head importlib.h
which is not human readable.
It is generated by this code:
C:\devel\python\Lib\importlib>grep "posix or nt" _bootstrap.py
but I don't know what it needs to satisfy that.
It's a bit strange that it can only be posix or nt when VMS is supported in 3.3
too.
BFN. Paul.
Index: Modules/main.c
===
RCS file: c:\cvsroot/python/Modules/main.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -r1.1.1.1 -r1.2
728a729
> #ifndef PUREISO
738a740
> #endif
Index: Modules/signalmodule.c
===
RCS file: c:\cvsroot/python/Modules/signalmodule.c,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -r1.1.1.1 -r1.3
418a419
> #ifndef PUREISO
419a421
> #endif
429a432
> #ifndef PUREISO
433a437
> #endif
Index: Objects/longobject.c
===
RCS file: c:\cvsroot/python/Objects/longobject.c,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -r1.1.1.1 -r1.3
939,944d938
< #ifndef HAVE_LONG_LONG
< # error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long"
< #endif
< #if SIZEOF_LONG_LONG < SIZEOF_VOID_P
< # error "PyLong_FromVoidPtr: sizeof(PY_LONG_LONG) < sizeof(void*)"
< #endif
948c942,944
< return PyLong_FromUnsignedLongLong((unsigned
PY_LONG_LONG)(Py_uintptr_t)p);
---
> #if SIZEOF_VOID_P <= SIZEOF_LONG
> return PyLong_FromUnsignedLong((unsigned long)(Py_uintptr_t)p);
> #else
949a946,950
> #if SIZEOF_LONG_LONG < SIZEOF_VOID_P
> # error "PyLong_FromVoidPtr: sizeof(long long) < sizeof(void*)"
> #endif
> return PyLong_FromUnsignedLongLong((unsigned
> PY_LONG_LONG)(Py_uintptr_t)p);
> #endif /* SIZEOF_VOID_P <= SIZEOF_LONG */
986c987
< #ifdef HAVE_LONG_LONG
---
> #if 1 /*def HAVE_LONG_LONG */
996a998
> #ifdef HAVE_LONG_LONG
1037a1040
> #endif
1040a1044
> #ifdef HAVE_LONG_LONG
1066a1071
> #endif
1139a1145
> #ifdef HAVE_LONG_LONG
1187a1194
> #endif
1191a1199
> #ifdef HAVE_LONG_LONG
1223a1232
> #endif
1227a1237
> #ifdef HAVE_LONG_LONG
1256a1267
> #endif
1257a1269
> #ifdef HAVE_LONG_LONG
1291a1304
> #endif
1303a1317
> #ifdef HAVE_LONG_LONG
1389a1404
> #endif
Index: Objects/unicodeobject.c
===
RCS file: c:\cvsroot/python/Objects/unicodeobject.c,v
retrieving revision 1.1.1.1
retrieving revision 1.3
diff -r1.1.1.1 -r1.3
2243c2243
< #ifdef HAVE_WCHAR_H
---
> #if defined(HAVE_WCHAR_H) || defined(PUREISO)
2865c2865
< #ifdef HAVE_WCHAR_H
---
> #if defined(HAVE_WCHAR_H) || defined(PUREISO)
9148c9148
< // TODO: honor direction and do a forward or backwards search
---
> /*TODO: honor direction and do a forward or backwards search */
Index: Parser/tokenizer.c
===
RCS file: c:\cvsroot/python/Parser/tokenizer.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -r1.1.1.1 -r1.2
1720a1721,1723
> #ifdef PUREISO
> return (NULL);
> #else
1758a1762
> #endif /* PUREISO */
Index: Python/fileutils.c
===
RCS file: c:\cvsroot/python/Python/fileutils.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -r1.1.1.1 -r1.2
40c40
< #ifdef HAVE_STAT
---
> #if 1 /* def HAVE_STAT */
279a280
> #ifdef HAVE_STAT
304a306
> #endif
Index: Python/getopt.c
===
RCS file: c:\cvsroot/python/Python/getopt.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -r1.1.1.1 -r1.2
33c33,35
< #include
---
> #ifdef HAVE_WCHAR_H
> #include
> #endif
Index: Python/pythonrun.c
===
RCS file: c:\cvsroot/python/Python/pythonrun.c,v
retrieving revision 1.1.1.1
retrieving revision 1.5
diff -r1.1.1.1 -r1.5
300a301,304
> /* Init Unicode implementation; relies on the codec registry */
> if (_PyUnicode_Init() < 0)
> Py_FatalError("Py_Initialize: can't initialize unicode");
>
318,321d321
< /* Init Unicode implementation; relies on the codec registry */
< if (_PyUnicode_Init() < 0)
< Py_FatalError("Py_Initialize: can't
Re: port to PDOS (especially mainframe)
On Wednesday, March 24, 2021 at 11:07:48 PM UTC+11, Christian Heimes wrote: > > "long long" is not C90. I don't have support for that. The > > "i370" target of GCC 3.2.3 doesn't have DI instructions > > working. Just 32 bits. Everything is 32 bits. > Which version of Python are you using as baseline? 3.3, which is the minimum required, according to this: https://github.com/s390guy/SATK asma- A Small Mainframe Assembler (ASMA) for stand-alone programs. ASMA runs wherever Python 3.3 runs! > CPython requires C99 since 3.6, Exactly why I go back to the oldest version I can! BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Wednesday, March 24, 2021 at 1:02:48 AM UTC+11, Chris Angelico wrote: > > ../Objects/exceptions.c:2538: `ECONNREFUSED' undeclared (first use in this > > function) > > > Ah, this sounds like an issue with your lower-level networking > support. Does PDOS have BSD sockets? Does it have WinSock? Something > else? Nothing at all? (sorry for the delay in replying) Nothing at all. Just what you can find in ISO/IEC 9899:1990. BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Tuesday, March 23, 2021 at 10:19:46 PM UTC+11, Paul Edwards wrote:
> Objects/exceptions.c: ADD_ERRNO(ConnectionRefusedError, ECONNREFUSED);
>
> Those errno are non-standard (non-C90) and I assume
> other platforms can't cope with that either. But I can't
> see how other platforms are circumventing that problem.
> (ie I did a grep -R of the whole source code).
>
> I could define a stack of constants in pyconfig.h to allow
> the compile to go through, but I don't see anyone else
> doing the same thing.
I defined a stack of E* in pyconfig.h and here is my
latest problem:
../Objects/longobject.c:940:5: #error "PyLong_FromVoidPtr: sizeof(void*) >
sizeof(long), but no long long"
/* Create a new long int object from a C pointer */
PyObject *
PyLong_FromVoidPtr(void *p)
{
#ifndef HAVE_LONG_LONG
# error "PyLong_FromVoidPtr: sizeof(void*) > sizeof(long), but no long long"
#endif
That to me sounds like having "long long" is compulsory,
but the error it is showing is not correct. My "void *" is
he same as "long", ie 32 bits. Everything I do is 32 bits
unless I'm doing the occasional MSDOS build which is
16 bits.
What's the point of having a variable HAVE_LONG_LONG
if it's compulsory?
"long long" is not C90. I don't have support for that. The
"i370" target of GCC 3.2.3 doesn't have DI instructions
working. Just 32 bits. Everything is 32 bits.
Any suggestions?
Thanks. Paul.
--
https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Tuesday, March 23, 2021 at 10:19:46 PM UTC+11, Paul Edwards wrote: > My latest problem is this: > > Objects/exceptions.c: ADD_ERRNO(ConnectionRefusedError, ECONNREFUSED); Sorry, I forgot to include the actual error: ../Objects/exceptions.c:2538: `ECONNREFUSED' undeclared (first use in this function) BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Tuesday, March 23, 2021 at 9:44:03 PM UTC+11, Gisle Vanem wrote: > Why not try to port MicroPython instead? Much lighter. > I've ported it to MSDOS/djgpp with some success. Thanks for the tip. I don't actually need it to be light. I just need it to be C90-compliant. The assembler I mentioned is designed to take the output of a customized GCC 3.2.3, which is a 3 MB executable and requires about 20 MB to recompile itself. So lots of memory needs to be thrown at it anyway. > > python.a(abstract.o)(.text+0x668c):abstract.c: undefined reference to > > `PyExc_StopIteration' > It's in 'Objects/exceptions.c'. When in doubt, look at the Thanks! > 'python*.map' files. I assume you have managed to build > Python 3 on Windows (?). There are no map files in the Python 3.3 distribution, and no, I haven't built it on Windows. I've never run python before. I tried typing in "python" to see if it came with Cygwin, but I got some stupid Windows store thing come up. > And BTW, it's also forwarded from 'python3.dll' via some > hacks in 'python3dll.c' to the real Python in 'Python310.dll' > (in my case): > pedump python3.dll | grep PyExc_StopIteration > 853A 227 PyExc_StopIteration (forwarder -> > python310.dll.PyExc_StopIteration) > > plus a lot more; it's quite ugly. Ok, I'm assuming that I can run without DLLs being involved. There are presumably other targets with no concept of DLLs. My latest problem is this: Objects/exceptions.c:ADD_ERRNO(ConnectionRefusedError, ECONNREFUSED); Those errno are non-standard (non-C90) and I assume other platforms can't cope with that either. But I can't see how other platforms are circumventing that problem. (ie I did a grep -R of the whole source code). I could define a stack of constants in pyconfig.h to allow the compile to go through, but I don't see anyone else doing the same thing. Is there some other way of circumventing the problem? Thanks. Paul. -- https://mail.python.org/mailman/listinfo/python-list
port to PDOS (especially mainframe)
Hello. I have a new operating system called PDOS which works on both PC and mainframe, which can be found here: http://pdos.sourceforge.net/ I know nothing about Python, my focus is on C90, but I wish to run this mainframe assembler, asma, which was written in Python, not C: https://github.com/s390guy/SATK It needs Python 3.3 as a minimum, so I wish to port that version, first to the PC version of PDOS, then to the mainframe version. I don't wish to run configure, I want to hand-construct the makefile. PDOS is a very simple system, so I only want to produce a single executable, no DLLs etc. I don't need extensions to work or anything, all I need to be able to do is run asma. I've started constructing a makefile (see below), which I execute with pdmake, included in PDOS. I only have a C90 runtime library, no more, no less, so I don't know whether Python will actually build in my environment, but so far things have been building successfully. However I'm currently stuck on this unresolved external: python.a(abstract.o)(.text+0x668c):abstract.c: undefined reference to `PyExc_StopIteration' What source file is meant to define that variable (PyExc_StopIteration) as opposed to just declaring it or using it? I tried looking at the OS/2 EMX for hints, but wasn't able to figure it out. Note that I am building a Win32 executable to start with, but it is linking against my own C90 library which will call either Microsoft's MSVCRT.DLL on Windows, or my own MSVCRT.DLL when running on PDOS/386 (aka PD-Windows). I also don't know whether Python will survive being transferred to an EBCDIC environment, as that is where it will ultimately need to be compiled and linked (MVS/380), or at least assembled, before it can wind up on PDOS/3X0. Well, maybe it can all be done on Windows. I need to see what asma is capable of. Thanks. Paul. # Produce Windows executables # links with PDPCLIB created by makefile.msv CC=gccwin CFLAGS=-O0 LD=ldwin LDFLAGS= AS=aswin AR=arwin STRIP=stripwin COPTS=-S $(CFLAGS) -fno-common -ansi -I. -I../Include -I../../pdos/pdpclib -D__WIN32__ all: clean python.exe python.exe: python.o ../Python/strdup.o ../Objects/object.o ../Objects/abstract.o \ ../Python/errors.o ../Objects/bytesobject.o rm -f python.a ar r python.a ../Python/strdup.o ../Objects/object.o ../Objects/abstract.o ar r python.a ../Python/errors.o ../Objects/bytesobject.o $(LD) $(LDFLAGS) -o python.exe ../../pdos/pdpclib/w32start.o python.o python.a ../../pdos/pdpclib/msvcrt.a ../../pdos/src/kernel32.a $(STRIP) python.exe .c.o: $(CC) $(COPTS) -o $*.s $< $(AS) -o $@ $*.s rm -f $*.s clean: rm -f *.o python.exe -- https://mail.python.org/mailman/listinfo/python-list
