English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 10 May 2020, 18:22   #401
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 42
Posts: 2,149
Quote:
Originally Posted by kamelito View Post
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.
gulliver is offline  
Old 10 May 2020, 19:10   #402
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 460
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.
Thomas Richter is offline  
Old 10 May 2020, 19:56   #403
kamelito
Zone Friend
kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,164
That is fine. Once released I’ll buy it.
kamelito is offline  
Old 11 May 2020, 14:05   #404
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 335
Quote:
Originally Posted by kamelito View Post
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.
Bruce Abbott is online now  
Old 11 May 2020, 14:50   #405
kamelito
Zone Friend
kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,164
@Thor
Maybe if you optimize things for The Vampire, AMMX for instance you’ll be able to reach new customers...
kamelito is offline  
Old 11 May 2020, 15:21   #406
hUMUNGUs
Registered User

hUMUNGUs's Avatar
 
Join Date: Apr 2016
Location: .no
Posts: 73
Quote:
Originally Posted by kamelito View Post
@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 !!
hUMUNGUs is offline  
Old 11 May 2020, 18:26   #407
Minuous
Coder/webmaster/gamer
Minuous's Avatar
 
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,102
Quote:
Originally Posted by Bruce Abbott View Post
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.
Minuous is offline  
Old 12 May 2020, 04:33   #408
PurpleMelbourne
Registered User

 
Join Date: Dec 2018
Location: Melbourne / Australia
Posts: 71
Quote:
Originally Posted by Daedalus View Post
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?
PurpleMelbourne is offline  
Old 12 May 2020, 07:43   #409
britelite
Registered User
 
Join Date: Feb 2010
Location: Espoo / Finland
Posts: 713
Quote:
Originally Posted by kamelito View Post
@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?
britelite is online now  
Old 12 May 2020, 07:52   #410
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,499
I concur that the Vampire is more than fast enough to run Amiga OS. No need to put man hours into that.
Steril707 is online now  
Old 12 May 2020, 07:52   #411
AC/DC HACKER!
Registered User

AC/DC HACKER!'s Avatar
 
Join Date: Aug 2016
Location: SCC-NAC-dC-iNT
Posts: 623
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.
AC/DC HACKER! is offline  
Old 12 May 2020, 09:52   #412
Steril707
Tigerskunk!

Steril707's Avatar
 
Join Date: Sep 2016
Location: Amiga Island
Posts: 1,499
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.
Steril707 is online now  
Old 12 May 2020, 11:58   #413
PurpleMelbourne
Registered User

 
Join Date: Dec 2018
Location: Melbourne / Australia
Posts: 71
Quote:
Originally Posted by Steril707 View Post
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.
PurpleMelbourne is offline  
Old 12 May 2020, 13:04   #414
amigo1
Registered User

 
Join Date: Nov 2016
Location: Cork/Gallia
Posts: 21
Quote:
Originally Posted by PurpleMelbourne View Post
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.
amigo1 is offline  
Old 12 May 2020, 13:26   #415
OlafSch
Registered User
 
Join Date: Nov 2011
Location: Nuernberg
Posts: 578
Quote:
Originally Posted by PurpleMelbourne View Post
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?
OlafSch is offline  
Old 12 May 2020, 13:28   #416
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 460
Quote:
Originally Posted by amigo1 View Post
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.
Thomas Richter is offline  
Old 12 May 2020, 15:24   #417
Fastdruid
Registered User
 
Join Date: Apr 2020
Location: UK
Posts: 144
Quote:
Originally Posted by OlafSch View Post
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.
Fastdruid is offline  
Old 12 May 2020, 15:48   #418
Gorf
Registered User

 
Join Date: May 2017
Location: Munich/Bavaria
Posts: 1,144
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.
Gorf is offline  
Old 12 May 2020, 17:37   #419
Fastdruid
Registered User
 
Join Date: Apr 2020
Location: UK
Posts: 144
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.
Fastdruid is offline  
Old 12 May 2020, 18:19   #420
OlafSch
Registered User
 
Join Date: Nov 2011
Location: Nuernberg
Posts: 578
Quote:
Originally Posted by Gorf View Post
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.

Last edited by OlafSch; 12 May 2020 at 18:26.
OlafSch is offline  
 


Currently Active Users Viewing This Thread: 5 (2 members and 3 guests)
DavidQ, Bruce Abbott
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
AmigaOS 3.1.x v 3.9 steve_mynott New to Emulation or Amiga scene 35 19 April 2020 06:23
AmigaOS 3.9 PoLoMoTo support.WinUAE 8 27 August 2011 18:06
AmigaOS 3.5 or 3.9 maddoc666 support.Apps 12 22 February 2010 08:02
AmigaOS koncool request.Apps 6 04 June 2003 17:45
AmigaOS XL sturme New to Emulation or Amiga scene 4 15 January 2002 02:13

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.11195 seconds with 16 queries