> 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).

Quote:

Yawn. AROS runs on multiple CPU architectures, which includes two 32-bit big endian ones (ARM is technically bi-endian too).

Quote:

I have no clue why that matters, since the post that we were discussing obviously references the X86/X64 version.
Although...when it come to compatibility, the 68K version still has a long way to go.
And ARM? I was actually one of the people advocating that ISA until the developers decided on X64.

Quote:

It matters as much as the lone sentence you picked out of his rant rebuts what I said.

Quote:

Right...except what he said, at least in that one instance, was correct.
And all NG OS' have compatibility issues.

Quote:


Jim don't confuse speed with compatibility. AROS 68K is actually very much source and binary compatible. As for i386(Abiv1) and x64 they are both source level compatible.

Quote:

So you both keep saying, but the X86/X64 versions are running on a little endian cpu which does cause compatibility issues.
And no AROS port has full support for all libraries.

Basically, every port is going to require some work-arounds.

Compatibility? By that I assume you just recompile it and it works?

And now that you mention it, AROS 68K IS damned slow.

Edit: Sorry that IS a bit inaccurate. OS friendly ports for the most part do NOT require any alteration.
AROS is certain as close to binary compatibility as we are ever likely to see.

And I wish the development team nothing but good fortune (just remembered I had friends working on this).

Just ignore the over the top BS guys.
I'd edit it out, but then the post would only serve to bolster my opinion (that a compatible X86/X64 OS is kind of pointless if you have to alter code to suit the endian structure of the new cpu).

Still, as a project, pretty damned impressive.

AND, in a fork to X64, we'll face the same challenges porting existing code (with potentially less API support).
So, AROS? Still my second favorite NG OS.

[ Edited by Jim 08.03.2017 - 17:52 ]

Quote:

That depends entirely on how it was designed in the first place. Source that was designed to be endian agnostic in the first place has no issue at all. If there is an issue(bug). It can and should be fixed in the OS not the application.

Quote:

Yes that is exactly what I mean. You may think I bought FinalWriter so AROS would have a wordprocessor. That's only part of the reason. I bought it also to help find bugs in AROS to allow cleaner ports. ;)

Quote:

Merely the gui is damned slow iirc that is actually part of the icon.library's fault.

Quote:
I seriously don't get the whole us vs them mentality that goes on in this community. As someone who has spent $1000's on what to me is a hobby it makes no sense.

Quote:

Reversing data structure based on the endian of a CPU is less of a big deal than making sure the OS is handling the API properly. ;)

Quote:

Yes, the us against them thing is overblown.
I get it most from the OS4 fanatics, and not all OS4 users are that fanatical (some of our posters have copies of that).
And I need to remember that I have some friends in both of the other two "camps" (heck, there are four factions if you count the legacy only guys/gals).

The purchase of FinalWriter was a pretty cool move.
I am definitely in favor of native apps.
The Linux ports like Firefox or OpenOffice just slow us down further.

One thread I see in not just my life, but everyone's in general, is a need to be less confrontational and more open.

I was a little biased against AROS by my earlier experiences (but then, all Amiga OS related projects were a slight challenge for me originally, I am NOT a "native" to this environment).
Once the drivers progressed a bit more, and especially after I saw some of the cool OpenGL demos (GLxcess in particular) I have too admit, I have definitely grown in my appreciation of the OS.

Then there are the bounty programs (some promoted by Bill Buck's Power2people organization), hey successful funding...cool.

@Tim

Does using PeterK's 68k icon.library solve the slowness issue with aros68k?

I remember reading that work was being done on getting aros to compile with vbcc to see if it improves the performance of the generated code compared to newer versions of gcc. Did anything come of that?

[ Edited by Intuition 09.03.2017 - 11:35 ]