@kolla

Quote:

I have built python 3.12 on 68k already, and it works great - but it is NOT AmigaOS

Interesting. Which OS(es) was this for and was it a straight config and compile or was it more involved?

_________________
Doing stupid things for fun...

@Karlos

Linux, straight forward build, just like just about anything else.

[kolla@chetter] :> uname -a
Linux chetter.kolla.no 6.10.6-gentoo #1 Tue Aug 20 02:29:34 CEST 2024 m68k 68040 68040 GNU/Linux
[kolla@chetter] :> cat /proc/cpuinfo
CPU:		68040
MMU:		68040
FPU:		68040
Clocking:	1098.5MHz
BogoMips:	732.36
Calibration:	3661824 loops
[kolla@chetter] :> python
Python 3.12.5 (main, Aug 15 2024, 06:00:30) [GCC 13.3.1 20240614] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

Do you know why you have built your Python 3.12? Because someone has already ported it to your platform. So, it's quite easy to checkout the repo and build it. Done!

Heard of POSIX? Portable Operating System Interface - someone didn't have to port it to my platform, they just followed good practice and followed POSIX and then portability happens on its own. Having the toolchain (gcc, llvm/clang) and kernel (linux, bsd) brought to a new architecture does take "real" developers, but once that's done, the rest is typically rather smooth sailing and just require people with patience.

Quote:

Porting Python 3.12 to Amiga OS, AROS, whatever OS, requires someone which has already experience on porting software to the selected platform, or... a lot of time to spend tinkering and trying it. So, again: not in my scope.

So you're saying OS _DOES_ matter.

You know what old Python2 ports to Amiga rely on?
IXemul.library - why is that do you think?

Last edited by kolla on 21-Aug-2024 at 05:25 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @Karlos Linux, straight forward build, just like just about anything else. [kolla@chetter] :> uname -a Linux chetter.kolla.no 6.10.6-gentoo #1 Tue Aug 20 02:29:34 CEST 2024 m68k 68040 68040 GNU/Linux [kolla@chetter] :> cat /proc/cpuinfo CPU: 68040 MMU: 68040 FPU: 68040 Clocking: 1098.5MHz BogoMips: 732.36 Calibration: 3661824 loops [kolla@chetter] :> python Python 3.12.5 (main, Aug 15 2024, 06:00:30) [GCC 13.3.1 20240614] on linux Type "help", "copyright", "credits" or "license" for more information. >>> (Same would go for NetBSD though)

I assume either the reported clock is wrong or that's under emulation...

_________________
Doing stupid things for fun...

@kolla

Quote:

kolla wrote: @cdimauro Quote: Do you know why you have built your Python 3.12? Because someone has already ported it to your platform. So, it's quite easy to checkout the repo and build it. Done! Heard of POSIX? Portable Operating System Interface - someone didn't have to port it to my platform, they just followed good practice and followed POSIX and then portability happens on its own. Having the toolchain (gcc, llvm/clang) and kernel (linux, bsd) brought to a new architecture does take "real" developers, but once that's done, the rest is typically rather smooth sailing and just require people with patience.

I think that you never got an OS course at the university, right?

POSIX is an industry standard FOR THE UNIX WORLD, and only for that! NOT for ALL OSes! And only for a LIMITED set of APIs.

BTW, Linux is NOT (fully) POSIX-compliant.

Last but not really least, your Unix flavour also needs to be supported, otherwise you might have problems building the given application
So, someone has to make sure the it can be build on Unix flavour X running on architecture Y and using the compiler Z.
Quote:

Quote: Porting Python 3.12 to Amiga OS, AROS, whatever OS, requires someone which has already experience on porting software to the selected platform, or... a lot of time to spend tinkering and trying it. So, again: not in my scope. So you're saying OS _DOES_ matter.

Yes, absolutely... and... "obviously". Otherwise there would no "porting" concept, right?

Have you ever heard of porting the application x from Windows to Linux? Or viceversa. Do you know why it's needed? Well, because those are DIFFERENT OSes! WoW! What a news...
Quote:

You know what old Python2 ports to Amiga rely on? IXemul.library - why is that do you think?

Guess why: for making the life easier to people to port software to the Amiga from the Unix world.

Could you explain me why a library like that is needed if the OS doesn't matter?

BTW, could you please show me how to port a Unix application which uses the fork() POSIX API?

@cdimauro

Quote:

cdimauro wrote: I think that you never got an OS course at the university, right?

I did, several, but it was early-mid 90s and the focus was on MS-DOS and Minix, I learnt more from working with all the hardware and software we had available at university, especially at the computer clubs that tended to inherit old systems from both univ and other sponsors - Ultrix, VMS, Irix, Solaris, old SunOS, AIX, HPUX, Tru64, QNX, NeXTStep, VxWorks, Plan9, OS/2, DomainOS, RiscOS, MiNT, BeOS, MacOS, and of course Linux and the BSDs...

Quote:

POSIX is an industry standard FOR THE UNIX WORLD, and only for that! NOT for ALL OSes! And only for a LIMITED set of APIs.

That's not right. POSIX is for any OS, it is based around Unix, but it is not a requirement. In fact most certified UNIX systems over the years have not been 100% POSIX compliant (and there was a time when WinNT was POSIX compliant, and the _most_ compliant was DEC VMS) - so POSIX or not is a _choice_ when developing an OS.

Quote:

BTW, Linux is NOT (fully) POSIX-compliant.

Of course not, like I said... most UNIX are not "fully" compliant (and there are several POSIX revisions to be compliant with)

Quote:

Last but not really least, your Unix flavour also needs to be supported, otherwise you might have problems building the given application So, someone has to make sure the it can be build on Unix flavour X running on architecture Y and using the compiler Z.

Naturally, I have been that "someone" quite a few times with my access to oddball systems, who have reported bugs (most often endian related) which then got fixed. What I can say is that it's a lot easier today than what it was 15-20 years ago.

Quote:

Porting Python 3.12 to Amiga OS, AROS, whatever OS, requires someone which has already experience on porting software to the selected platform, or... a lot of time to spend tinkering and trying it. So, again: not in my scope.

And not in anyone else's scope either, so...

Quote:

Yes, absolutely... and... "obviously". Otherwise there would no "porting" concept, right?[7/quote] So what you wrote... [quote]The problem isn't the Amiga OS, rather the hardware. Nowadays it's possible to run the Amiga OS with more than adeguate resources for running PHP or Python.

Is rather BS - we _DO_ have the hardware, the problem is Amiga OS.

Quote:

Have you ever heard of porting the application x from Windows to Linux? Or viceversa. Do you know why it's needed? Well, because those are DIFFERENT OSes!

Yes I have, been in projects were same code base was for macOS, iOS, Android, Linux and Windows (and big plus when also working on NetBSD and FreeBSD, which is typically would)

Quote:

Could you explain me why a library like that is needed if the OS doesn't matter?

the "OS doesn't matter" argument was yours, why are you attempting to flip the chairs?

Quote:

BTW, could you please show me how to port a Unix application which uses the fork() POSIX API?

You rewrite it to use spawn (posix and alike) or CreateProcess or whatever it's called on windows - fork() (followed by exec()) was nice back in the days, but today with multiprocessing and multi-threading, it is better avoided. On Linux you must also keep in mind that the Linux kernel has its fork(), but with glibc the system will use glibc's own fork() (and I don't recall if musl has its own). So, best solution is to rewrite and commit upstream.

Last edited by kolla on 22-Aug-2024 at 04:55 PM.
Last edited by kolla on 22-Aug-2024 at 04:53 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Quote:

I assume either the reported clock is wrong or that's under emulation...

Yes, the above is Qemu emulating a fictive 68040 system with just virtio hardware (running on my old 12" macbook, 1.2 GHz Intel Core m5). I have three real systems for Linux/68k, two A1200s (060 and 030+882) and one Quadra 910 (040), but currently lack rack space, and they need recapping as well.

Last edited by kolla on 22-Aug-2024 at 05:28 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I wonder how many POSIX calls are actually involved in supporting the Python runtime. I imagine the usual ones for signals, process management, IPC etc.

The first step is knowing the scope of what you need. How much, if any, is covered by ixemul?

_________________
Doing stupid things for fun...

@kolla

Quote:

kolla wrote: @cdimauro Quote: cdimauro wrote: POSIX is an industry standard FOR THE UNIX WORLD, and only for that! NOT for ALL OSes! And only for a LIMITED set of APIs. That's not right. POSIX is for any OS, it is based around Unix, but it is not a requirement.

No, but that's the reality: it's the common bases for Unixes, because that's exactly what they have standardized.

The claim that it's a common baseline for OSes compatibility is simply ridiculous, because they used Unix as the baseline.

And you cannot force all other OSes to have it as a baseline, for obvious reasons.
Quote:

In fact most certified UNIX systems over the years have not been 100% POSIX compliant (and there was a time when WinNT was POSIX compliant, and the _most_ compliant was DEC VMS) - so POSIX or not is a _choice_ when developing an OS.

WinNT wasn't POSIX-compliant.

Windows had/has it's proper, own, APIs which are incompatible with POSIX. And those APIs are INTERNAL: never exposed externally.

What Microsoft is doing is exposing SUBSYSTEMS which are using (part of) such internal APIs, and publicly exposing them.

Win32 is the most notable subsystem, which might directly map those internal APIs. OS/2 was another one, and of course its (public) APIs are different from the Win32 ones. And finally there was the POSIX subsystem with its APIs.

As you can see, an OS can have proper, unique, APIs which have nothing to do with POSIX. Yet, can provide POSIX-compliance (through another layer).
Quote:

Quote: BTW, Linux is NOT (fully) POSIX-compliant. Of course not, like I said... most UNIX are not "fully" compliant (and there are several POSIX revisions to be compliant with)

And let's leave it to the Unix world: other OSes have the right to have completely different APIs.
Quote:

Quote: Porting Python 3.12 to Amiga OS, AROS, whatever OS, requires someone which has already experience on porting software to the selected platform, or... a lot of time to spend tinkering and trying it. So, again: not in my scope. And not in anyone else's scope either, so...

Not yet, at least. As I've said, mazze was tinkering with bounty some years ago: maybe he'll restart it and release a first, basic version.
Quote:

Quote: Yes, absolutely... and... "obviously". Otherwise there would no "porting" concept, right? So what you wrote... The problem isn't the Amiga OS, rather the hardware. Nowadays it's possible to run the Amiga OS with more than adeguate resources for running PHP or Python. Is rather BS - we _DO_ have the hardware, the problem is Amiga OS.

No, it's that YOU have completely missed the context of the discussion, albeit it was already reported in my sentence, which I've highlighted it now.

The availability of a PHP or Python port was implied in this context.
Quote:

Quote: Could you explain me why a library like that is needed if the OS doesn't matter? the "OS doesn't matter" argument was yours, why are you attempting to flip the chairs?

See above: next time it's better that you understand the context.
Quote:

Quote: BTW, could you please show me how to port a Unix application which uses the fork() POSIX API? You rewrite it to use spawn (posix and alike) or CreateProcess or whatever it's called on windows - fork() (followed by exec()) was nice back in the days, but today with multiprocessing and multi-threading, it is better avoided. On Linux you must also keep in mind that the Linux kernel has its fork(), but with glibc the system will use glibc's own fork() (and I don't recall if musl has its own). So, best solution is to rewrite and commit upstream.

You can't have a full replacement for fork(), and you should know it.

As I've said before, POSIX is a common baseline, but only for Unix systems.

Other OSes can be quite different and implementing APIs like the fork() monster can be a nightmare or even impossibile (e.g.: the Amiga OS).

That's the reason why I've used it as an example to show how porting software is it NOT a matter of recompiling something, but requires deep knowledge of both original and new systems to identify such cases and try to provide solutions / workarounds.

@Karlos

Quote:

Karlos wrote: @kolla I wonder how many POSIX calls are actually involved in supporting the Python runtime. I imagine the usual ones for signals, process management, IPC etc.

Python (CPython, to be more precise, which is the mainstream implementation) doesn't use POSIX as a baseline (fortunately).

There are a set of includes & other files that expose interfaces for all supported OSes.
Quote:

The first step is knowing the scope of what you need. How much, if any, is covered by ixemul?

AFAIR ixemul wasn't used on the existing Python ports for the post-Amiga OSes.

As I've written in the bounty ( https://power2people.org/projects/python/ ), there are some old ports which could be taken as a starting point for the port.
I've inspected all of them at the time, and IMO the best one is the MorphOS port (the last one). Unfortunately, the link isn't working anymore...