Quote:

Somewhere around its inception. It's binary compatible on m68k, and source code compatible on the rest.

> "As far as I know..."

Well, at least that's what I understand the author has said a month ago (see link in comment #12). Is it a misinterpretation on my part? Or do you think he doesn't tell the truth (mind you, he has it running already)?

If I'm not mistaken, the Frieden brothers say they have an SMP capable kernel as well.
From the description you pointed to, the system sounds similar to an ASMP OS.

We've always know something like that could be kluged.

MorphOS could easily use each core as a separate environment (each with its own scheduler) with a common display via an enhanced Ambient.
But is that SMP?

I'm not trying to be a downer here.
I'm sure our developers have thought about it, but they seem to want to switch ISAs before they tackle multiprocessing.

> From the description you pointed to, the system sounds similar to an ASMP OS.

To me it sounds like non-SMP for existing binaries and full-fledged SMP for programs using the new API.

> We've always know something like that could be kluged.

I always assumed implementing SMP would break compatibility with existing binaries (i.e. they don't run at all). AROS shows that compatibility can be retained.

> MorphOS could easily use each core as a separate environment

That's not what AROS does. In AROS, old single-core binaries and programs using the new SMP API can run in the same environment. Unless I misunderstood.

> But is that SMP?

Your proposal for MorphOS: no. What AROS does: yes.

> our developers [...] seem to want to switch ISAs before they tackle multiprocessing.

The official rationale for this has been that implementing SMP (and other modern features) would break compatibility anyway. But as AROS shows, that doesn't have to be in case of SMP.

>To me it sounds like non-SMP for existing binaries and full-fledged SMP for programs using the new API.

Sure. And we've discussed this before, but its still a hybrid solution.
I didn't say I was against the idea, in fact a few people have mentioned it could be implemented later in PPC MorphOS.
But its not a focus as far as I know.

>> To me it sounds like non-SMP for existing binaries and full-fledged SMP
>> for programs using the new API.

> Sure. And we've discussed this before

As I said, before the recent AROS developments, I never deemed this possible.

> but its still a hybrid solution.

I guess a solution where also old binaries can be moved to other cores than the boot core is not possible.

> in fact a few people have mentioned it could be implemented later in PPC MorphOS.

MorphOS team members among them?

>I guess a solution where also old binaries can be moved to other cores than the boot core is not possible.

No, of course it is.
But scheduling across multiple cores, its a bit more complicated than just being able to run code on more than one core.

And yes, I'd be pretty surprised if a few of the MorphOS developers hadn't toyed around with using the additional cores.
After all, MorphOS as it exist right now would not even have to be aware of the other cores' operations.

> scheduling across multiple cores, its a bit more complicated than just
> being able to run code on more than one core.

Isn't the AROS solution capable of the former for programs using the new SMP API?

>Isn't the AROS solution capable of the former for programs using the new SMP API?

I don't know until I see it working.
But been discussing the idea of a similar solution for MorphOS for awhile as well.
And if certain legacy apps can't be made to behave within the SMP environment, they could be boxed onto one core.
The e5500 and e6500 with their hypervisors would be very capable of concurrently running a multiple number of possible single core and SMP concurrent operations (even concurrent 32 and 64 bit environments).
When you get to the e6500, the possible thread count makes things really interesting.

BTW, did you notice NXP's docs on interfacing DDR4 with Qorlq cpus?

> I don't know until I see it working.

https://www.youtube.com/watch?v=OF8qRc8y6P4
https://www.youtube.com/watch?v=pCCuqpCYZsQ

> if certain legacy apps can't be made to behave within the SMP environment,
> they could be boxed onto one core.

If I understand the AROS solution correctly, everything that has run so far will run in SMP-enabled AROS as well.

> The e5500 and e6500 with their hypervisors would be very capable of
> concurrently running a multiple number of possible single core and SMP
> concurrent operations (even concurrent 32 and 64 bit environments).

I clearly favour the AROS solution of running everything within the same environment.

> did you notice NXP's docs on interfacing DDR4 with Qorlq cpus?

You mean this? QorIQ T1 series has DDR4-compatible memory controller. Is there anything special about that implementation?

Nothing really special, except they have done the layout work.

>I clearly favour the AROS solution of running everything within the same environment.

IF everything CAN be made to run in the same environment...

I'd parse that into "I...favor...running everything", and still would like to have the benefit of support for full 32 or 64 bit multi-core threaded code.

> Nothing really special, except they have done the layout work.

Freescale released the T1042D4RDB about 2 years ago (we talked about that board via PM back then), so that's when they must have done the original layout work at the latest.

>> I clearly favour the AROS solution of running everything within the same environment.

> IF everything CAN be made to run in the same environment...

SMP-enabled 64-bit AROS *can* run old 64-bit single-core AROS binaries and new 64-bit AROS binaries using the new SMP API in the same environment. Of course, I can't say for sure whether that would also be possible for PPC MorphOS (in 32-bit mode, that is), but I think (and hope) it is. Maybe a MorphOS team member will condescend to give us mortals any details about this.

> I'd parse that into "I...favor...running everything"

...with "everything" meaning these:
1. old and current single-core MorphOS binaries
2. future MorphOS binaries using a future SMP API (AROS-like)
3. m68k binaries that are already running on current MorphOS

> and still would like to have the benefit of support for full 32 or 64 bit multi-core
> threaded code.

Yes, that's already included in my definition of "everything" above. Without "multi-core threaded code", "everything" would just mean exactly what we have already right now. And while my MorphOS hardware is a 64-bit system, I don't have a need for 64-bit OS or programs (on the same PPC hardware, 64-bit is slower than 32-bit anyway). For me, it would be enough to turn PPC MorphOS from the 31-bit OS it is effectively now into a real 32-bit OS so it can address 4 GiB of RAM.

Quote:

Bingo!

I think that making MorphOS a truly 32-bit OS, to allow it to access 4gb of memory, plus giving it SMP similar, or exactly like they are pursuing in AROS, and possibly implementing some kind of memory protection, would satisfy most MorphOS users.

I wonder how many MorphOS Dev. Team members are conflicted regarding the move to x64 hardware, and the monumental task that such a project (probably) is, instead of continuing with our current PPC stable version of MorphOS, which they know well, and have worked on for so many years? I would think that the move to x64, no matter how attractive, must be daunting, considering the small size of the team, and the reduced free coding time that most of them have, now that they are older, and have higher family responsibilities that eat up much of their free time.

Let's hope that the move to x64 is less painful for the Dev. Team than I am imagining, and the benefits for both them and us, the users, make the decision easier than I can know.

I don't know about apple's G5, but NXP's e5500 and e6500 cores seem to be able to concurrently support both 32 and 64 bit code.
At this point, even if you didn't want to pursue SMP, the possibility of rewriting some parts of the OS to use the additional memory and cores would be possible with no compatibility issues I can think of.

Quote:

No doubt its Freescale's design.
NXP will still sell me a D4 model for about $1300.
But I'm having trouble locating a picture of it (I can find images of the other T10XX RDBs).
This was what I thought would have made a good start as a base to build something better than Tabor.

Pity we aren't likely to see further developments with these cores.

And unless a lower cost derivative of the Power8 or 9 turns up...




[ Edited by Jim 04.03.2017 - 20:17 ]

>> Freescale released the T1042D4RDB about 2 years ago

> This was what I thought would have made a good start as a base
> to build something better than Tabor.

When the T1042D4RDB was released, Tabor boards were already in the hands of developers.

> I'm having trouble locating a picture of it

I couldn't find any either.

>I couldn't find any either

Weird, isn't it?
Images of the T1024RDB, no problem.

And something like Tabor could have been produced about as early as the X1000.

I'm pretty sure the idea of using a 32bit Qorlq cpu was something Varisys proposed that long ago.
But the use of that particular cpu core, and the long development time really have made that project unattractive to me.

So, what we do have are our current systems, with the promise of future X5000 support.
That places limits on the utility of both SMP and 32bit addressing, as many of our systems have a single cpu and only a few support more than 2GB of ram.
In fact, its only the 64bit systems that support more memory.
If we are going to support 4GB and 32 bit, why not 64 bit (and a lot more range)?

[ Edited by Jim 08.03.2017 - 12:08 ]

> something like Tabor could have been produced about as early as the X1000.

Yes, but that would have meant postponing the X1000 instead.

> our current systems, with the promise of future X5000 support [...] places limits
> on the utility of both SMP and 32bit addressing, as many of our systems have
> a single cpu and only a few support more than 2GB of ram.

If MorphOS gets SMP support or 4 GiB RAM support, I'm sure a significant percentage of MorphOS users will upgrade to a used machine that can work with both (i.e dual-CPU PowerMac G5) or either (dual-CPU PowerMac G4 for SMP, single-CPU PowerMac G5 for 4 GiB RAM). Besides, even a 2 GiB machine would benefit from 4 GiB RAM support, as the I/O address space wouldn't any longer collide with the RAM addressing, so we'd have full 2 GiB RAM at our disposal instead of the 1.5 GiB we have now (or the 1.7 GiB announced for MorphOS 3.10).

> If we are going to support 4GB and 32 bit, why not 64 bit (and a lot more range)?

64-bit MorphOS wouldn't work on any of the currently supported 32-bit machines (i.e. everything except PowerMac G5 and X5000). And I'd guess m68k compatibility would suffer less from expanding addressing to 32-bit than it would do from expanding to 64-bit.

Quote:

I never looked into it before, so I don't know the answer to this question, but why was the original AmigaOS 31-bit, instead of 32-bit, and was there any previous discussion by anyone within Commodore, or outside, such as peer review, that ever considered what it would take to make AmigaOS3.x 32-bit? Would such a modification break most/all of the legacy software, or cause it to require re-compiling? The 31-bit/32-bit discussion, as it relates to how the OS works, and what it would break is a little bit over my head.

I am guessing that AROS was designed from the beginning with either 32-bit, or 64-bit in mind, so they must have figured out how to fix the problem. Since neither MorphOS, or AmigaOS4.x chose to attempt to move to 32-bit, I can only assume it was for software compatibility purposes (edit: to retain binary compatibility).

[ Edited by amigadave 05.03.2017 - 13:42 ]

> why was the original AmigaOS 31-bit, instead of 32-bit [...]?

Comment #58 has the answer from henes:
http://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=6684&forum=11&start=57

Some more from ThoR:
http://www.amiga.org/forums/showpost.php?p=788121
http://www.amiga.org/forums/showpost.php?p=788162

Excellent references. The reason behind that limitation was never clear to me either, thanks.

Quote:

AROS is not source and binary compatible.

But on 68k one can add libraries and patches from oryginal Amiga Os and made 68k AROS
enough source and binary compatible.

AROS x86 is of course worth nothing shit.

AROS x86 was shit, AROS x86 is shit and AROS x86 will be shit.

It is simple.

CPU change to one that not support 32 bit big endian mode already breaks compatybility.

AROS x86 have to have all drawbacks of original amiga os removed at time of change api to not compatybile.

AROS for LE cpu should be amiga gui and graphics on top of unix.

AROS x86 with cheated SMP is set of hacks still with out memory protection.

Quote:


AROS 68K is most certainly both source and binary compatible to AmigaOS.

Quote:
You seem to always confuse API and ABI.

Definition of API :

An API defines the interfaces by which one piece of software communicates with another at the source level.


Definition of ABI :

Whereas an API defines a source interface, an ABI defines the low-level binary interface between two or more pieces of software on a particular architecture. It defines how an application interacts with itself, how an application interacts with the kernel, and how an application interacts with libraries.

Quote:

What can be asserted without evidence can be dismissed without evidence :)

Quote:

Not really, if its a fairly obvious fact.
And "CPU change to one that not support 32 bit big endian mode already breaks compatybility", isn't worded that well, but it is factual.
Endian mode does greatly affect compatibility (although, conversely, it makes porting from other little endian platforms easier).