Mail sent. Support MorphOS. We need new Hardware.

Mail sent. We wish new PPC based Hardware.

with Regards

jcmarcos:
Yes, the CrabFire was essentially a Pegasos 2 G4 in a
custom-built 2U-case and a stripped down Linux OS.

CrabOS, however, was an operating system made by
ex. Gentoo developer David Holm. The target platform
was of course the CrabFire.

Too bad we didn't get the CrabFire to market. We all had
our day-jobs aside and the project pretty much died.

Today, however, I work in my own company with ZyXEL
firewalls. Their latest firewall-line (USG) are mostly running
PowerQUICC CPU's. Only the highest end USG 1000-2000
are running dual-core x86 CPUs.

Mail is sent.

Any update on the figures, how many people are interested in that project?

Quote:

I was just about to paste this:

http://www.codex.gr/index.php?pageID=&blogItem=62

Feanor: is there any limit you have to reach to consider making your project alive?

I'd like 500 mails yes. I could even consider it at 300 (a typical production run is 500 units), ~60 is too few, but I didn't expect to satisfy the limit in 3 days obviously. I'm a patient man -until the end of October at least. :)

Did you try to announce that out of Amiga, Morphos and Haiku related forums? Meaby that would be a good chance to get some brand new users to our market :)

I asked also on linuxppc-dev, and debian-powerpc -though I admit I never found a reply from the debian list. I'll probably try again. I also intend to post on several more linux/ppc lists (gentoo, arch, ubuntu, opensuse).

@feanor

Don't be affraid of multiple cores. MorphOS can use them in relatively easy to implement way. Not SMP, of course, but "dual/quadcore makes no sense for MorphOS" is a myth.

@Krashan

This is interesting...in what way and to what extent could Morphos make use of extra cores without SMP?

Quote:

I'm not afraid of multicores, in fact if P1022 was out now, I would go for this one no question about that, specs are right, the price is right and it's low-power. But samples start Q1/2010, it's a long wait and perhaps people will get bored waiting. We'll see.

@ Ruud

Quote:

In the same general way as MorphOS is able to offload certain tasks from the CPU to a graphics processor, for instance.

There are reasons why seemingly every major OS supports SMP, however

Quote:
The same way as PowerUp used two different processors. I see it as a library allowing for launching processes, or even an extension to dos.library. IPC may be integrated in exec. In fact supporting multiple cores of one processor is easier than PowerUp because of following reasons:

1. Cores are identical, so you need not to use different compiler. You may write the same code which runs on both single core and multicore systems.

2. Cache coherency between cores is ensured by hardware.

Disadvantages are:

1. Only new applications using the extension may take advantage of multiple cores (on the other hand it does not break compatibility). Old apps will run on "main" core only.

2. Programmer should desing an application multithreaded way (but this is also needed for systems with SMP as far as I know).

@ Krashan

Quote:

Yes, if a single application is supposed to utilize, say, four cores when running on an SMP-capable OS, then you need to design it to be multithreaded.

That being said, you can run four single-threaded applications on a quad-core machine and your typical SMP-capable OS will manage to utilize all four cores (one per app, for instance) rather than run the applications on the main core only.

Quote:

Exactly the same thing I thought of years ago. In fact, the PowerUP framework was more difficult than this scenario.

Quote:

The "dos.library" is the one that starts processes?

Quote:

Of course, some extensions would be needed in the kernel. By the way, is anyone surprised that we are talking about SMP, and there's NO mention of Quark? MorphOS IS the A-Box, there's still a SMP capable kernel beneath, and funnily, its SMP abilities wouldn't be used.

Quote:

Yes, one minor (ahem) detail, that emphzsizes just how amazing was the PowerUP system. A computer inside a computer, an operating system inside an operating system.

Quote:

There's been a lot of talk about this since a long ago...

Quote:

Of course, these are not disadvantages of this implementation, only the obvious, natural compromises, of SMP computing. For example, sometimes, doing something on several cores is actually slower than ina single one. That can't be counted as a disadvantage of the implementation, it's just life.

Quote:

Actually, life doesn't really bother with such details, it's just computers that deal with such stuff :)

I sent my email yesterday.

@Krashan

I would do multiple core support by simply allowing (through some new Exec functions) tasks to enter and leave a special state where they are multi-core-safe. While in this state the scheduler is allowed to run them on other cores. See here.

Quote:
As it has been said many times, full SMP in MorphOS would be very hard to implement if possible at all. What I'm talking about is some kind of asymetrical multiprocessing (AMP), where one of cores is considered the main one, and the rest serve as a kind of "coprocessors". The kernel initializes all cores and starts a supervisor thread on every secondary core. This thread waits for messages from the kernel in idle state. When some application wants to launch a MProcess (short from "multicore capable process"), the kernel assigns one of secondary cores (it may be the main one as well if there is only one, or load balancer detects that the main core is the least loaded one). Then MProcess is added to the task scheduler of a core supervisor.

Quote:
Yes, the usual way to start a process is to call CreateNewProcTags() from dos.library. As it is a tag based function, it may be easily extended. In fact the difference between a regular process and "MProcess" would be that the system is allowed to run MProcesses on secondary cores. This is needed for compatibility, as many of existing multithreaded applications rely on the fact (and use it for IPC) that any two of their threads cannot be executed at the same time. Applications creating MProcesses have to do their threads synchronization and communication with simultaneous execution in mind.

Quote:
Fortunately exec.library relies on a minimal set of multitasking primitives, these are basically just signals and semaphores. All the rest rely on them (like messages and message ports). Then these extensions will be implementation ones, not API ones.

Quote:
I do not like the idea personally, as it assumes the kernel will have to move a process from a core to another one. This will be performance costly and can potentially create many compatibility problems. My idea is that a proces once launched on core N will stay there until termination. About calling libraries from MProcesses - those libraries with shareable bases should be safe. Libraries with non-shareable bases (bsdsocket.library for example) will be not allowed to be called from MProcesses in the first stage of multicore transition. Then multicore-safe versions of them will be created. It is a problem of course, but not very big one. The first candidates for MProcesses will be tasks of number crunching and multimedia processing. Such tasks do not need any I/O libraries, just data are passed via memory blocks and basic IPC is needed for synchronization.

[ Edited by Krashan on 2009/9/30 17:15 ]

Using additional cores as coprocessors should be a good fit for the Amiga hardware & software model.

Mail sent with a big thanks. Anyway it will go...