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

More updates here:

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

This is great. 1st establish a project name 2nd talk about its progress with information about specs and other things and make community be with you on this 3rd When community gets interested, tell that to investors (give them link of interest) 4th Make a thread on amigaworld.net and morph.zone where you give people chances to come up with a name for this new PPC product. 5th .. Now you have both community and investors knowing that there is interests in this and that community supports you.

People wants to help you out for sure! Its October and time for this is now :) Good luck and I hope you succeed. I really do.

Regards,
Michal, Amix

As far I understand, there are no good news. Tell me I'm mistaken.

Quote:

Hi,
sorry for the delay, there is going to be a series of meetings in the following week. Depending on the outcome of these meetings, the news will be good or bad but at least it will be a final decision. Though the mails I received are not as many as I wanted to (~120 in total) I didn't want to just dismiss the possibility of a nice ppc board. And although recent news reg. MorphOS on the mac minis -and soon powerbooks?- at least give people some more hardware to play with, it's still not as good a solution as new hardware -at least IMHO. But at least you won't miss a 8610 board that much :D

it's still not as good a solution as new hardware

Only if this new hardware has advantages other than just being new. From what I know, you can't compete with computing power, but you can with interfaces and extendability. Neither mini, nor powerbook are really extendable. Some users may prefer typical desktop machine with lots of slots, sockets and connectors.

Quote:

I think I've discussed this before, but seriously, I'm curious as to why people say that all the time. I have a MPC8610@1.3Ghz here and it absolutely destroys the G4@1Ghz in terms of performance (200-300% speed increase is not unusual). The 8640D is even better (being dual core). I'm pretty positive that the *only* thing the G4 on the mac mini or the powerbook is going to beat the MPC8610 on are cpu-intensive computations with NO memory access (like a mandelbrot fractal). Even a 3D renderer would be much faster on the 8610 as it actually needs totally random access to memory. Don't forget the 8610 has a 533Mhz memory bus.

With regards to the P1022, well, I can't say for sure as it's quite a different design, but that one has a DDR3 memory interface (~800Mhz) which would make up for its somewhat slower CPU design.

So actually yes, I can compete -rather the cpus chosen can- in processing power, in fact I would say it's the other way around. But seriously, I do not intend to start a flame here, I'm too anxious to see if this thing will actually become reality. :)

[ Edited by feanor on 2009/11/7 16:34 ]

I have a MPC8610@1.3Ghz here and it absolutely destroys the G4@1Ghz in terms of performance (200-300% speed increase is not unusual).

Well, the time of Pegasos with its crappy memory bus, is over. Now you compete with mini @ 1.5 GHz and in the near future with powerbook @ 1.67 GHz. If your MPC 8610 board can beat them, fine. But it won't be easy. Extendability of your design and fast, modern interfaces may be your strong point. For example 2 or 4 SATA interfaces for those needing extreme mass storage. Neither mini nor powerbook deliver any other option than USB or Ethernet for that purpose.

Quote:

The G4 in the mac mini has an internal bus at 167Mh. Because it's Dual Data Rate some sites INCORRECTLY report this as 333Mhz which is of course wrong. The "effective" RAM speed is 333Mhz, in the same way the Pegasos II has an "effective" RAM speed of 266Mhz (133Mhz bus). It is indeed better than the Pegasos, but only 25% faster, let's not get overjoyed here.

Regarding connections, well for sure it would support 4 SATA2 ports, USB2 (USB3 if we find cheap controllers) and gigabit ethernet.

[ Edited by feanor on 2009/11/7 18:03 ]

[ Edited by feanor on 2009/11/7 18:07 ]

Quote:

I heard, Intel and other vendors decided to start USB3 controllers production not in 2010, but in 2011. So, I think that USB2 is enough.

Quote:

I actually had this in mind:

http://www.reghardware.co.uk/2009/05/19/nec_usb_3_host/