Hi Morphos Team,

For what I've read from Amiwest 2010/2011 it seems that some features already available on Morphos in the kernel land, for instance SMP will be available in user land for OS 4 am I correct?
Aros are also thinking of way to implement features like SMP.
So my question is what about Morhpos? isn't it time to forget about binary compatibility? Something like ABox+, I suppose that the current ABox could run legacy apps, and apps still in developement or apps where source code are available could benefit from new features.

I know that you could argue that its just announcement but one day it'll happens and I don't wanna see Morphos felt behind.
It's nice to port Morphos to Mac but it's also important to move forward and bring more feature from a developer perspective that will enable them to develop apps more rapidly, a kind of Cocoa for Morphos. Why not extend MUI in other direction than just UI.

ABox+ or whatever the next step is should remove Amiga API limitation for the better in the long run.
Like Apple did, Classic for legacy apps, Carbon so programmers could use new features while not having to learn a new API and now Cocoa. Classic and Carbon are transition API, Cocoa is the way to go, if Mac did it why not Morphos?

Thanks
Kamel
PS I know that the MOS Team do not have the resources Apple have.
[ Edité par kamelito 31.10.2011 - 12:53 ]

[ Edité par kamelito 31.10.2011 - 12:59 ]

> For what I've read from Amiwest 2010/2011 it seems that [...] SMP will be
> available in user land for OS 4 am I correct?

I don't know what was said at this year's AmiWest on that topic but this is what Hyperionmp told us some weeks before:

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7183&start=336

> Aros are also thinking of way to implement features like SMP.

From this recent interview I understand that for now they're going for ASMP instead of SMP:

"First of all it could be extended with exec-alike library which would allow to run dedicated tasks on secondary CPU cores (PowerUP-alike approach). This is much easier to implement than full SMP (because the new library is legacy-free), but still useful (for example video players and coders could support this)."

Yes a port of morphos to X86 is a must.

SMF

For who?

>Yes a port of morphos to X86 is a must.

Nah.

Continuing develoment yes. Other ISAs, maybe later.

well, afaik, ASMP is somehow supported by legacy AmigaOS via 'task' which allowed to run a special code and wait until it's finished or do some other work and then check if the task has finished... so i guess, that this implementation for another cpu wouldn't be that difficult for cleanly written system applications... some other ASMP functions could be simply implemented, like RunASMP(code,args,cpuid), AllocCPU(), FreeCPU() etc :)

bye, MarK.

Well "tasks" still run the same CPU so thats not the big issue ....

I really think something like PuP revisited would be the best approach, read you got special tasks (maybe even a special kernel) running on the 2nd core. Limitations for these tasks need to be well defined and documented (like no access to system function except for some special exec ones).

It would offcourse be well welcomed if these tasks could still be started on the 1st CPU/core (for single CPU systems or when the 2nd core/CPU is allready overwhelmed with work) and the code for both main and special task could be combined into on binary. The hackish way that was achieved with WarpOS did IMO contribute to it's relative success over PowerUP).

One has to make 100% sure that all memory accesed is protected by Semaphores (would these also need to clear caches ?) but thats allready a must if you have multithreaded SW running on one CPU/core and not really that hard.

well, anyway, i believe, that the upcomming MorphOS 3.0, that should be released until the end of this year, won't "just" add support for powerbooks and to add some system improvements (i'd call it then 2.8)... i'd love to see the (A)SMP support, as from 1.4.5 to 2.0 was (imo) the main feature the altivec support, now, i'd expect the multicpu support...

bye, MarK.

@kamelito : I'm agry with you. It's time to to bring MorphOS to present.

It's time to get Qbox to the frontside.

It's time to go to another CPU family. ARM is invading the Personnal computing begening from PDA devices then Netbooks and next step well be desktop machines.

Other AmigaOS systèmes are going this way. (SMP, Ressource tracking, memory protection etc)

[ Edited by serge 03.11.2011 - 11:54 ]

Quote:

No, they are not.

I trust you Itix, but will see what AmigaOS 4.2 brings...I don't see the point of putting a double core CPU if its just to have one running...

What about others topics of my previous post? is it possible for you to tell more? The AOS4 team spoke about their roadmap, some stuff are interesting. Let's say it's not vaporware, this mean that they're moving forward. I just hope that you're also moving forward in the software areas not only the hardware side of thing which is also crucial.

thanks
Kamel

@kamelito

I dont think we are going to drop binary compatibility as long as we are on PowerPC platform. Native endianess allows easy integration of old 68k applications to the system and it would also hurt PPC native software base.

To develop applications more rapidly I have got some ideas and plans and projects too but honestly I can not promise anything I still have got some bug fixing to do for MorphOS 3 what is the priority now.

Hello,

Amiga Os 4.x does not have virtual mem or mem protection.
They do not have SMP either. Hyperion is promising a lot, but they even do not have
a stable usb2 driver for now.
After Mos 3 is released, i also hope that the Qbox will continued.
Moving to arm would great, i do not care about backward compatibility to 68k/ppc.

regards
eliot

[ Edited by eliot 03.11.2011 - 14:25 ]

> Amiga Os 4.x does not have virtual mem

I think it does. Hyperion also claims OS4 has it:

"Modern operating system features such as virtual memory have been added without losing that intrinsic Amiga feel."
http://www.amigaos.net

@Itix

Thanks for the infos, if you have plan to make tools to speed up Morphos applications development, feel free to post your paypal address so I can support your effort.

Kamel

#include <stdio.h>

int main(void){
unsigned int i=0;
char *c;
while(1){
*c='\0';
c++;
i++;
printf("%u written\n", i);
}
return 1;
}

Compile it, run it.
There won't be any segfault on OAS4.x, instead hust a freezing aos4.x

[ Edited by eliot 03.11.2011 - 16:50 ]

@Andreas_Wolf

It is only co-operative. Applications must allocate memory using right memory flags.

@kamelito

Thanks but no thanks, users registering MorphOS is my reward

itix,
Quote:
AFAIK that's true - but nevertheless it's vitual.

@eliot
Quote:
I knew that someone will bring this on... - After changing my USB2.0 card in my Pegasos II (which, btw, didn't work with MorphOS, bringing Poseidon to run amok, but worked flawless with OS4.1) I can only say that with both my OS4.1 machines USB2.0 is rock stable (with all memory sticks and external harddisk and some mice and keyboards I have tested). Nevertheless transfer rates are higher with Poseidon - something I got used to (I mean: MorphOS is faster... ).

kamelito,
Quote:
Pfff....I always assumed Trance and the very fast and transparent emulation layer as a *big* advantage - and I suppose binary compability plays it's role here. Please don't propagte that inferior UAE integration stuff. Up to now I see binary compability as a key feature.

For a user's point of view we should talk about *user* features as well: Guido's Grunch and MagicBeam i.e are very wellcomed (at least by me) - and a new dock subsystem would be nice, too ( I know that this is already being worked on...).

[ Editiert durch cha05e90 03.11.2011 - 19:34 ]

@Itix, I'm ok with that, but I guess I'll have to wait for Morphos 3.0 since I've a PowerBook 5.8 unless you wanna bring me in the beta team :)

Kamel

well, another question about ASMP, when i do have the 2xG4 in my PowerMac, will MorphOS let me use instructions/registers, that makes it possible to use the second cpu? There are docs about SMP usage at freescale, afair, so if i'd be able to use it atleast for my own usage, i'd be satisfied for a while... :)

bye, MarK.

Update:

>> Aros are also thinking of way to implement features like SMP.

> From this recent interview I understand that for now they're going for ASMP instead of SMP: [...]

https://gitorious.org/aros/aros/commits/silly-smp

Some explanation given by the responsible programmer:

http://www.amiga.org/forums/showpost.php?p=745766