64-bits With 32-bit Compatibility Layer? | |
---|
|
---|
| | Samuel Crow
Posts 424 01 Feb 2023 21:47
| I'm writing this to illustrate what would be necessary to have a 32-bit ApolloOS layer on top of a 64-bit operating system. Be warned: it won't be cheap and will be a lot of work. Given these facts, it's very understandable why few people would want to follow this path. The 64-bit underlying operating system will be incompatible with ApolloOS unless the 32-bit compatibility layer is developed separately as a compatibility shim. That being the case, breaking from the traditions of the past could bring an advantage or two. 1. AmigaOS cannot use full SMP without breaking compatibility anyway. The scheduler was documented as blocking lower-priority tasks. This means no multicore 68090 without a second layer of OS. 2. AROS can only be 64-bit capable at a source-code compatible level. Binaries made from earlier years cannot be transparently made 64-bit. Message passing is done by absolute address on both AmigaOS and ApolloOS, for example. Another example is jump table entries on shared libraries. What the competition has done: Windows 32-bit executables are run using a compatibility shim called WoW (Windows on Windows). 64-bit Windows executables are a totally different file format. Mac used "fat binaries" where multiple formats are included in a single bloataed executable format. Linux disavows 32-bit compatibility unless all the supporting libraries are also 32-bit. Ugh! MorphOS uses a JIT compiler for each formerly native executable format on a compatibility breaking Q-box for the x86-64 Quark Microkernel gaining both SMP and 64-bit in one step. 64-bit x86 retains no knowledge of 32-bit x86 nor is PPC64 ever supported. AmigaOS 4.x is trying to splice in nonsymmetric multiprocessing but no hope of 64 bit addressing. AROS x86-64 is not backwardly compatible to 32-bit x86 AROS binaries at all. Since compatibility is already broken, why not add in SMP? Sure! Now that you see how much effort migrating to 64-bit operating systems is, is anyone willing to put forth the effort of making it happen?
| |
| | Eric Gus
Posts 479 02 Feb 2023 05:11
| Its a nice idea but at the end of the day I would rather have the effort put into ApolloOS to bring it up to par with current Amiga OS 3.x fully 100% so much so that we can leave classic Amiga OS behind forever without even batting an eye... Maybe .. if / when we get that fully compatible at all levels, and we can finally walk away from ever needing classic Amiga OS and use ApolloOS 100% without any need to ever go back, we can think about this .. but I also ask do we need 64 bit right now? what/who will take advantage of it? It's certainly a lot of work and effort for what gain, and we risk breaking existing 32bit compatibility or causing new bugs/problems in the process with backwards compatibility? Lets face it, "new" software that could utilize this would be even more rare, right now the higher-level development tools are not there, (we need more than just ASM dev tool chains). The pool of folks who are qualified to do this is exceptionally small and IMHO their time is better spent working on getting what we have now refined and polished and on a par with classic Amiga OS 3.x so we can free ourselves from the mess that perpetually plagues the Amiga community with the never ending legal squabbling, fighting, lawsuits and picking over the dead corpse of whats left of Commodore's IP .. Not that I would stop anyone from doing this but I don't know what the payoff would be putting this effort it at this specific point in time (note im not saying its a bad idea, im just saying its a bit early to be thinking about this with the work still to do) .. Maybe we shelve the idea and revisit it when ApolloOS is more refined and polished. Its valid, I just think its a bit premature. Having a fully 100% compatible to classic AmigaOS, ApolloOS would be a great starting foundation to build this idea on, but we need to get there first.. and that will take some time and focused effort.
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6262 02 Feb 2023 08:51
| Samuel Crow wrote:
| I'm writing this to illustrate what would be necessary to have a 32-bit ApolloOS layer on top of a 64-bit operating system.
|
Amiga is on the market since 37 years. In this 37 years Amiga System now use up to 512 MB Memory. Many systems use less. Most Amigas need less than 1% of the address space. The Vampire with 128MB use 3% of the available address space. Our biggest systems with 512 MB memory use 12.5% of the address space possible with 32bit pointers. How long will us the still available 88% unused space last? Another 250 years? Or maybe only 60 more years ? Whatever time it is, I personally think there is absolutely no urgency to that we run out of space anytime soon. We are focused on improving the current software situation: We work on improve Amiga OS compatibility. A goal here is make sure that WB 3 can run perfectly with our ApolloRom. We improve Drivers, we improve performance of the existing GFX routines. We are working on 3D driver for the Amiga Maggie 3D acceleration. We are working on new audio applications and new games. In my opinion the current 32bit addresses is optimal. Current 32bit addresses keep program slimmer and faster - and maintain 100% compatibility. I think that the amount of memory is to Amiga software no limitation. If you want to develop software for Amiga, then you can get our support. If you want to improve existing Software for Amiga, then you can also get our support. Changing Amiga OS to 64bit addresses is in our opinion not reasonable now.
| |
| | Carles Bernat Martorell
Posts 22 02 Feb 2023 11:40
| I also fail to see which advantadge would provide 64 bit addressing to me as a Vampire user. I've got 128mb of RAM and i've never used even the half of it. It's not like Vampire is powerful enough to run those stupid unoptimized web browsers anyway.
| |
| | Samuel Crow
Posts 424 02 Feb 2023 12:40
| Carles Bernat Martorell wrote:
| I also fail to see which advantadge would provide 64 bit addressing to me as a Vampire user. I've got 128mb of RAM and i've never used even the half of it. It's not like Vampire is powerful enough to run those stupid unoptimized web browsers anyway.
|
Agreed. Browsers are needlessly bloated and 100 MHz isn't enough to run them.I should have made my last statement clear: nobody should go to that level of effort just to "keep up with the Joneses". Also, SMP and multicore CPUs can't fit on an FPGA cheaply.
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6262 02 Feb 2023 12:54
| Samuel Crow wrote:
| Also, SMP and multicore CPUs can't fit on an FPGA cheaply.
|
Lets not forget, SMP coding adds another level of complexity. IBM had to give intensive support even to professional companies like SAP to get SMP run stable and bug free on Power. I'm big fan of the home coder scene on Amiga. Not having to deal with the pitfalls of SMP coding on Amiga is frankly a major advantage today.
| |
| | Samuel Crow
Posts 424 02 Feb 2023 13:20
| eric gus wrote:
| Lets face it, "new" software that could utilize this would be even more rare, right now the higher-level development tools are not there, (we need more than just ASM dev tool chains). |
Agreed. I have an AmigaE toolchain on GitHub that could help. It currently supports 68020 and PPC on MorphOS and AmigaOS 4.Also, Bartman's GCC12 port needs runtime support. If that could be brought up to a level to compile AROS, we'd be in better shape for ApolloOS also.
eric gus wrote:
| Not that I would stop anyone from doing this but I don't know what the payoff would be putting this effort it at this specific point in time (note im not saying its a bad idea, im just saying its a bit early to be thinking about this with the work still to do) .. Maybe we shelve the idea and revisit it when ApolloOS is more refined and polished. Its valid, I just think its a bit premature. Having a fully 100% compatible to classic AmigaOS, ApolloOS would be a great starting foundation to build this idea on, but we need to get there first.. and that will take some time and focused effort.
|
I agree to a point. Classic AmigaOS is built on the same crumbling foundation as AmigaOS 4. It will eventually run out of gusto.I've pretty much moved on from AmigaOS. Haiku is my new foundation and the operating system by itself needs 128 MB of RAM. Most of that is for MMU page tables but SMP is definitely there. Would refitting Haiku to run using an Apollo-style memory protection unit be practical for a first-tier of operating system? It's written mostly in C++. One Haiku developer tried compiling Haiku on an A4000 with 128 megs but didn't make it very far. So far there is little interest in running Haiku on a single-threaded system.
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6262 02 Feb 2023 13:25
| Samuel Crow wrote:
| Bartman's GCC12 port needs runtime support. If that could be brought up to a level to compile AROS, we'd be in better shape for ApolloOS also.
|
Why would we be in a better shape? Is the 68K code generation of it better than GCC 6.5?
| |
| | Samuel Crow
Posts 424 02 Feb 2023 13:49
| Gunnar von Boehn wrote:
|
Samuel Crow wrote:
| Bartman's GCC12 port needs runtime support. If that could be brought up to a level to compile AROS, we'd be in better shape for ApolloOS also. |
Why would we be in a better shape? Is the 68K code generation of it better than GCC 6.5?
|
I'm glad you asked! The reason for moving on from 6.5 is more related to modularity. LibGCCJIT became stable in GCC 11 or so. Don't let the name fool you though, it generates static as well as dynamic code. It still has some warts left over from 68k Linux, but the underpinnings are solid. It is designed to run from a library (shared object) using a common API.
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6262 02 Feb 2023 14:57
| Samuel Crow wrote:
|
Gunnar von Boehn wrote:
| Samuel Crow wrote:
| Bartman's GCC12 port needs runtime support. If that could be brought up to a level to compile AROS, we'd be in better shape for ApolloOS also. |
Why would we be in a better shape? Is the 68K code generation of it better than GCC 6.5? |
I'm glad you asked |
Yes. But did you review the 68K Assembler code generation? Is GCC 12 producing better or worse code? In the end the quality of the generated code is also very important. It happened before that higher number GCC did in fact produce less good 68k code - so it makes sense to verify this. Did you do this by chance?
| |
| | Samuel Crow
Posts 424 02 Feb 2023 16:35
| It varies from one program to the next. Sometimes GCC12 is much faster, sometimes 3% slower than GCC6.5. The link-time optimizer definitely needs work according to Bartman. Bebbo is looking to modernize his 68k pass for current GCC and would likely entertain more work on it for donations.
| |
|