Aros Abiv1 Situazione

AROS, sistemi compatibili ed emulatori

Aros Abiv1 Situazione

Messaggioda savior » mer giu 19, 2019 3:11 pm

Si Riporto quanto scritto nel blo di kalamatee, che a quanto pare è tornato attivo:

Friday, June 14, 2019

Ahh how time flies ...

Well its been a long 3 years since my last post, with a few absences due to hardware issues amongst other things. I'm still not in a position to work on the things I would like, but due to a few people pestering me when I had decided to stop working on AROS, i've actually still been working away behind the scene (mostly to address issues wawa was encountering, such as missing atomic support to compile certain c++ code on m68k and arm).

One of the main things I have been spending a lot of effort on during this time is reworking the AROS build system so that components get exactly the flags they should for a given toolchain set (e.g. host, kernel and target), because in the past it has been very hit and miss on which ones the components end up using resulting in subtle differences in how the code is compiled in different environments.

After a good 3 or 4 years of hacking away at this I now feel like there is starting to be a light at the end of the tunnel, and feel confident that the components are now using the flags they should be (bar some minor fixes still needed in some specific components mmakefile's).

Another part of this was splitting up the flags passed to the compilers/assemblers so that they are in the correct variables rather than being all crammed into the CFLAGS, making it difficult to work with. Going forward it should be easier to manipulate the used flags so that e.g only the ISA components get replaced to compile for a different flavor of processor on a given platform, and this is currently used to make sure we get all the correct flags needed for m68k builds targeting 68000/020 etc cpus or x86 32bit and 64bit code generation.

Correcting this has allowed the darwin builds to be re-enabled (although due to their lack of maintenance, they probably still need fixes in the code base to get working..)

In combination with these fixes and changes (there is also better c++ handling in the templates, amongst other things), I've also updated the AROS toolchains through to the current experimental version 9.1.0 - which is being used to build the pc-x86_64-smp target. So far the toolchain has been successfully tested with all the AROS targets, bar PPC - although the ARM support is needing a bit of adjustment, which i'm currently talking with michal to get done.

Well, if you thought that might be enough to keep me busy - ive also been working on other things!

The m68k target has received some love to try and improve its performance and behavior a little, and address some problems using it on vampire - though this work is still ongoing. The uae generic gfx card code has been reworked into p96gfx.hidd and handles other devices better now, has fixes to the sprite imagery handling, and should work with multiple p96 .card driver instances at the same time. There is also preliminary code in place to detect remapped rom images so that AROS does not try to use the physical memory they occupy (e.g when booting an a3000 using superkickstart).

ATA device has had its api adjusted slightly so that it uses generic definitions for the controller/bus/unit interfaces inherited from the storage subsystem classes. AHCI devices has also been adapted to expose the same api''s and classes so they now operate using the common storage subsystem, allowing them to be enumerated easily in sysexplorer etc.

Finally, this summary wouldn't be complete without mentioning that I have updated our MesaGL subsystem from the quite old v7 we have been using since its initial inception, to the current v19! Unfortunately (and after discussion with other devs) it meant that for the time being the nouveau driver had to be disabled since it needs considerable work to be able to compile with the newer gallium code base, but if someone decides to do the work before Michal or myself can get round to it - we will finally be able to use modern 3d graphics technologies in AROS!. Im really quite excited about this, and cant wait to see the first OpenGL 4.5 code running native on AROS - and maybe even Vulkan down the line...
Support Aros Develop for System and Applications
Avatar utente
savior

Esperto
 
Messaggi: 78
Iscritto il: mar feb 26, 2019 6:08 pm
Località: Verona

Re: Aros Abiv1 Situazione

Messaggioda savior » mer giu 19, 2019 3:12 pm

Beh, sono passati 3 anni dal mio ultimo post, con alcune assenze dovute, tra l'altro, a problemi hardware. Non sono ancora in grado di lavorare sulle cose che vorrei, ma a causa di alcune persone che mi infastidiscono quando ho deciso di smettere di lavorare su AROS, ho lavorato dietro le quinte (soprattutto per risolvere problemi che Wawa stava incontrando, come la mancanza di supporto atomico per compilare un certo codice c+++ su m68k e braccio).

Una delle cose principali su cui ho speso molto impegno in questo periodo di tempo è stato il rielaborare il sistema di compilazione AROS in modo che i componenti ricevano esattamente le bandiere che dovrebbero avere per un dato set di toolchain (ad esempio, host, kernel e target), perché in passato è stato molto colpito e manca su quali componenti finiscono per usare, con sottili differenze nel modo in cui il codice viene compilato in ambienti diversi.

Dopo ben 3 o 4 anni di hacking away in questo senso, mi sento come se ci fosse una luce alla fine del tunnel, e sono sicuro che i componenti stanno usando i flag che dovrebbero essere (a parte qualche piccola correzione ancora necessaria in alcuni componenti specifici del mmakefile).

Un'altra parte di questo è stata la suddivisione delle bandiere passate ai compilatori/assemblatori in modo che siano nelle variabili corrette piuttosto che essere tutte stipate nei CFLAGS, rendendo difficile lavorare con loro. Andando avanti dovrebbe essere più facile manipolare i flag usati in modo che, ad esempio, solo i componenti ISA vengano sostituiti per compilare per un diverso sapore del processore su una data piattaforma, e questo è attualmente utilizzato per essere sicuri di ottenere tutti i flag corretti necessari per le costruzioni m68k che puntano a 68000/020 ecc cpus o x86 a 32bit e 64bit di generazione del codice.

Correggere questo ha permesso alle build darwin di essere riattivate (anche se a causa della loro mancanza di manutenzione, probabilmente hanno ancora bisogno di correzioni nel codice base per funzionare....).

In combinazione con queste correzioni e modifiche (c+++ è anche una migliore gestione dei template, tra le altre cose), ho anche aggiornato le toolchains AROS fino all'attuale versione sperimentale 9.1.0 - che viene utilizzata per costruire il target pc-x86_64-smp. Finora la toolchain è stata testata con successo con tutti i target AROS, a parte PPC - anche se il supporto ARM ha bisogno di un po' di aggiustamenti, che sto parlando con Michal per essere fatto.

Beh, se pensate che questo potrebbe essere sufficiente per tenermi occupato - ho anche lavorato su altre cose!

Il target di m68k ha ricevuto un po' d'amore per cercare di migliorare un po' le sue prestazioni e il suo comportamento, e affrontare alcuni problemi di utilizzo su vampiri - anche se questo lavoro è ancora in corso. Il codice generico della scheda gfx è stato rielaborato in p96gfx.hidd e ora gestisce meglio altri dispositivi, ha correzioni alla gestione delle immagini sprite, e dovrebbe funzionare con più istanze di driver per schede p96.card allo stesso tempo. C'è anche del codice preliminare per rilevare immagini rom rimappate in modo che AROS non cerchi di usare la memoria fisica che occupano (per esempio quando si avvia una a3000 usando superkickstart).

Il dispositivo ATA ha avuto il suo api leggermente modificato in modo da utilizzare definizioni generiche per le interfacce controller/bus/unità ereditate dalle classi del sottosistema di storage. Anche i dispositivi AHCI sono stati adattati per esporre le stesse api e classi in modo che ora operano utilizzando il sottosistema di storage comune, permettendo loro di essere facilmente enumerati in sysexplorer, ecc.

Infine, questo riepilogo non sarebbe completo senza menzionare che ho aggiornato il nostro sottosistema MesaGL dalla piuttosto vecchia v7 che abbiamo usato fin dal suo inizio, alla attuale v19! Purtroppo (e dopo averne discusso con altri sviluppatori) significava che per il momento il driver nouveau doveva essere disabilitato in quanto necessitava di un notevole lavoro per poter compilare con il più recente codice base di gallio, ma se qualcuno decide di fare il lavoro prima che Michal o me stesso possa girarci intorno - finalmente saremo in grado di utilizzare le moderne tecnologie grafiche 3d in AROS! Sono davvero entusiasta di questo, e non vedo l'ora di vedere il primo codice OpenGL 4.5 in esecuzione nativa su AROS - e forse anche Vulkan lungo la linea.....

Tradotto con www.DeepL.com/Translator
Support Aros Develop for System and Applications
Avatar utente
savior

Esperto
 
Messaggi: 78
Iscritto il: mar feb 26, 2019 6:08 pm
Località: Verona


Torna a AROS e compatibili

Chi c’è in linea

Visitano il forum: Nessuno e 7 ospiti

cron