How many people here are programmers that actually need features added for custom software to be written? I am the maintainer of a fork of ECX, an Amiga E compiler that supports 68020 and PPC. Who among you are willing to help me add features to this Amiga/MorphOS compiler knowing that it will never work outside the Amiga community? Show of hands? Anyone? I thought not.

EEC could have a GCC code generator that would be portable to any supported architecture of GCC 10+ using the LibGCCJIT frontend. It could support multiple cores if the OS supported it. 64-bit tag-lists might get tricky but it might be possible if the data field was 64 bits and the code field was 32 bits. The point is that no volunteers will make it happen.

> So far our record waiting time (since 2.0) has been 615 days
> (between MorphOS 2.7 and 3.0). It's been 584 days since 3.18
> as for today, so no new record... yet.

Apart from the massive 1010 days wait for 3.10 (already addressed by connor) and the even longer wait for 2.0 (1157 days), the wait for 3.0 was not 615 days but only 554 days, so the current 584 days wait for 3.19 is already longer by now, making it #3.
Here is an ordered list of the waiting times in days just for the fun of it (feature releases in bold):

2.0: 1157
3.10: 1010
3.19: 584 and counting
3.0: 554
3.12: 453
3.16: 433
3.18: 377
3.2: 323
3.8: 285
3.14: 240
2.5: 235
2.3: 229
3.6: 132
2.6/3.13: 128
3.3: 114
3.11: 103
3.15: 88
3.4: 87
2.2: 81
2.1: 68
2.4: 67
3.5: 63
2.7/3.17: 53
3.7: 37
3.9: 35
3.1: 30

What's interesting to see (because it's counter-intuitive) is that the wait for the feature releases 2.2, 2.4 and 3.4 was on the shorter side, whereas the wait for the bug-fix releases 2.3 and 2.5 was on the longer side (as is the exceptional wait for bug-fix release 3.19).

Another fun list is that of added waiting times in days of feature release and following bug-fix release:

2.0/1: 1225
3.10/11: 1113
3.18/19: 961 and counting
3.0/1: 584
3.12/13: 581
3.16/17: 486
3.2/3: 437
3.14/15: 328
3.8/9: 320
2.2/3: 310
2.4/5: 302
2.6/7: 181
3.6/7: 169
3.4/5: 150

As can be seen, the current 3.18/19 pair is just 5 months away from becoming #2 :-)

For Morpos Deverloper

N1g2Zm5

@ Samurai_Crow


Better outsource your comment to a new thread. Here it is off-topic and might not get the attention you want to have.

Quote:

I posted it as news. The link even made the news here but nobody seemed to reply. Anyway, it's a tangent to the ideal of x86_64 or ARM being a good sequel to MorphOS 3.18. Everything needs recompiling to get the performance including the compilers.

Update:

> Here is an ordered list of the waiting times in days
> just for the fun of it (feature releases in bold): [...]

2.0: 1157
3.10: 1010
3.19: 616
3.0: 554
3.12: 453
3.16: 433
3.18: 377
3.2: 323
3.8: 285
3.14: 240
2.5: 235
2.3: 229
3.6: 132
2.6/3.13: 128
3.3: 114
3.11: 103
3.15: 88
3.4: 87
2.2: 81
2.1: 68
2.4: 67
3.5: 63
2.7/3.17: 53
3.7: 37
3.9: 35
3.1: 30

> Another fun list is that of added waiting times in days
> of feature release and following bug-fix release: [...]

2.0/1: 1225
3.10/11: 1113
3.18/19: 993
3.0/1: 584
3.12/13: 581
3.16/17: 486
3.2/3: 437
3.14/15: 328
3.8/9: 320
2.2/3: 310
2.4/5: 302
2.6/7: 181
3.6/7: 169
3.4/5: 150

A new platform for MorphOS would be great but the Amiga compatibility in the design of morphos presents challenges. The small size of the MorphOS team means supporting all the possible hardware for an architecture is not a viable option. Finding commodity hardware for a reference platform that will be produced 3 years, let alone 5 or 10 is difficult.

MorphOS’s core is the ABox and QBox and being able to switch from one to the other quickly. That is why MorphOS has the tight ties to PPC. PPC can have a 68K emulator in cache for Amiga compatibility and quickly jump back to PPC code.

If a new platform is selected in the multiple core world, the ABox could be assigned to one core and the QBox to another which prevents the context switch penalty but may incur overhead from forcing asymmetric multiprocessing on modern systems that assume SMP.

A more universal solution is for MorphOS to stop being an OS and becoming a wrapper/layer on top of an OS that can run Amiga and MorphOS applications. Then the host OS becomes an abstraction layer that handles the specifics of the installed hardware and lets MorphWrapper focus on how things look and compatibility with old software.

Looking at new PPC platforms that MorphOS could be ported to the WiiU stands out to me. It is PPC based, has 2GB of RAM, and an AMD GPU. The lack of an internal hard drive is a minus but it has a SDHC slot and USB that can be used for an SSD.

Quote:

I don´t know if it has sense for morphosdev and morphos community - it is very special machine, not suited for desktop.
But for me it is very interesting - it has the fastest G3 CPU ever even with L3 cache and SIMD paired instructions. GPU has TeraScale2 architecture.
Such toys I like But I understand, that this make no big sense.


[ Edited by sailor 19.01.2025 - 19:10 ]

Quote:

No matter how fast it is, I am not going back to 1 FullHD screen........

> MorphOS’s core is the ABox and QBox

Is the QBox really being used with the current design, i.e. running the ABox as a single task on the Quark kernel?

> Looking at new PPC platforms that MorphOS could
> be ported to the WiiU stands out to me.

Yes, WiiU port would have been nice. A port for that 12-year-old platform today would be more like a retro project, but interesting nonetheless.

> GPU has TeraScale2 architecture.

R600/R700 is TeraScale1 ;-)