@all

German

English

Obvious note to followers of Amiganews: The German version is always more likely to contain comments, unlike the English version.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

Great interview thank you David.

Very nice interview! I’m glad the V4 was brought up.

_________________
Sent from my Quantum Computer.

Quote:

I’m glad the V4 was brought up.

Itz would be nice if more of the changes in ApolloOS could be ported back to AROS 68k. AROS has RTG, a working TCP/IP Stack and is far more advanced than AOS 3.x.

Last edited by OneTimer1 on 05-Apr-2024 at 07:32 AM.

@OneTimer1

It already happened in the past and will hopefully in future. But there are basic differences between apolloos and aros 68k on main branch so not everything can be used

David Brunet Quote:

What about the legality of AmigaOS 3.2+? You're currently working for Hyperion, but would you agree to continue development under the Amiga Corporation umbrella?

Does David have more inside knowledge of the Amiga situation than Camilla? Does he have foresight of things to come?

Camilla Boemann Quote:

So the court has ruled that Hyperion has the rights to develop and release AmigaOS. The name of the company is not that important to me, but from how I read it the ruling is quite firm. Right now, the autonomy, and no one bossing us around is what is most attractive for us developers. I am very thankful to Hyperion and I firmly believe it is the only setup that will allow AmigaOS to live on.

The court ruling is firm based on what looks like a coerced contract of a business under financial duress. Is it not as obviously illegal as creating a new Ben Hermans BV and transferring the stock to it before the old Ben Hermans BV is declared insolvent only 8 days later? Is morality harder to judge when there is a conflict of interest that benefits personal goals? Perhaps the shell business shenanigan is the mistake that brings AmigaOS "development under the Amiga Corporation umbrella"?

Camilla Boemann Quote:

I know some people really want AmigaOS open-sourced, but while I am a firm believer in open source in general, I am convinced that it will be the death of AmigaOS. The process alone will take many years and cost a lot more money than anyone can dream of. And I'm speaking only in general here, but such a process with a 40+ year old codebase requires a lot of detective work and lawyer work. The real kind that is very expensive. Anyone claiming they can open source such a huge project with a snap of the hand are dead wrong. And in the process AmigaOS will be frozen for maybe 10 years.

AmigaOS open sourcing can't be done in parallel with AmigaOS development? The open source AROS hasn't been the death of AmigaOS. The "AmigaOS" IP could be reserved for the official AmigaOS which I expect would remain popular with quality development. The open source license and copyrights could further limit development of competitors while allowing for personal development changes, contributions and better debugging. It should be possible to gain some of the advantages of open sourcing while retaining control of the official AmigaOS and avoiding Linux flavor, distro and fork hell.

David Brunet Quote:

Are optimised versions of AmigaOS planned for PiStorm32 or Apollo/Vampire 68080 boards?

Camilla Boemann Quote:

Thank you for asking, as I see this wish popping up so often, and I think it is a huge misunderstanding. The main reason those CPUs are faster is because they run faster. Not because you run programs optimised for them. A Ferrari doesn't run any faster if you wear a red t-shirt while sitting inside. Two versions of a program optimised for 68000 and 680030 respectively are not two different programs. Typically, there is maybe 1% difference. The newer CPUs have a few more instructions that come in handy if you do math and a few other things, but very little of AmigaOS do that, so it is utterly pointless. Now optimising for CPU does make sense in some cases. Some games can benefit a lot. JPEG datatype would benefit. Lha too. What these programs have in common is a lot of repetitive calculations.

Code compiled for a 68020 instead of 68000 would only make a 1% performance difference on 68020+? It is more likely 5% or more for the 68020-68040 and likely more for the 68060. Code compiled for a 16 bit scalar CPU when executed on a 32 bit superscalar CPU could easily have 20% reduced performance.

@matthey

For what it's worth I responded to the team:

Here

Please feel free to disagree.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

#6 Quote:

For what it's worth I responded to the team: Here Please feel free to disagree.

The answer is nuanced. Hyperion has a "firm" license to develop and sell the AmigaOS which I don't believe is in dispute although it could be cancelled for violation of the license by challenging ownership or due to an illegal cooerced contract of a business in financial duress. It is the scope of the license that is in dispute and far from being "firm". I don't blame Camilla for spreading Hyperion propaganda as she may be the victim of it too. Ben's comment to you was rich with the current Ben Herman's BV shell games though.

https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=25979&forum=2&start=100&viewmode=flat&order=0#861202 Quote:

Hyperion dropped all of its counterclaims against the Amiga Parties and Cloanto Corp "with prejudice" as there is no merit in litigating against shell companies.

@thread

Well that sheds some decent light on the status quo. Things are more broken at a fundamental level than I had previously thought.

_________________
All the way, with 68k

@matthey

Quote:

Thank you for asking, as I see this wish popping up so often, and I think it is a huge misunderstanding. The main reason those CPUs are faster is because they run faster. Not because you run programs optimised for them. A Ferrari doesn't run any faster if you wear a red t-shirt while sitting inside. Two versions of a program optimised for 68000 and 680030 respectively are not two different programs. Typically, there is maybe 1% difference. The newer CPUs have a few more instructions that come in handy if you do math and a few other things, but very little of AmigaOS do that, so it is utterly pointless. Now optimising for CPU does make sense in some cases. Some games can benefit a lot. JPEG datatype would benefit. Lha too. What these programs have in common is a lot of repetitive calculations.

My personal experience is different that what she says.
In my experience using 020 Code is always good and makes programs always a little faster and little smaller.

And in AMIGA is also also performance critical code.
The IDE driver, or memcopy, there are many parts where a CPU tuned version - can gives significant better results.

Gunnar Quote:

My personal experience is different that what she says. In my experience using 020 Code is always good and makes programs always a little faster and little smaller.

Even emulators may be faster with the 68020 optimizations considering emulation is the 68k AmigaOS development environment.

https://www.patreon.com/posts/not-so-useless-56128275 Quote:

BTW I have found many places in kickstart which were sign-extending 8 bit value in register into 32 bit using 68000-compatible two opcode operation: EXT.W Dn; EXT.L Dn. Since places were pretty annoying and wasted many unnecessary aarch64 opcodes, I have written small optimisation which merges this two instructions into one available at higher m68k models - EXTB.L which does sign-extension of 8bit directly into 32bit. But this is just a detail ;)

The "EXT.W Dn; EXT.L Dn" to EXTB.L Dn optimization using instruction folding/fusing may be performed in larger 68k FPGA CPU cores like the Apollo core as well. Then there is all the 68020+ hard CPUs and FPGAs that benefit which do not have the optimization. There are many common situations where instruction folding/fusing optimizations are not available like addressing mode index register scaling and long branches. It's nice to continue support of 68000 hardware which needs the most performance help but I expect 90+% of 68k Amiga hardware, FPGA 68k Amiga hardware and emulation being used today, should benefit more than 1% in performance from a 68020 compiled 68k AmigaOS. The code size and memory savings is nice too as most 68k Amigas are small footprint systems.

@matthey

However… 68000 variant are much more available and at higher clock rates than 020 chips. 68000 support was my main motivation for buying OS 3.1.4, so I could finally get Prefs for ASL and Workbench that didn’t rely on H&P 020+ resource.library (most OS 3.9 core components run just fine on 68000, only a few command line tools and Reaction classes strictly required 020+). My original Minimig v1.1 with 49 MHz 68SEC000 runs in circles around most if not all 020 systems.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Also, most FPGA systems have the option of setting what CPU to use, typically 68000 and 68020 - it’s darn annoying when OS stops working just because you changed to 68000 CPU to be compatible with some software you wish to run. Likewise on real 68000 Amiga, to have the OS crash because you have a need to remove 020+ acc board for whatever reason.

IMO, the OS should _always_ be fully functional on 68000, ThoR has demonstrated how software can detect what CPU it’s running on and load code accordingly.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: IMO, the OS should _always_ be fully functional on 68000 ....

100% with you on that & the reasons you mentioned.

Also I can't be the only one who has a basic set up & copies that across to a CF or SD card for use in other Amigas. If everything works on the original setup (especially the OS) on a plain 68000 it will boot & work fine with hardly anything needing changing whatever CPU you have.

Surely having multiple CPU optimised versions creates more work not just in testing but in choosing what part of the code its worth optimising. This then slows the whole proceeds of OS development down & could lead to disagreement within the team.

There would then be a temptation to introduce advanced features for 020+ leading to versions with different & incompatible features. All for the sake of a few % speed boost for code that already runs fine on a plain 68000 let alone a 060 or 080!

_________________
A1200+Mediator+Voodoo3+040+130mbRAM+0S3.9
A2000+Supra28mhz+9mbRAM+OS3.2.2, CD32 & WinUAE

@Tpod

Quote:

Surely having multiple CPU optimised versions creates more work not just in testing but in choosing what part of the code its worth optimising. This then slows the whole proceeds of OS development down & could lead to disagreement within the team.

The fact is that Commodore ALWAYS made special versions of the Kicksart.
The Kickstart of the A3000 was tailored only for the A3000.
There was a ROM for A1200 and a Rom for A4000 - and so on.

Making special version for each model was the norm.

@Gunnar

Only when strictly necessary, typically due to disk controllers. All 68000 systems use same kickstart.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

To compile for 68000 or 68020 is the question of where your target is

3.14 and 3.2 exist in a time when plenty 68000s are of the fake kind and is looking backwards (aka 100% retro).

3.5/3.9 were done to run on real Amigas trying to stay relevant against Win/MacOS.

The min requirements were already far to low for that goal.

Stuff like the 68SEC00 made no sense back then as the cost of getting one to realy run at 50MHz (including RAM) would have been the same or more as getting a 030 to 25MHz, hence noone really pushed that far, and the fast 68000 that did exist were pretty slow outside Sysinfo.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@number6

Nice interview. Sadly, none of OS 3.2 sales goes to developers, which is kind of sad and unethical, even people opted for it.
Maybe more direct donation system should be established. I dislike all profit sadly go to Hyperion, just because once they got rights to use OS 3.1 sources to do PPC port. But it is as it is.

On optimization, 00 compatibility make sense for product targetting A500 and A600/1500 Plus and A2000.

But even in Amigaworld 020 optimizations make sense. Even in FPGA world, 020 should be at least new baseline.

It would be best if optimized ports existed (I understand compilers can nowadays autocreate it?)
even as seperate product.

As example, I am sure V2/V4 customer base is big enough to sell 080 AMMX port of OS 3.2, if produced. So its missed opportunity, in a way.

Surely, optimizations make sense, as ApolloOS shows compared to plain AROS/OS 3.1

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

kolla Quote:

However… 68000 variant are much more available and at higher clock rates than 020 chips. 68000 support was my main motivation for buying OS 3.1.4, so I could finally get Prefs for ASL and Workbench that didn’t rely on H&P 020+ resource.library (most OS 3.9 core components run just fine on 68000, only a few command line tools and Reaction classes strictly required 020+). My original Minimig v1.1 with 49 MHz 68SEC000 runs in circles around most if not all 020 systems.

I understand. Some people need 68000 compiled code as 68020 code will not work on 68000 Amigas. Using 16 bit 68000 code on 32 bit 68020 Amigas is far from optimal likely resulting in more than 1% performance difference in most cases and more for superscalar 68k CPU cores. Most 68k Amiga users would benefit from 68020 compiled code.

Performance improvement:
68020-68060 Amigas
68020+ FPGA cores
emulation of 68k code

Needs 68000 code:
68000 Amigas
68000 only FPGA cores

A 68020 core has a significant performance advantage when using...

addressing mode scaled index registers
larger datatype hardware MUL/DIV instructions than the 68000 supports
long branches (no more trampoline branch tables)
extb.l (significantly faster for 32 bit sign extension with 32 bit only result forwarding/bypassing)

It looks like the real Gunnar explained the 68000 code handicap with scaled index addressing mode which affected the CoreMark benchmark.

https://www.atari-forum.com/viewtopic.php?p=461622&sid=f4b56cc78061ad9b6e162d903e4cd8bf#p461622 Quote:

Yes I can see this point. At the same - maybe we should consider that CoreMark works with focus on matrix in memory. Perfectly for this is the 68K EA mode (An,Dn*scale) The 68000 CPU does not support the scale feature. The 68000 will need to use a MOVE and LSL or ADD to emulate the Scale. Such extra LSL/ADD will only add more instruction - that reduce the score. This update on the register will also trigger a ALU to EA pipeline stall as explained in the 68060 Motorola CPU manual. Have you considered to make two version, one with 68020+ compile flag?

There is often significantly more than 1% performance difference on more advanced 32 bit superscalar CPU cores like the 68060 and Apollo core. Two versions is a reasonable suggestion.

kolla Quote:

Also, most FPGA systems have the option of setting what CPU to use, typically 68000 and 68020 - it’s darn annoying when OS stops working just because you changed to 68000 CPU to be compatible with some software you wish to run. Likewise on real 68000 Amiga, to have the OS crash because you have a need to remove 020+ acc board for whatever reason. IMO, the OS should _always_ be fully functional on 68000, ThoR has demonstrated how software can detect what CPU it’s running on and load code accordingly.

Plenty of more modern and popular 68k Amiga hardware uses a 68020+ hardware base. I expect most 68k Amiga hardware being used today defaults to using the 68020+ ISA and most new 68k Amiga systems use it as well. The problem is lack of modern affordable high performance 68k hardware so people don't have to use antiquated and primitive 68000 hardware.

Last edited by matthey on 07-Apr-2024 at 06:39 PM.

Well, I have yet to see any real optimization for 68020. Even with the slowest 020 systems around, the speed difference between 68000 code and so called optimized 020+ code seem negligible. So what’s the point? 020+ binaries just create silly incompatibilites and extra work, for extremely little gain.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC