Anche con Google Translate, si capisce poco. :cry:
Is it an AROS project goal to run MorphOS applications under AROS-PPC?I'm about to get involved in some PPC development, and I was wonderingthat that comparability is desired.If so, I will work on making that happen.-- Jason McMullan
Project goal not really. There is a bounty for such a provision. http://www.power2people.org/projects/profile/8However I'm not sure if it's actually desirable. Regards,R.
Previous discussions on the subject have concluded that it isundesirable due to differences in how mos/os4 achieve the same things.My personal opinion is we should be trying to atleast be a bit similarto os4 (since it is the natural progression of the OS we implement) -but again we might not agree with how some things are done there.
Although I think current PPC ABI should also be kept I don't thinkanybody can be stopped to make another 'arch' that is MOS compatible. Iwould then call this arch ppcmos and keep the ppc arch with the currentABI. I am sure this this will break some code that only checks for__powerpc__ and not __amigaos4__ or __morphos__ in their code.There at least two things that will be different. The packing ofstructures. For structs defined by the API of OS3.x libraries MOS andOS4 let these struct be packed in a m68k compatible way (e.g. mostly attwo byte boundaries) and other structs are packed in PPC native way (4bytes for data of 4 bytes long etc.)We even had a solution to implement it in the AROS includes by using#include to enable this packing e.g. something like this:#include <aros/compat_packing_on.h>/* Definition of structs with compat packing */#include <aros/compat_packing_off.h>The contents of these aros/compat_packing_on.h andaros/compat_packing_off.h could then be dependent on arch and compiler.Another thing to fix is the way LVO tables are set up and the stub codeto fake m68k entry of the library functions.To summarize ppc arch would use native packing for all structs and apointer table for the LVOs without special stub code. ppcmos would applyspecial packing to structs that need it and provide the MOS LVO tableconvention for shared libraries.In the end I would like to have then also a ppcos4 arch that would thenbe targeted to be OS4 compatible with their interfaces for sharedlibraries etc.One open source OS to unite them all !!I am not so sure this initiative will be welcomed by either themos-devteam for ppcmos or by Hyperion for ppcos4. They both try to earnsome cash by selling their respective closed source OS.greets,Staf.
A root directory filled with unix-like sobj files that are not reallyshared, without version numbers and confusing users doesn't sound like anatural progression at all. Poor compatibility mixing m68k/PPC componentsdoesn't sound natural progression. Incompatibility with OS legal driversthat did DMA doesn't sound like a natural progression to me. OS4 developershave made a good deal of bad choices IMHO, a lot of hype and promises butbad choices, poor code and bad performance.For me the natural progression is MorphOS: they use the first 64bitfilesystem standard chosen by the community of developers, they made CGX(cloned by both OS4&AROS), they use MUI (the defacto amiga gui standardincluded as standard with os4), they did first 060 boards, they bringed PPCto Amiga... MorphOS is much more amiga-like than os4 is (os4 now is moreunix than amigaos)
IMHO we should not let this evolve into another MOS vs OS4 discussion.With defining two different archs (ppcmos and ppcos4) there is IMO noreason why they can't happily coexist.greets,Staf.
>> However I'm not sure if it's actually desirable.>> Imagine AROS m68k port without m68k comaptibility to see if it makes senseor not. I think it's pretty obvious that development of m68k port hasimproved AROS quite a lot and I think having MorphOS compatibility couldhelp to improve AROS stability and compatibility because more apps could betested. Not just that but it could be quite useful. And in the futureperhaps it could help to run m68k apps natively on PPC too.
I'd personally much rather see PPC AROS hosted on both OS 4 and MorphOS so we could build a compatibility layer for them. They've already gone to the point that they won't easily run each other's software. Also OS4Emu for MorphOS is unmaintained last I checked. We might even beat some of them to the punch if we get Mesa and its Gallium3D drivers working on both systems. The MorphOS team has already said that they won't be porting Gallium3D to their OS.Cheers,Sam
> However I'm not sure if it's actually desirable. Being just the initiator of that bounty and having my money withdrawn meanwhile for other AROS stuff, I obviously can't speak for the other donors, but myself at least I do indeed not see that much benefit in it anymore. The bounty was started many, many years before Apple's change of architecture.But maybe someone would like to ask at amigaworld.net if there's significant interest - given that the OS4 community seems to be basically the only one benefitting from such a possibility.Best wishes,Martin
PS: On a bounty aiming at running MorphOS binaries under AROS/x86 or AROS/x64 instead, I'd definitely donate, though. Everything making it easier for MorphOS developers to switch to AROS once they run out of Apple hardware would be really appreciated by me.
> PS: On a bounty aiming at running MorphOS binaries under AROS/x86 or AROS/x64 instead, I'd definitely donate, though. Everything making it easier for MorphOS developers to switch to AROS once they run out of Apple hardware would be really appreciated by me.>This is kinda my intent. OS4's API (interfaces, etc) is verydifferent, structurally, from AROS/MorphOS 4.Many of our libraries already have the MorphOS function stubs for post 3.x APIs.And we already share code with MorphOS.I would like to see AROS as a 'source level' transition for MorphOSdevelopers, allowing them to run their pre-compiled PPC binaries onAROS PPC (to ensure that AROS supports the services their Applicationuses), then they can recompile for x86, knowing that they should onlyneed to fix the inevitable endianess issues.Who knows - maybe MorphOS could contribute a 'Rosetta' style PPC->x86interface, then they could use AROS x86 as a kernel for a 'MorphOSx86' (with PPC compatability).
Then you should look in to http://emumiga.org/ and Vamos,http://lallafa.de/blog/category/amiga/vamos .Both projects aimed at running Amiga m68k binaries on x86.Emumiga specifically at running m68k Amiga binaries on AROS.(Developed on AROS x86, but in theory it should run unchanged on AROSx86/PPC/m68k, maybe even amd64.)Anyway, the difficult part stems from the fact that m68k is bigendian. Emumigaright now has a68000 interpreter. But it could also have a PPC interpreter. Morphos is verysimilar to OS 3.1I guess? So probably most of the lessons and maybe even code from Emumigacould be used here.
Adesso ci siamo. Però, e spero non ti seccherai, ho gradito molto di più l'elenco delle mail che ha riportato raistlin77it, che mostrano tanti interessanti retroscena e dettagli che dalla sintesi come quella che hai riportato non poteva emergere.P.S. Purtroppo http://emumiga.org/ sembra morto.
Adesso ci siamo. Però, e spero non ti seccherai, ho gradito molto di più l'elenco delle mail che ha riportato raistlin77it, che mostrano tanti interessanti retroscena e dettagli che dalla sintesi come quella che hai riportato non poteva emergere.
Citazione da: "cdimauro"Adesso ci siamo. Però, e spero non ti seccherai, ho gradito molto di più l'elenco delle mail che ha riportato raistlin77it, che mostrano tanti interessanti retroscena e dettagli che dalla sintesi come quella che hai riportato non poteva emergere.ci mancherebbe ; è una fortuna che vi sia chi riporta dettagli ed entra nel particolare, il bello è proprio questo(in amiga-news.de il giorno successivo riportano la traduzione in inglese dei loro threads)
Autore
Topic: AROS/MorphOS x86/x64/PowerPC considerazioni (Letto 4891 volte)
