I only rarely reach limits with MorphOS as it is now. But recently I use google adwords quite a bit. And while it is nice that it generally works with Oddyssey, this tool is a real memory hog. On my 1 GiB Mac mini all memory gets occupied quite fast, on the Powerbook with 1.5 GiB it's a bit more relexed, but even that much RAM sees an end there. While it's okay to work with (with an eye on the memory module on screen bar) it would be nice to have a machine that sports more RAM. 64 bit machines with supported 64 bit address space would be cool. I know it's not possible with current approach. But it's one of the situations which show that a switch to "MorphOS NG" would be quite an enabler.

> 64 bit machines with supported 64 bit address space would be cool. [...] it's one of
> the situations which show that a switch to "MorphOS NG" would be quite an enabler.

One step towards this would be to turn MorphOS into a real 32-bit OS which can address 4 GiB RAM. This would give up to 2 GiB usable RAM on G4 (and below) and up to 3 GiB usable RAM on G5.

A memory request flag that indicates the application won't shoot itself in the head if it gets 'negative' memory address?

With 4GB in my G5, Andreas' suggestion would be welcome.

If you have to apply for special "unsigned RAM" anyways why not go the whole way and insist that any app doing so must expect a 64Bit address....

Quote:

Well, there is the small problem that most MorphOS systems are still 32 bit...

It's so sad to think about fixing bad coding habits with just adding more memory. In better world we could affect to webkit authors to learn to be better coders and stop wasting the memory for nothing :)

But why not make in Odyssey http://en.wikipedia.org/wiki/Virtual_memory on Disk?

Quote:

Its been brought up before, but there does not seem to be much support for it.
That is a pity as I will have a spare 3GB doing nothing (up to 7GB if upgraded).

Andreas_Wolf,
Quote:

I guess most parts of MorphOS are already 32Bit. The Problem ist that this will cause massive incompatiblity with 3rd party Software and 68K stuff.

It is better to perform a clean cut, dump all the old crap required to be backward compatible and add virtual memory, 64bit support, multi processor support and all this stuff at once, to only break system compatility once, instead of doing this over and over to add new features.

Geit

Quote:

That could be done with the G5 right now.
Or a X2000 (if that is what A-eon will call them).

Doesn't even require an platform change.
And I still don't see why a 31 bit mode could not be boxed in.

geit,
Quote:



b1905_ORIG-benStillerDoIt.jpg

Quote:

AFAIK the SoC used there is only 32Bit !!
Not sure wether thats only for the external bus (limiting it 4GB RAM - IO) or also internally.

Quote:

/me puts his money on "manpower" with a sidebet on "motivation"

Nope, the e5500 core is 64 bit as is the G5, so we are already there!
Like Ben Stiller said, DO IT!

>>And I still don't see why a 31 bit mode could not be boxed in.

>me puts his money on "manpower" with a sidebet on "motivation"

It would require a lot of work.

Then again, you guys do a lot with a limited base of developers.

Isn't the 64 bit move far more complicated?

Quote:

Yeah, so it is 64Bit, but the lack of Altivec will surely hurt in day2day performance.

"a move to 64bit" would pretty much mean a new OS that might or might not carry over some ideas from the old ones.

A special 32Bit or "upper-memory" mode is little more than a hack allowing apps developed for it to break some boundaries.

In a way one could look at like the very early GFX-cards that had some limited drivers/plugins that allowed a select number of apps to go truecolor/highres with just that 1 type of GFX-card vs. a fully intregrated cgx/gfx solution that allowed all (cleanly written) apps to use all features of all cards without having special code built in ....

I am not convinced that the lack of AltiVec is that important.
It still has an FPU and a fairly adequate one.
AltiVec will come with later revisions of the core.

Frankly, I like the e6500 core better, but both are pretty good.
Lightyears better than AMCC`s offerings.

What we could use, is something that costs less.
A T1022 or T1042 based board would be nice.
Faster than Acube`s hardware, less expensive than A-eon.
Then again, we already have the G5, faster, cheaper, readily available.
So its not like we need improvement in our hardware options.

Kronos wrote:
Yeah, so it is 64Bit, but the lack of Altivec will surely hurt in day2day performance.

"a move to 64bit" would pretty much mean a new OS that might or might not carry over some ideas from the old ones.

A special 32Bit or "upper-memory" mode is little more than a hack allowing apps developed for it to break some boundaries.

In a way one could look at like the very early GFX-cards that had some limited drivers/plugins that allowed a select number of apps to go truecolor/highres with just that 1 type of GFX-card vs. a fully intregrated cgx/gfx solution that allowed all (cleanly written) apps to use all features of all cards without having special code built in ....



[ Edited by ASiegel 01.01.2014 - 20:28 ]

> AltiVec will come with later revisions of the core.

AltiVec in an e5500 core? What's the source of that info? The only info on newer e5500 revisions I found was mention of the e5500-lp (page 10 of PDF file) and the e5501 (page 12/13 of PDF file, page 23/28 of PDF file, page 33/34 of PDF file), which are obviously different names for the 28nm e5500 variant inside the QorIQ T1. Nothing about AltiVec there.


Edit: I notice that you claimed the same thing there:
http://www.amiga.org/forums/showpost.php?p=755178
http://www.amiga.org/forums/showpost.php?p=757201

[ Edited by Andreas_Wolf 29.10.2014 - 11:44 ]

>> a X2000 (if that is what A-eon will call them).

> AFAIK the SoC used there is only 32Bit !!

A-Eon announced to use 3 different SoCs, two of which are 64-bit (e5500 core) and one is 32-bit (e500mc core).

> why not make in Odyssey http://en.wikipedia.org/wiki/Virtual_memory on Disk?

With current MorphOS this would only make sense on machines where the physically installable RAM is less than 1.5 GiB. The solutions described in the Wikipedia article don't help with addressing limitations.

>> why not make in Odyssey http://en.wikipedia.org/wiki/Virtual_memory on Disk?

> there does not seem to be much support for it. That is a pity as I will have a spare
> 3GB doing nothing (up to 7GB if upgraded).

The solutions described in the Wikipedia article wouldn't be able to change that (see my previous posting).

To reply to the initial post:
64 bit or swap memory is certainly not the right answer to webkit being a memory pig and not giving everything back when you close a browser tab (which is the real issue)...
Most (all ?) phones and tablets use 32bit CPUs and are working around all this.

> Most (all ?) phones and tablets use 32bit CPUs

Yes, most. You may have heard of the iPhone 5S, the iPad Air and the iPad mini 2 ;-) And there are about 200 different tablet models using x86-64 CPUs currently on the market.

We will se a heck load of 64bits phones and tablets in 2014. Iphone5 and ipad air might be first, but many coming soon. Not to forget the ARM cortex a57... Anyone know if they will be in any mobile hardware during the bew year?

> Not to forget the ARM cortex a57... Anyone know if they will be in any mobile hardware
> during the bew year?

I'm not sure about the Cortex-A57, but the Cortex-A53 has already been announced to be used in a chip for mobile hardware:

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=3&topic_id=9647&start=37 (2nd link)

Yes, use of the A-53 in mobile hardware should occur shortly.
Manufacturers were testing those devices before the New Year.

And while it offers more power than needed (like that has ever stopped sellers), the A-57 is a likely candidate for mobile devices.

What I want is an ARM board with some PCI-E expansion slots.
A-57, A-15, I'm not sure I care, I just want industry stsandard expansion.