Re: port to PDOS (especially mainframe)

[Paul Edwards]

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: convert script awk in python

[Cameron Simpson]

On 23Mar2021 16:37, Tomasz Rola  wrote:
>On Tue, Mar 23, 2021 at 10:40:01AM -0400, Avi Gross via Python-list wrote:
>[...]
>> I am a tod concerned as to where any of the variables x, y or z have been
>> defined at this point. I have not seen a BEGIN {...} pattern/action or
>> anywhere these have been initialized but they are set in a function that as
>> far as I know has not been called. Weird. Maybe awk is allowing an
>> uninitialized variable to be tested for in your code but if so, you need to
>> be cautious how you do this in python.
>
>As far as I can say, the type of uninitialised variable is groked from
>the first operation on it. I.e., "count += 1" first initializes count
>to 0 and then adds 1.
>
>This might depend on exact awk being used. There were few of them
>during last 30+ years. I just assume it does as I wrote above.

I'm pretty sure this behaviour's been there since very early times. I 
think it was there when I learnt awk, decades ago.

>Using BEGIN would be in better style, of course.

Aye. Always good to be up front about initial values.

>There is a very nice book, "The AWK Programming Language" by Aho,
>Kernighan and Weinberger. First printed in 1988, now free and in pdf
>format. Go search.

Yes, a really nice book. [... walks into the other room to get his copy 
...] October 1988.

Wow. There're 11 pages of good example programmes before any need for 
user variables at all. But at "1.5, Counting" is the sentence:

Awk variables used as numbers begin life with the value 0, so we 
don't need to initialise emp.

Which is great for writing ad hoc scripts, particularly on the command 
line. But not a great style for anything complex.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Re: Looking for people interested in a Python register virtual machine project

[Guido van Rossum]

On Tue, Mar 23, 2021 at 12:40 PM Skip Montanaro 
wrote:

> I've not attempted to make any changes to calling conventions. It
> occurred to me that the LOAD_METHOD/CALL_METHOD pair could perhaps be
> merged into a single opcode, but I haven't really thought about that.
> Perhaps there's a good reason the method is looked up before the
> arguments are pushed onto the stack (call_function()?). In a
> register-based VM there's no need to do things in that order.
>

IIRC the reason is that Python's language reference promises left-to-right
evaluation here. So o.m(f()) needs to evaluate o.m (which may have a side
effect if o overrides __getattr__) before it calls f().

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: port to PDOS (especially mainframe)

[Paul Edwards]

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: [Python-ideas] Looking for people interested in a Python register virtual machine project

[Skip Montanaro]

> a) You're working with CPython bleeding edge.
> b) You find that (bleeding edge) adding extra chore.
> c) Nobody told you to work on bleeding (nor boss, nor a maintainer who
> said "I'll merge it once you've done"),
>
> Then: why do you complicate your task by working on bleeding edge?
> Could take not too old CPython version, e.g. 3.8/3.9, instead, and work
> with that.

I started this in the 3.9 alpha timeframe. Staying up-to-date wasn't
too difficult. It never occurred to me that the virtual machine would
undergo so much churn for 3.10, so I just stuck with main/master and
paid the price when the changes started to arrive in earnest. When the
3.10 branch is created I will take that off-ramp this time.

> Btw, from just "pep", it's unclear if, and how much, you reuse Victor's
> work. If not, why? (The answer is useful to contributors - you ask them
> to "reuse" your code - how it's regarding your reuse of code of folks
> who were before you?).

Both Victor's and my earlier work took place in the dim dark past.
There have been so many functional changes to the virtual machine that
directly reusing either old code base wasn't feasible. I do have a
copy of Victor's work though which I have referred to from
time-to-time. I just never tried to merge it with something recent,
like 3.9.

> > > explicitly. Would be interesting to read (in the following "pep"
> > > sections) what makes them "almost completely distinct".
> >
> > Well, sure. The main difference is the way two pairs of instructions
> > (say, BINARY_ADD vs BINARY_ADD_REG) get their operands and save their
> > result. You still have to be able to add two objects, call functions,
> > etc.
>
> I'd note that your reply skips answering question about calling
> convention for register-based VM, and that's again one of the most
> important questions (and one I'd be genuinely interested to hear).

I've not attempted to make any changes to calling conventions. It
occurred to me that the LOAD_METHOD/CALL_METHOD pair could perhaps be
merged into a single opcode, but I haven't really thought about that.
Perhaps there's a good reason the method is looked up before the
arguments are pushed onto the stack (call_function()?). In a
register-based VM there's no need to do things in that order.

> > The fact that I treat the current frame's stack space as registers
> > makes it pretty much impossible to execute both stack and register
> > instructions within the same frame.
>
> I don't see how that would be true (in general, I understand that you
> may have constraints re: that, but that's exactly why I bring that up -
> why do you have constraints like that?). Even existing Python VM allows
> to use both in the same frame, e.g. LOAD_FAST. It takes value of
> register and puts it on a stack.

Sure, but that's because it must. All operands must be on the stack.
My code does have a step where it tries to remove LOAD_FAST_REG and
STORE_FAST_REG opcodes. It's not very good though. Pesky implicit
references cause problems. Still, I am able to remove some of them.
This should get better over time. And, it is possible that at some
point I decide to add back in some stack space for stuff like calling
functions, constructing lists, etc.

> Do you mean details like need to translate stack-based instructions
> into 2 (or more) instructions of: a) actual register-register
> instruction and; b) stack pointer adjustment, so stack-based
> instructions still kept working?

Yes, but I see (I think) what you're getting at. If I continued to
maintain the stack pointer, in theory stack opcodes could exist along
with register opcodes.

> Yes, you would need to do that, until you fully switch to
> register-based ones. But then there's 2 separate tasks:
>
> 1. Make register VM work. (Should be medium complexity.)
> 2. Make it fast. (Likely will be hard.)

I'm not too worried about #2 yet. :-) And as demonstrated by the
current project's incompleteness, either I'm not up to medium
complexity tasks anymore or it's harder than you think. :-)

Some of the second step isn't too hard, I don't think. I already
mentioned eliding generated fast LOAD/STORE instructions, and in my
previous email mentioned copying constants from the code object to the
frame object on creation. I also think opcode prediction and fast
dispatch should be straightforward. I just haven't bothered with that
yet.

> If you want to achieve both right from the start - oh-oh, that may be
> double-hard.
>
> > Victor's implementation did things
> > differently in this regard. I believe he just allocated extra space
> > for 256 registers at the end of each frame, so (in theory, I suppose),
> > you could have instructions from both executed in the same frame.
>
> I hope you have a plan of how to deal with more than 256 registers,
> etc. Register VM adds a lot of accidental implementation complexity ;-).

One of the reasons I just reused the current stack space as my
register space harkens back to a thread with Tim Peters back in th

Re: convert script awk in python

[Tomasz Rola]

On Tue, Mar 23, 2021 at 10:40:01AM -0400, Avi Gross via Python-list wrote:
> Alberto,
> 
[...]
> I am a tod concerned as to where any of the variables x, y or z have been
> defined at this point. I have not seen a BEGIN {...} pattern/action or
> anywhere these have been initialized but they are set in a function that as
> far as I know has not been called. Weird. Maybe awk is allowing an
> uninitialized variable to be tested for in your code but if so, you need to
> be cautious how you do this in python.

As far as I can say, the type of uninitialised variable is groked from
the first operation on it. I.e., "count += 1" first initializes count
to 0 and then adds 1.

This might depend on exact awk being used. There were few of them
during last 30+ years. I just assume it does as I wrote above.

Using BEGIN would be in better style, of course.

There is a very nice book, "The AWK Programming Language" by Aho,
Kernighan and Weinberger. First printed in 1988, now free and in pdf
format. Go search. Perhaps it is easier to make the script work rather
than rewriting it in another language. Both ways require deep
understanding of current code, then with rewrite one also has to make
sure new code is drop in replacement for the old.

There is very nice documentation to gawk (Gnu AWK).

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: port to PDOS (especially mainframe)

[Stestagg]

On Tue, Mar 23, 2021 at 3:20 PM Michael Torrie  wrote:

> On 3/23/21 5:19 AM, Paul Edwards wrote:
> > Thanks for the tip. I don't actually need it to be
> > light. I just need it to be C90-compliant.
>
> I guess the point with MicroPython is that since it can build on all
> sorts of microcontrollers, a) it has a simpler build system and b) it is
> definitely statically compiled. But I'm not sure whether it would be
> applicable here.
>
>
For example, micropython can be compiled with a standlone TCP/IP
implementation: LWIP.

lwip contains the relevant constants, along with the code needed to make
them do stuff:

https://github.com/lwip-tcpip/lwip/blob/0056522cc974d2be2005c324f37187b5b3695765/src/include/lwip/errno.h#L160

So if you're compiling for a non-posix compliant environment, this may be
an easier route to go

Steve
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: port to PDOS (especially mainframe)

[Michael Torrie]

On 3/23/21 5:19 AM, Paul Edwards wrote:
> Thanks for the tip. I don't actually need it to be
> light. I just need it to be C90-compliant.

I guess the point with MicroPython is that since it can build on all
sorts of microcontrollers, a) it has a simpler build system and b) it is
definitely statically compiled. But I'm not sure whether it would be
applicable here.

> I tried typing in "python" to see if it
> came with Cygwin, but I got some stupid Windows
> store thing come up.

Cygwin does have python available.  You can select the python packages
when installing or install later by running the cygwin's setup.exe.  In
Windows 10 by default if you don't have any python interpreter
installed, Windows 10 will direct to you to the windows store to install
Python when you try to run the python interpreter.  That is why you saw
something about the Windows store.  Just by way of explanation.

> Ok, I'm assuming that I can run without DLLs
> being involved. There are presumably other
> targets with no concept of DLLs.

Possibly but they would be rarely used targets and not documented well.
 There is a basic wiki page from a few years ago on the subject, but
light on details: https://wiki.python.org/moin/BuildStatically. The
mailing list conversation the page links to is over ten years old.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: convert script awk in python

[Avi Gross via Python-list]

Alberto,

To convert any algorithm to python (or anything else) you have to understand
it. Do you know what AWK is doing? And does the darn thing work already in
awk? Why do you need to convert it? My suspicion is that it has errors and
if so, it is NOT about converting at all.

I will not solve this for you except to outline what it does.

AWK is designed to read in data and organize it into fields based on rules.
It then sees patterns to match against each clump of data (usually a line)
and performs actions.

The beginning of your shown program simply defined helper functions before
the main program begins. You will need to translate them individually. I
would not have written and formatted it the way you show.

function sq(x) {
return x * x;
}

function dist(x1, y1, z1, x2, y2, z2) {
return sqrt(sq(x1 - x2) + sq(y1 - y2) + sq(z1 - z2)); }

function print_distances() {
if (na == 0)
print "No type 8 atoms.";
else {
min = 1000;
for (a = 0; a < na; a++) {
d = dist(x, y, z, pos[a,"x"], pos[a,"y"], pos[a,"z"]);
#printf "%7.5f ", d;
if (d < min) min = d;
}
printf "%6i%7.5f\n", istep, min;
x = y = z = 0;
delete pos;
na = 0;
}
}

OK, so far? You need to make changes in the above as needed or completely
redo the algorithms in python but first you must recognize what the above
are.

Now the main AWK call is hidden and looks like:

awk 'PROGRAM' $1.lammpstrj > $1_mindist.txt

The above says that AWK is called with a filename the shell script makes
using an argument to the script. The shell also sends the standard output
from awk to a second file with a name based on the same argument. So your
python program needs to open the same file but write to standard output OR
you can rewrite it any way you please to get the same result.

The rest of the program is patterns and actions. But AWK is doing all kinds
of things for you invisibly that you now need to do explicitly in python.

You need to open a file and read a line at a time in a loop. The line must
be parsed into fields the same way AWK would have done. There probably is a
simple package that can do that or you do it by hand.

Now the rest of the program is patterns like:

$1 == 113

$8 == 10

And a more complex one I defer. The above has an action it wants to do for
any line that has a first part exactly equal to 113. The second wants an 8th
part equal to 10. In python, once you have figured out what those parts are
(as well as the other parts) you need to test using something like an "if"
statement for that condition and do what action follows. Here is the
condition then action for the first clause:

$1 == 113 {
if (x || y || z)
print "More than one type $8 atom.";
else {
x = $2; y = $3; z = $4;
istep++;
}
}

I am a tod concerned as to where any of the variables x, y or z have been
defined at this point. I have not seen a BEGIN {...} pattern/action or
anywhere these have been initialized but they are set in a function that as
far as I know has not been called. Weird. Maybe awk is allowing an
uninitialized variable to be tested for in your code but if so, you need to
be cautious how you do this in python.

Be that as it may, I am explaining what I think I see. PATTERN ACTION.

So the next pattern/action is:

$8 == 10 {
pos[na,"x"] = $2; pos[na,"y"] = $3; pos[na,"z"] = $4;
na += 1;
}

And the next one is a bit more complex:

/^ITEM: ATOMS/ && na != 0 { print_distances(); }

It does pattern matching on the original line and asks for the text being
looked for to be at the beginning of the line. So you need to learn how to
ask python to match that pattern. And note the && joins two Boolean parts.

All the above patterns are checked for on every line and you need to know
what AWK does once it matches. Does the code above ask you to move to the
next line when it matches or do every applicable action?

So you have been in a loop and when you reach the end of the file, you need
to get out of the loop. Only then does the final pattern match:

END   { print_distances(); }

I hope some of that was helpful. To do the full job you need to do way more
than translate how AWK does something like use curly braces for grouping
while python uses indentations. AWK is designed to be a filter in the ways
described above and does many helpful things behind the scenes. You need to
do all that work for yourself in python.

Of course, having said all that, I know this is a common enough problem that
people have solved by making modules that do awk-like activities in python
but I have no experience there. Had you done a search for something like
this, an answer might have presented itself that involves less work for you,
unless this is homework that needs to be done by you:

https://www.google.com/search?q=python+awk+module&sxsrf=ALeKk03gD2jZYJkZ0cGv
zbKlErWzQJ5Spw%3A1616510303610&source=hp&ei=X_1ZYJPDIob

Re: port to PDOS (especially mainframe)

[Chris Angelico]

On Tue, Mar 23, 2021 at 11:21 PM Paul Edwards  wrote:
>
> 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)
>

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?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: port to PDOS (especially mainframe)

[Paul Edwards]

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

convert script awk in python

[alberto]

Hi to everyone I have an awk script that calculate minimum distances between 
points 

## atom type frag - atom type surface
#!/bin/bash

FILE1=$1.lammpstrj

if [ -f $FILE1 ];
then

awk 'function sq(x) {
return x * x;
}
function dist(x1, y1, z1, x2, y2, z2) {
return sqrt(sq(x1 - x2) + sq(y1 - y2) + sq(z1 - z2));
}
function print_distances() {
if (na == 0)
print "No type 8 atoms.";
else {
min = 1000;
for (a = 0; a < na; a++) {
d = dist(x, y, z, pos[a,"x"], pos[a,"y"], pos[a,"z"]);
#printf "%7.5f ", d;
if (d < min) min = d;
}
printf "%6i%7.5f\n", istep, min;
x = y = z = 0;
delete pos;
na = 0;
}
}
$1 == 113 {
if (x || y || z)
print "More than one type $8 atom.";
else {
x = $2; y = $3; z = $4;
istep++;
}
}
$8 == 10 {
pos[na,"x"] = $2; pos[na,"y"] = $3; pos[na,"z"] = $4;
na += 1;
}
/^ITEM: ATOMS/ && na != 0 { print_distances(); }
END   { print_distances(); }
' $1.lammpstrj > $1_mindist.txt
fi

where $1 is a particular atom and $8 is a other type of atoms

How could I prepare  a python script 

regards

A
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: port to PDOS (especially mainframe)

[Paul Edwards]

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

Re: port to PDOS (especially mainframe)

[Gisle Vanem]

Edwards wrote:


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.


Why not try to port MicroPython instead? Much lighter.
I've ported it to MSDOS/djgpp with some success.


However I'm currently stuck on this unresolved
external:

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
'python*.map' files. I assume you have managed to build
Python 3 on Windows (?).

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.

--
--gv
--
https://mail.python.org/mailman/listinfo/python-list

port to PDOS (especially mainframe)

[Paul Edwards]

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