ARM for the future?

[WolfToTheMoon]

...

takemehomegrandma, care to explain Genesi's relation to MorphOS... I haven't been following MorphOS that closely so I'd like to know more about that. I noticed there's Genesi's subsection on the MorphZone.

edit: Sorry, I've meant takemehomegrandma, not Iggy... but seeing both of you use MorphOS so I guess both of you could also answer me... I guess

[the_leander]

care to explain why should anyone write their OS completely in asm code in a world of multicore GHz CPUs and storage that sizes in TBs.... instead of putting up various pictures?

The challenge of doing so. Menuette is very cool as projects go.  

But beyond that just because you have multicore cpus doesn't mean you shouldn't or needn't bother with optimising code. The major growth area in terms of development is in portable computing, starting with smart phones and continuing with tablets and netbooks. Heavy, unoptimised programs don't just mean poor performance, but decimation of battery life.

[jj]

takemehomegrandma, care to explain Genesi's relation to MorphOS... I haven't been following MorphOS that closely so I'd like to know more about that. I noticed there's Genesi's subsection on the MorphZone.
 
edit: Sorry, I've meant takemehomegrandma, not Iggy... but seeing both of you use MorphOS so I guess both of you could also answer me... I guess

 
There is no longer any connection between Genesi and MorphOS.  They are two totally seperate things.
 
No support either way any more as far as I know

[WolfToTheMoon]

But beyond that just because you have multicore cpus doesn't mean you shouldn't or needn't bother with optimising code. The major growth area in terms of development is in portable computing, starting with smart phones and continuing with tablets and netbooks. Heavy, unoptimised programs don't just mean poor performance, but decimation of battery life.

I agree partially, but one should also note that today's compiler's do a pretty fine job of optimizing output asm code. Probably better then 99% of programmers who would try to replace them with a manually written asm/machine code. If one writes a elegant, properly structured program in a higher-level language such as C or JAVA, one will have a responsive program... Simple as that. No need to use asm today.

I agree that Kolibri and MenuetOS are neat projects. But if I wanted to code a OS from scratch, in 99% of situations I'd have to be heavily dosed with a powerful toxic to choose asm over C/C++.

[WolfToTheMoon]

There is no longer any connection between Genesi and MorphOS.  They are two totally seperate things.
 
No support either way any more as far as I know

I wonder if that could change if MorphOS goes ARM. It would be a great thing for MorphOS.

[the_leander]

I agree partially, but one should also note that today's compiler's do a pretty fine job of optimizing output asm code. Probably better then 99% of programmers who would try to replace them with a manually written asm/machine code. If one writes a elegant, properly structured program in a higher-level language such as C or JAVA, one will have a responsive program... Simple as that. No need to use asm today.

Tell me, when the assembly programmers have finished with you, where do you want me to send the flowers?

There are plenty of instances where being able to use asm is not only handy, but very necessary. Many small industrial micro controllers for instance.

[WolfToTheMoon]

Tell me, when the assembly programmers have finished with you, where do you want me to send the flowers?

There are plenty of instances where being able to use asm is not only handy, but very necessary. Many small industrial micro controllers for instance.

I haven't said I'd get rid of them completely nor have I mentioned microcontrollers... Just that it is not needed to code a OS or applications 100% in assembler.

[Iggy]

There is no longer any connection between Genesi and MorphOS.  They are two totally seperate things.
 
No support either way any more as far as I know

No recent support, but a valued former partner.

From :MorphZone:
http://bounties.morphzone.org/

"Highest Donations...Genesi...Site Maintenance..."

[WolfToTheMoon]

These would be great to run MorphOS on...

[the_leander]

I haven't said I'd get rid of them completely

No you stated that it was completely irrelevant due to today's computing power.

Just that it is not needed to code a OS or applications 100% in assembler.

I don't think anyone said it is necessary, only that it is an interesting project to see just what it can be made to do as far as choice of computing language, as Karlos has said many times, pick the right language for the right job.

The reason you got the response you did was because what you wrote read like an excuse to code poorly as well as a complete blanket dismissal of asm.

[TheBilgeRat]

Just because you see no value in the optimization of code for an application doesn't mean the rest of the world shares your view.  In other words, Wolf, I do not share in your ignorance and frankly am shocked by it.  I will chalk it up to either a poor upbringing or youth.

[TheBilgeRat]

The reason you got the response you did was because what you wrote read like an excuse to code poorly as well as a complete blanket dismissal of asm.

This.

[runequester]

Crap code is the refuge of corporations with customer bases willing to pay repeatedly for deteriorating performance and non-existing feature improvements.

[WolfToTheMoon]

Just because you see no value in the optimization of code for an application doesn't mean the rest of the world shares your view..

I never said that...

In other words, Wolf, I do not share in your ignorance and frankly am shocked by it

I'm shocked you would consider writing an entire OS or any application in asm as a guarantee of better performance or more optimized code. I also doubt many programmers could manually write more optimized code then today's compilers. And ultimatively, spending resources of doing so is questionable in most applications(while I agree it's mandatory in some others).

I never said I'm anti-asm in general.

[takemehomegrandma]

There is no longer any connection between Genesi and MorphOS.  They are two totally seperate things.
 
No support either way any more as far as I know

Even though Genesi indeed has nothing to do with MorphOS development past v1.4 (2004?), I believe Genesi's stance (from the past) is that they own MorphOS 1.4 in full. But when they stopped paying for MorphOS development, they said something in the lines of "Go ahead and continue developing MorphOS in any way you like, release it for any platform you like (even for AmigaOne(! Shock! Horror! ))" etc.

That has pretty much been the connection since then. Genesi has a silent claim for MorphOS 1.4, while the MorphOS Team freely went on far beyond that, the entire relevant Mac PPC platform has almost entirely been conquered, and MorphOS 2.7 has come a long way since then! At one point (as a prequel to the 5121e/"LimePC" development), Genesi paid for a port to Efika PPC, and that's why the Efika has been a supported platform sine MorphOS 2.0.

From Genesi's Point of View, I have no clue to whether MorphOS could play *any practical role whatsoever* in a Genesi future on ARM today? Probably not! Genesi has Linux/Android/ChromiumOS/Whatever, as well as all the relevant applications and "real" standards, official Flash support, etc, etc.

AFAIK, MorphOS is today being developed entirely on a hobby basis. On PPC only, for practical reasons mostly I guess.

But if the MorphOS Team would expand their ambitions regarding CPU architecture, I actually *do* think that Genesi and bPlan (and *Freescale* through them) would *actively assist* them in many ways! Through documentation, knowledge, experience, etc. Through early development hardware? Etc...

In *that* sense, I believe that the connection that still exists would be beneficial!

Otherwise I think it's just as you say JJ, "There is no longer any connection between Genesi and MorphOS"

[commodorejohn]

Crap code is the refuge of corporations with customer bases willing to pay repeatedly for deteriorating performance and non-existing feature improvements.

This.