MorphZone

SMP for AROS

TheMagicM

# 51
Paladin of the Pegasos

Posts: 1220 from 2003/6/17

Quote:

In_Correct wrote:

A MorphOS Developer said no to the request of introducing Sleep Mode, Hibernate Mode, and scheduling to MorphOS. But with these features introduced, they will attract and increase Audience. Not having these features will repel and decrease Audience. Why Shut Down as only option to save energy, and thus have to reopen same things every time?

Thats "IN CORRECT". Get it? In_Correct?? Thank you thank you.. I'll be here all week.

Honestly, I dont care about any mode other than shutdown. I have an SSD in my Powerbook and MorphOS boots up so fast that I dont even care about any hibernate/sleep feature.

People wouldnt exactly flock to MorphOS because we can hibernate.
»25.08.17 - 13:45

In_Correct

# 52
Order of the Butterfly

Posts: 245 from 2012/10/14

From: DFW, TX, USA

Quote:

amigadave wrote:
Quote:

In_Correct wrote:
Also, It benefits MorphOS to be on as many computers as possible, even if it is "just the silly PowerPC". If they feel it is more importance for the X 86 64 (AMD Version is requested.) and also adding the Multi, and the SMP, and the Whatever, then they should do so but then release MorphOS for the PowerPC systems and also including the New Functions such as SMP and Memory Protection and More Than 31 Bit and More Than 32 Bit and Multi Processor. ... Also Better Power Management etc. is desirable.

But if it takes less time to support the additional PowerPC, it makes sense to do that first. And if it takes less time to support New Functions on Power PC compared to X 86 64, it makes sense for Morph to work on New Functions for Power PC first.

That doesn't make much sense, when we have such a small group of developers on the MorphOS Dev. Team, all doing this work in their spare time (which has been drastically reduced, as they get older and have families, which take up most of their free time now).

It does not make any sense to me to ask this small team of programmers to "back port" their work which ports MorphOS to the x64 architecture and gives us memory protection, smp, and "whatever", to the PPC architecture, unless doing so is as simple as flipping a switch on the code compiler, from x64, to PPC. If it is any more difficult to give us the new features of MorphOS for x64 on our existing PPC hardware, I don't think it is worth it, and I would rather have the MorphOS Dev. Team concentrate on our future by improving things on x64, instead of looking backward and continuing to work on PPC.

PPC was great for us, for a time and served its purpose, but once we make the switch to x64, I see no reason to look back (and if I want to look back, I'll use original Amiga hardware, or probably a Vampire), as there isn't enough PPC specific software that I will miss, and I expect we will very shortly have much superior software on our x64 MorphOS systems. (Edit: If the MorphOS Dev. Team does their job right, and makes it easy to port software to the new MorphOS for x64)

Modern x64 hardware that I hope the MorphOS Dev. Team will target, will be SO much faster than any PPC system, I just think it will be a "no brainer" to leave my PPC hardware behind, with regard to running the new MorphOS features you are asking them to back port to MorphOS3.9, and just enjoy those new features on the hardware they were written to run on.

I never mentioned Backport. I only mention if it takes much time to switch to X86 64 Architecture compared with New Functions, especially considering length of release for MorphOS 3.10, that perhaps it would be more efficient to add New Functions on existing support PowerPC computers, especially the ones with more than one processor or processor core, with 32 and 64 bit, while only 31 bit MorphOS.
I Support Quark Microkernel.
»25.08.17 - 13:57

In_Correct

# 53
Order of the Butterfly

Posts: 245 from 2012/10/14

From: DFW, TX, USA

Quote:

geit wrote:
Quote:

In_Correct wrote:
Quote:

Andreas_Wolf wrote:
> New Functions such as SMP [...] and Multi Processor

I meant Multi Core and Multi Processor.

Whatever they are, MorphOS uses only one.

Because I would break compatiblity to use more and I guess you don´t want to be limited to the stuff that comes with the OS.

Same goes for basically any other feature MorphOS lacks. It will break compatiblity with all existing software. Not only 68K.

So it just does not make any sense to do that with PPC just to perform this last step and reach the end of the dead end, which only way out is breaking compatiblity all over again.

Better use the last possible exit.

If that is the best thing to do, then it is the best thing to do.

But can software not be updated to anticipate New Functions?

Would Bounty Help?
I Support Quark Microkernel.
»25.08.17 - 14:01

In_Correct

# 54
Order of the Butterfly

Posts: 245 from 2012/10/14

From: DFW, TX, USA

Quote:

Andreas_Wolf wrote:
> 3.9 is our current latest version, so instead of writing that he would
> want it back ported to what ever was the most current PPC version,
> I used our current "latest version", which is 3.9.

You know very well that 3.10 for PPC (and at least the usual follow-up bugfix release which should be 3.11, if not even more releases) is supposed to be released before any x64 version, so you knew that "3.9" would be wrong. Besides, the severe changes that go with such a backport would surely warrant a version number increase for the PPC version anyway (hence "such version would be [...] the same version number as the then-current version for x64, just for PPC64"). Furthermore, I can't see how "back port to MorphOS3.9" is any shorter or easier to write than "back port to PPC".

> you just love to find any grammar or content fault, and point it out.

As I'm sure you have realized, I make every effort to ignore grammar faults (as well as orthographic ones), not least because I'm sure I make many of those myself when communicating in a foreign language.
As to content faults, yes, I don't like them go unchallenged, so I point them out. And I hope everybody does so when I make those myself.

> I guess that is one way you get your "kicks" for the day

...as much as you seemingly get your kicks from writing things you know are wrong.

Since you are not typing in your primary language, I no longer consider your replies to me as rude and so let me explain why I refer to "The MorphOS Development Team" as "Morph", sometimes with a type of business next to it.

It is very complex to type "The MorphOS Development Team" every time mention "The MorphOS Development Team". Abbreviating "The MorphOS Dev. Team" is not as efficient as "Morph".

Many others have mentioned "MorphOS" as "MOS", while MOS is the name of a Hardware Architecture and also of a company that ceased to exist because of problem factory. Even sillier is the successor company used the same factory instead of a different factory. I do not use this abbreviation "MOS" for "MorphOS" because whenever I use "MOS", I use it as the architecture and the company that made the hardware. And "MorphOS" is not much longer, only type 4 extra letters ... On the contrary there is "The MorphOS Development Team" resembles as a long phrase or even a short sentence.

[ Edited by In_Correct 25.08.2017 - 09:13 ]
I Support Quark Microkernel.
»25.08.17 - 14:13

In_Correct

# 55
Order of the Butterfly

Posts: 245 from 2012/10/14

From: DFW, TX, USA

Quote:

TheMagicM wrote:

Fortunately this week has almost ended.

It is impressive that MorphOS is fast and even faster on SSD. I also want to install MorphOS on SSD.

But this Fast MorphOS Even Faster On SSD does not make Power Management irrelevant.

Meanwhile Mac OS 9.2.2 has Power Management functions such as Sleep Mode, and even when use complete restart or Shut Down and Start Up, the previous things open, including the folders, are open again automatically. Even "a-Dock" seems more efficient compared with MorphOS Panels.

One reason why I do not use MorphOS as often is because of the lack of power management. The annoyance to open everything again by myself, and the energy inefficiency.

Perhaps Bounty Will Help.

And perhaps the best device for people to flock to MorphOS, based on success with RISC OS, is a Pi Device. This might or might not attract new development for MorphOS if amount of MorphOS developers have been decreasing.

[ Edited by In_Correct 25.08.2017 - 10:15 ]
I Support Quark Microkernel.
»25.08.17 - 15:02

Andreas_Wolf

# 56
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

> if it takes much time to switch to X86 64 Architecture compared with New Functions

Porting current MorphOS to x86_64 could be done in a short time, I'm sure. It's the fact that it won't be done without adding the new functionality that makes it so time-consuming.
»26.08.17 - 12:11

Andreas_Wolf

# 57
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

> I no longer consider your replies to me as rude

Being rude has never been my intention.

> let me explain why I refer to "The MorphOS Development Team" as "Morph"

It wasn't me who asked you about this in comment #43.

> sometimes with a type of business next to it.

Always made-up ones at that.

> It is very complex to type "The MorphOS Development Team" [...].
> "The MorphOS Development Team" resembles as a long phrase or even a short sentence.

That's why I usually just type "MorphOS team" without creating any ambiguity :-)

> Abbreviating "The MorphOS Dev. Team" is not as efficient as "Morph".

Just typing "M" would be even more efficient, wouldn't it? ;-) "Morph" seems to be too ambiguous for some, see comment #43, and I too think that one should at least distinguish between a product (the OS) and a group of people (its developers).

> Many others have mentioned "MorphOS" as "MOS"

...and were criticized for it (never by me, mind you).

> MOS is the name of a Hardware Architecture

Is it? I can't remember I heard of that.
»26.08.17 - 12:41

Jim

# 58
Yokemate of Keyboards

Posts: 4977 from 2009/1/28

From: Delaware, USA

>> MOS is the name of a Hardware Architecture

>Is it? I can't remember I heard of that.

Well, as I'm pretty sure we're all aware of, MOS Technology was the creator of the 6502 microprocessor and some of the custom chips used in Commodore computers. They were eventually bought out by Commodore International and renamed Commodore Semiconductor Group.
"Never attribute to malice what can more readily explained by incompetence"
»26.08.17 - 13:34

Andreas_Wolf

# 59
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

>>> MOS is the name of a Hardware Architecture

>> Is it? I can't remember I heard of that.

> MOS Technology was the creator of the 6502 microprocessor

Of course I know the MOS company and its 6502 microprocessor/architecture, but I'm not aware that the 6502 architecture is usually referred to as 'MOS'.
»26.08.17 - 18:12

In_Correct

# 60
Order of the Butterfly

Posts: 245 from 2012/10/14

From: DFW, TX, USA

If not refer to the MOS Technology Hardware Architecture as "MOS", then what?

"6502"?

[ Edited by In_Correct 26.08.2017 - 13:47 ]
I Support Quark Microkernel.
»26.08.17 - 18:47

Andreas_Wolf

# 61
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

> If not refer to the MOS Technology Hardware Architecture as "MOS", then what? "6502"?

Yes, "6502" is what both the instruction set architecture and the microarchitecture of MOS Technology's 6502 processor are usually referred to.
»26.08.17 - 19:05

Jim

# 62
Yokemate of Keyboards

Posts: 4977 from 2009/1/28

From: Delaware, USA

Now that we've settled that, generally when referring to the operating system we use the whole name, MorphOS.
And when referring to the development team, we use that term, or 'MorphOS development team'.

Abbreviations can lead to confusion, and are generally frowned upon in professional documents/communications.

And if I'm not mistaken, MOS has other connotations beyond the semiconductor company.
"Never attribute to malice what can more readily explained by incompetence"
»26.08.17 - 20:13

In_Correct

# 63
Order of the Butterfly

Posts: 245 from 2012/10/14

From: DFW, TX, USA

Does that also mean that MorhpOS Developers are only developers and not from a corporation?
I Support Quark Microkernel.
»27.08.17 - 04:35

Jim

# 64
Yokemate of Keyboards

Posts: 4977 from 2009/1/28

From: Delaware, USA

Quote:

In_Correct wrote:
Does that also mean that MorhpOS Developers are only developers and not from a corporation?

Yes, it is not a business entity, it is a group of allied developers.
"Never attribute to malice what can more readily explained by incompetence"
»27.08.17 - 13:09

ppcamiga1

# 65
Order of the Butterfly

Posts: 215 from 2015/8/23

What endianess has to do with API?
It is simple. Amiga Os API 1.x was designed hardware depended in a way that works on big ednian cpu only.
CPU change to one not working in 32 bit big endian mode, twist API about 180 degrees and made not compatible with old 68k apps.
Why AROS x86 is shit?
AROS x86 is shit beacuse cpu change to to one not working in 32 bit big endian mode, made API not compatible with old 68k apps.
What should be first thing to do after API change to compatible with old 68k apps?
Of course adding memory protection.
Unfortunatelly AROS developer where to stupid to get this.
20+ years passed and AROS x86 still has not memory protection.
No memory protection and no binary compatibility with 68k apps - thats why AROS x86 is shit.
»27.08.17 - 13:36

Andreas_Wolf

# 66
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

> when referring to the development team, we use that term, or 'MorphOS development
> team'. Abbreviations can lead to confusion

As said, I use the term "MorphOS team" and while shorter than the official term, I don't think this can be confusing to anyone.

> MOS has other connotations beyond the semiconductor company.

Absolutely. 'MOS' is an abbreviation for many things in the broader technology field and in the related computing field, among them even two other specific operating systems:

https://en.wikipedia.org/wiki/MOS#Technology
»28.08.17 - 21:50

Jim

# 67
Yokemate of Keyboards

Posts: 4977 from 2009/1/28

From: Delaware, USA

'Soviet UNIX clone', hmm...I'll have to remember that one.
"Never attribute to malice what can more readily explained by incompetence"
»28.08.17 - 22:09

Andreas_Wolf

# 68
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

>>> Change to cpu working in 32 bit low endian mode made API not compatible with
>>> old 68k amiga software.

>> What does API have to do with endianness here?

> CPU change to one not working in 32 bit big endian mode, twist API about 180 degrees

No, the API has not been twisted.

> and made not compatible with old 68k apps.

No, it's not the AROS API that is incompatible with m68k apps but the AROS/x86 ABI. ABI and API are different things. You can google and read up on the difference between them. If you do this, you'll know why an API doesn't have anything to do with endianness, whereas an ABI has.

> cpu change to to one not working in 32 bit big endian mode, made API not
> compatible with old 68k apps.

You already said this and it's still false. And it will remain false no matter how often you will repeat it (not that this has stopped you in the past...).

> first thing to do after API change to compatible with old 68k apps

To make AROS/x86 compatible with m68k apps, the required ABI must be provided. On MorphOS and OS4 this is done by means of the integrated m68k emulation. On AROS/x86, this would indeed be problematic because of opposing endianness between host OS and guest binaries (Emumiga failed for a reason).

> no binary compatibility with 68k apps

Try AROS/m68k.
»28.08.17 - 22:25

Andreas_Wolf

# 69
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

> 'Soviet UNIX clone', hmm...I'll have to remember that one.

Interestingly, a later derivative of this even ran on 68020:

https://en.wikipedia.org/wiki/DEMOS
»28.08.17 - 22:34

ppcamiga1

# 70
Order of the Butterfly

Posts: 215 from 2015/8/23

API was twisted.
Oryginal Amiga OS API 1.x was 32 bit big endian only.
No matter how You call it.
First thing to do after breaking compatibility with 68k apps should be adding memory protection.
20+ years plus passed and shitty AROS x86 still has not memory protection.
»24.09.17 - 18:35

Andreas_Wolf

# 71
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

> API was twisted.

No, the API has not been twisted.

> Oryginal Amiga OS API 1.x was 32 bit big endian only.

ABI and API are different things. You can google and read up on the difference between them. If you do this, you'll know why an API doesn't have anything to do with endianness, whereas an ABI has.

> No matter how You call it.

I call the things what they are. You do not.

> breaking compatibility with 68k apps

Try AROS/m68k.
»25.09.17 - 10:50

Jim

# 72
Yokemate of Keyboards

Posts: 4977 from 2009/1/28

From: Delaware, USA

Funny, memory protection is not as high on my list as some other functions.
"Never attribute to malice what can more readily explained by incompetence"
»25.09.17 - 12:13

ppcamiga1

# 73
Order of the Butterfly

Posts: 215 from 2015/8/23

Quote:

Andreas_Wolf wrote:
> API was twisted.
No, the API has not been twisted.

If oryginal Amiga OS API 1.x will be not 32 bit big endian only, it should be easy to use qemu/petunia/trance to run 68k Amiga Os apps on x86 AROS.
Like it is easy to run ppc/68k apps on x86 linux unser qemu, or 68k apps under MOs/Amiga Os 4.

There is not something like that fully working it means oryginal Amiga OS API 1.x is 32 bit big endian only.
»01.11.17 - 06:42

Andreas_Wolf

# 74
Yokemate of Keyboards

Posts: 12150 from 2003/5/22

From: Germany

> If oryginal Amiga OS API 1.x will be not 32 bit big endian only, it should
> be easy to use qemu/petunia/trance to run 68k Amiga Os apps on x86 AROS.

No, because ABI and API are different things. You can google and read up on the difference between them. If you do this, you'll know why an API doesn't have anything to do with endianness, whereas an ABI has.

> Like it is easy to run ppc/68k apps on x86 linux unser qemu

The reason big-endian Linux binaries can run via QEMU on little-endian Linux (whereas big-endian AmigaOS binaries cannot run on x86 AROS) is that Linux has memory protection (whereas AmigaOS and AROS are singular address space operating systems which are based on message passing concept).

http://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=7183&start=261
http://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6775&start=148
»01.11.17 - 12:23

TheMagicM

# 75
Paladin of the Pegasos

Posts: 1220 from 2003/6/17

@amigadave

I agree with your comment on leaving PPC. Once MorphOS goes x86, I wouldnt go back either. No back porting.. just a "final release" and walk away from that. Concentrate efforts on x86 as I'm sure that will bring much newer set of dev tools/software to MorphOS.
»02.11.17 - 01:40