Any new info about Arix and it's implementation of multicore support?

http://www.arixfoundation.com/
https://www.facebook.com/pages/Arix-OS/414578091930728

Quote:

Don't know anything about Arix, but AROS SMP is laid on ice as it seems. There is no technical reason, why it would not work, there is just this "lack of manpower resources" thing, that still needs to be debugged and fixed.

> AROS SMP is laid on ice as it seems. There is no technical reason,
> why it would not work, there is just this "lack of manpower resources"
> thing, that still needs to be debugged and fixed.

Update:
http://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=10057&forum=16&start=75

Since there has been so much work to get WinUAE working fantastically, and even EUAE work very well, breaking backward compatibility with the Amiga API and depending on emulation for legacy support in the new x64 version of MorphOS is a viable solution for most current and former Amiga users. Having true SMP, as well as memory protection, IMO, are a must for the new x64 version of MorphOS, or what is the point of breaking compatibility with the old API? It will be interesting if the small group of MorphOS Developers can come up with a new OS that has enough legacy flavor and new ideas, to make it worth using, instead of the more popular and better supported Linux distros, or the entrenched Windows and MacOSX options.

Another option for legacy support in a modern x64 computer might be to re-visit the idea of installing an "Amiga-on-a-card", with something like the Vampire stand alone FPGA system, on a PCI card, but I suppose that has its Pros and Cons as well, and emulation using EUAE might be the best answer. The Apollo core is getting more and more interesting every month, and the latest addition of some/most MMX, or SSE, or what ever it is called, instructions that have been added to the core, make it even more interesting as a legacy option.

> the latest addition of some/most MMX [...] instructions that have been
> added to the core, make it even more interesting as a legacy option.

These instructions are for new/updated software and cannot be used by legacy software.

Quote:

Yes, the X1000 has a dual core cpu, and all A-eon AmigaOnes (until Tabor) have had 64 bit cpus.
Yet another reason Tabor is such a POS.

Hopefully, when we go multicore, it will be part of the ISA shift to X64.
As has been pointed out, whatever gets developed under X64...could be backported.

But Hyperion's plan to produced a multiprocessing AmigaOS variant without backward compatibility problems? Ridiculous.


[ Edited by Jim 02.03.2017 - 11:50 ]

Quote:

If you were to compare the price of that 2500...

> Hyperion's plan to produced a multiprocessing AmigaOS variant without
> backward compatibility problems? Ridiculous.

If AROS can do it, why not Hyperion? AROS is open source, after all ;-)

Quote:

Good point!

My main Amiga for many years was an accelerated A2000, and I know I spent at least $3,500 on hardware for that system, probably over $4,000. Then if you adjust the value of those dollars from 1990, when I spent that money to purchase and accelerate that A2000, it would probably be close to equal with $5,500 2017 dollars.

The reason money is a valid argument against purchasing an X5000, is because Windows and Linux users choosing x64 hardware today, can spend as little as $500 to $1,200 to get a computer system that is 2 to 4 times faster than the A-Eon X1000 & X5000 systems. If they want to spend $3,000, they can probably get performance that is 10 times faster, or more. But of course, those x64 systems can't run MorphOS, or AmigaOS4 (except slowly through emulation).

At the time I purchased my X1000, I did not think it was a bad investment, compared to what I had already spent on my Amiga addiction, but now as the years drag onward, and there is still no hint that AmigaOS4.2 will ever be finished, my conviction regarding the purchase has tarnished a bit.

@amigadave

500 to 1200$ for a PC 2-4 times the speed of an X5000? I think your lagging behind a few years, such performance can be found dumpster diving these days.....

> I know I spent at least $3,500 on hardware for that system, probably over $4,000.
> Then if you adjust the value of those dollars from 1990 [...] it would probably
> be close to equal with $5,500 2017 dollars.

5500 USD today were inflation-adjusted 2960 USD in 1990. 3500 USD in 1990 had the buying power of today's 6500 USD.

Quote:

I would not be surprised to read an announcement soon that OS4 has SMP that works in exactly the same way as AROS does it. ;)

[ Edited by Intuition 03.03.2017 - 09:14 ]

Quote:

When did AROS become 3.1 compatible?
I must have missed that.
It can run AmigaOS binaries without UAE?

Quote:

My estimate was a guess, and I was trying to be conservative, so I am not surprised to see that I was $1,000 low. I don't even know where to look to find out inflation adjusted values, but could probably google it and find where the calculation can be made.

Once MorphOS moves to x64, hopefully the MorphOS Devs. will choose readily available hardware that is priced competitively with all other x64 hardware, and we will finally have (nearly) up to date hardware power, at up to date hardware pricing. The problem any small group of developers has writing an OS for any hardware is time. It takes time, sometimes a lot of time, to write hardware drivers, so by the time the OS is finished and released, the hardware is no longer "up to date", and depending on just how long the writing of the drivers and the rest of the OS takes, it could be possible that the hardware they are aiming for becomes no longer available, except through a few dealers who have a handful of NOS units, and the used market.

Even Linux, with its thousands of programmers, and considerable commercial support, has a difficult time supporting all the newest hardware. The MorphOS users will most likely just have to accept that they will always be limited to using just a few systems, which are probably 1 to 2 years old, at the least, and be patient with the Devs., when waiting for newer hardware to be supported.

Creating a new x64 OS, with modern features, but also very MorphOS like, and unique enough to make it worth all the effort, is a huge undertaking. I believe in the MorphOS Dev. Team though, and would be willing to bet some hard cash that the first x64 version of MorphOS is released prior to AmigaOS4.2 being completed and released, as first described by Hyperion many years ago. I no longer believe that Hyperion has the ability to complete AmigaOS4.2 as it was first described, ever!

>>> Hyperion's plan to produced a multiprocessing AmigaOS variant without
>>> backward compatibility problems? Ridiculous.

>> If AROS can do it, why not Hyperion? AROS is open source, after all ;-)

> When did AROS become 3.1 compatible?

AROS is source-compatible with AmigaOS 3.1. As far as I know, existing AROS programs won't have to be recompiled to run on the boot core in SMP-enabled AROS. Why shouldn't the same be possible with OS4 (or MorphOS, for that matter)?

> It can run AmigaOS binaries without UAE?

No, but I fail to see the relevance for what I wrote.

Quote:

"As far as I know..."

I guess we will see how that goes, I'll believe it when I see it done.

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?