Python on Itanium Windows 64: available or planned?

[Bernhard Mulder]

I am using Python on Itanium Windows 64 (Server 2003) with a Win32 version.

Is there a native version available or planned? Are testers needed for
this platform?

Windows 64 is a bit unusual in that "long" is not large enough to hold
an address.

[Trent Mick]

[Bernhard Mulder wrote]

> I am using Python on Itanium Windows 64 (Server 2003) with a Win32 version.
>
> Is there a native version available or planned? Are testers needed for
> this platform?

Python should compile fine for Win64. It was ported for Win64 a few
years back (around the time of Python 2.0/1.6 I think).

There are no free binary packages kicking around out there that I know
of but a number of people do compile it themselves for Win64. There was
some discussion on this list recently about how to do that seeing as
there is no DevStudio for Win64 (at least, that is my understanding).
One way was to export makefiles from Python's .dsp project files and use
the Win64 cross-compiler that is available with the platform SDK.

> Windows 64 is a bit unusual in that "long" is not large enough to hold
> an address.

Yup. Though I would use a stronger word than "unusual". :)

Trent

p.s. ActiveState will provide Win64 binary installers for Python on
contract, though I don't know if that is an option for you.

--
Trent Mick
Tre...@ActiveState.com

[Martin v. Löwis]

Trent Mick <tre...@ActiveState.com> writes:

> There are no free binary packages kicking around out there that I know
> of but a number of people do compile it themselves for Win64.

However, there are free binary packages out there that you don't know
of :-)

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python23.msi

See

http://groups.google.com/groups?selm=mailman.1060265944.15612.clpa-moderators%40python.org

for the original announcement.

> There was some discussion on this list recently about how to do that
> seeing as there is no DevStudio for Win64 (at least, that is my
> understanding).

Again, it depends: With sf.net/projects/vsextcomp, VS 7.1 is very well
capable of invoking the Itanium platform SDK compiler (AMD64 coming
soon).

> > Windows 64 is a bit unusual in that "long" is not large enough to hold
> > an address.
>
> Yup. Though I would use a stronger word than "unusual". :)

That may even be a source of bugs. I'm in the process of putting
size_t in every place Python currently uses "int" or "long" to store a
number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
cause crashes in Python 2.3 (in other cases, this is somewhat overkill
- eg. when the compiler complains that strlen(some_file_name) may not
fit into 4 bytes).

Regards,
Martin

[Mike Rovner]

Martin v. Löwis wrote:

> That may even be a source of bugs. I'm in the process of putting
> size_t in every place Python currently uses "int" or "long" to store a
> number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
> cause crashes in Python 2.3 (in other cases, this is somewhat overkill
> - eg. when the compiler complains that strlen(some_file_name) may not
> fit into 4 bytes).

Does that mean forthcoming API interface change?
There are mostly ints for sizes (ex. PyString_AsStringAndSize
(PyObject *obj, char **buffer, int *length)).

Regards,
Mike

[Martin v. Löwis]

"Mike Rovner" <mi...@nospam.com> writes:

> > That may even be a source of bugs. I'm in the process of putting
> > size_t in every place Python currently uses "int" or "long" to store a
> > number of bytes. In some cases, exceeding 4GB (sometimes 2GB) will
> > cause crashes in Python 2.3 (in other cases, this is somewhat overkill
> > - eg. when the compiler complains that strlen(some_file_name) may not
> > fit into 4 bytes).
>
> Does that mean forthcoming API interface change?

Yes. I haven't changed any structure (yet), but, after approval on
python-dev, this is likely to happen as well.

> There are mostly ints for sizes (ex. PyString_AsStringAndSize
> (PyObject *obj, char **buffer, int *length)).

Indeed. I don't think it matters, though: processors typically return
results in registers. On a 64-bit processor, a single register will
take the result, and most likely, a 32-bit return value will be
widened appropriately. So you might actually get away with not
recompiling the extensions in 2.4 (atleast until ob_size changes,
which does cause incompatibilities on big-endian machines).

Regards,
Martin