AmigaOS 3.2 and beyond

[gulliver]

Originally Posted by kamelito

Since there is C in the OS why not compile each C parts for every CPU? I guess it would be a nightmare to test thought.

There are many issues, but you named the most important one, which is testing:

You need to have a consistent and cohesive testing base or everything starts to fall apart and then stability becomes compromised.

So, we may perhaps do some selective cpu builds where it is worth, but that would have to happen when we first solve all the open issues we have first.

[Thomas Richter]

IMHO, optimizing for a particular CPU model only makes sense for heavy-duty algorithms, and then you would want to rewrite this in assembly anyhow. Then you also risk that users install the wrong version, which is to be avoided. Thus, there should be only a single file which works for every CPU. One can then still include a CPU-specific dispatcher in its core.

[kamelito]

That is fine. Once released I’ll buy it.

[Bruce Abbott]

Originally Posted by kamelito

Since there is C in the OS why not compile each C parts for every CPU? I guess it would be a nightmare to test thought.

A nightmare yes, but also why do it? It's more important to optimize for the stock 7MHz 68000, less important on a faster CPU. And most compiler optimizations don't make that much difference anyway.

[kamelito]

@Thor
Maybe if you optimize things for The Vampire, AMMX for instance you’ll be able to reach new customers...

[hUMUNGUs]

Originally Posted by kamelito

@Thor
Maybe if you optimize things for The Vampire, AMMX for instance you’ll be able to reach new customers...

Thumbs up for Vampire optimization !!

[Minuous]

Originally Posted by Bruce Abbott

It's more important to optimize for the stock 7MHz 68000, less important on a faster CPU.

7MHz is going to be slow no matter what you do. Better to optimize for a more modern CPU. Users with 32-bit CPUs like the 68020 do not want to run 16-bit operating systems. Most upgraded their CPU 20 years ago or more when OS3.5 made it a requirement, no sense going backwards now.

[PurpleMelbourne]

Originally Posted by Daedalus

Part of the problem there is that there's also no way of an uninstaller knowing if any installed common components (e.g. in LIBS: or C: ) are required by any other program. So, you install program A that needs random.library in LIBS:. Then you install program B that also uses random.library, but didn't install it as there was already a copy in LIBS:. Then you uninstall program A, which put random.library in place and so removes it again. Program B stops working, maybe even crashes, and you're left scratching your head about what changed.

How about :
Uninstaller LINKs random.library to LIBS_OLD: with an single-use LINK that is destroyed if file is accessed from LIBS: as a first step towards cleanup-deletion, but waiting for an "empty rubbish" to take place to delete it with the LINK. The "empty rubbish" could be set to varying lengths of time, like don't delete unless LIBS_OLD:random.library has not yet gone 90 days without use.

Could this be done without significantly slowing down the system?

[britelite]

Originally Posted by kamelito

@Thor
Maybe if you optimize things for The Vampire, AMMX for instance you’ll be able to reach new customers...

But isn't the Vampire the most awesome and fastest thing ever, surely the OS components won't need to be optimized for it?

[Tigerskunk]

I concur that the Vampire is more than fast enough to run Amiga OS. No need to put man hours into that.

[AC/DC HACKER!]

With AmigaOS as it is, you need User Intervention (Pro-Activity). Otherwise you need OS locks of stuff that's in use in some way - to keep from happening what you're describing.

I'm not a fan of all that, but the future of AmigaDOS depends on such things if it's going to really change into a more sold OS. Like others around.
I very much enjoy keeping different version of Libs, and whatever...but generic users are not into keeping track of detailed changes. DOS locks and some kind of Checks that this Lib file belongs to..are going to become required. Unless it remains a tinker and enthusiast OS. What was okay in the 80's and 90's isn't today...if it's to continue to grow.

[Tigerskunk]

For me it would be more in the field of UI and user interaction what I would like to see improved in the future..

3.2 seems to be doing some good steps into the right direction.

[PurpleMelbourne]

Originally Posted by Steril707

I concur that the Vampire is more than fast enough to run Amiga OS. No need to put man hours into that.

Maybe version 3.4 would be the time for it

3.2 important bug fixing foundations
3.3 more important remaining foundation stuff (CyberGFX by then...)
3.4 moving forward with advancements, like 060 superscalar, aMMX, SMP, rewrite graphics.library for multiple displays and SAGA.

[amigo1]

Originally Posted by PurpleMelbourne

How about :
Uninstaller LINKs random.library to LIBS_OLD: with an single-use LINK that is destroyed if file is accessed from LIBS: as a first step towards cleanup-deletion, but waiting for an "empty rubbish" to take place to delete it with the LINK. The "empty rubbish" could be set to varying lengths of time, like don't delete unless LIBS_OLD:random.library has not yet gone 90 days without use.

Could this be done without significantly slowing down the system?

Perhaps a simpler solution to this, would be have the needed components in the drawer of the Application itself. A subdir of "Libs" in the "MyFavouriteApplication".

So all Programs are self contained, and you just have to delete the drawer to cleanely delete any left overs.

Of course the software should look into memory if a version of the (in this case library) has already been loaded into memory.


The downside would be have 10.000.000.000 copies of every same library lying around on the Storage medium, but with the 2GiB barrier finally crossed for good thanks to OS3.1.4 I see not problem with it other than one of philosofical nature.

[OlafSch]

Originally Posted by PurpleMelbourne

Maybe version 3.4 would be the time for it

3.2 important bug fixing foundations
3.3 more important remaining foundation stuff (CyberGFX by then...)
3.4 moving forward with advancements, like 060 superscalar, aMMX, SMP, rewrite graphics.library for multiple displays and SAGA.

I do not share all views from Thomas but he clearly stated that 3.1.4 (and certainly 3.2 too) are for unifiying the old base by unifying as much as possible from 3.1/3.5/3.9 and the countless patches in one stable platform

It is not about developing a new platform with more advanced hardware specific features and adding third party software like CybergraphX or P96

SMP on 68k? For what hardware?

[Thomas Richter]

Originally Posted by amigo1

Perhaps a simpler solution to this, would be have the needed components in the drawer of the Application itself. A subdir of "Libs" in the "MyFavouriteApplication".

Surprise, surprise. You can already do that right now. Actually, since Os 2.0. The libraries go into PROGDIR: and are found there.


The problem is *not* the operating system, but developers. There is no need to clutter LIBS: with private libraries, or S:User-Startup with assigns.



BTW, if you want to include PROGDIR:Libs as well: BetterOpenLibs exists, and is in Aminet. Its functionality is not included in 3.1.4 since it changes the behaviour of ramlib.

[Fastdruid]

Originally Posted by OlafSch

SMP on 68k? For what hardware?

I can envisage some potential ways of getting hardware but can't see a use case other than playing and even if you did I don't see much point in it tbh.

Willy waving at "look at my 4 CPU A500" kind of thing (which I grant you I *would* be impressed with!)

There is no point in spending developer time on it now. It would have been fantastic if the functionality/ability was there in '85 and we'd had the hardware over the years but utterly pointless now for 99.99% of the potential buyers of 3.2.

Leave SMP to AmigaOS4.x/MorphOS/AROS with newer multi-core CPU's.

[Gorf]

There are several FPGA-based accelerators on the way besides the Vampire and there are of course the minimig-core and FPGA-arcade ... it would be no far fetch to put more than just one 68k-core onto them.

the Apollo core already supports SMT...

So SMP on 68K-AROS and on AS3.x would make sense.

[Fastdruid]

Even with an FPGA based accelerator I don't see it. You're better off emulating a faster 68020 or '030/'040 than you are spreading into more cores. Although I grant if you have the ALU spare that just spinning up a second core would be easier.

I see AmigaOS 3.x as the legacy OS, yes it should get new features and updates but not at the extent of breaking everything that came before it. SMP is a problem that has proved tricky on AmigaOS4 with true multi-cored processors let alone on AmigaOS3 with kludged virtual ones while trying to retain compatibility.

https://blog.hyperion-entertainment....nt-and-future/

Finally, it's questionable on 68k if there would be any real performance improvement.

So it would be right at the very very bottom of any list I'd want the devs to spend time on.

[OlafSch]

Originally Posted by Gorf

There are several FPGA-based accelerators on the way besides the Vampire and there are of course the minimig-core and FPGA-arcade ... it would be no far fetch to put more than just one 68k-core onto them.

the Apollo core already supports SMT...

So SMP on 68K-AROS and on AS3.x would make sense.

on aros smp support was added only at X64 platform. At the moment it is more important that as much software as possible works on aros 68k and that current hardware is supported and parts of aros are optimized. Even that is a demanding task. At the moment I do neither see the need nor the development resources for adding something like smp.