AROS: ABI v1 and the 68k port are proceeding well…

Again a post “in progress” – so much to write and so little time, so please come back often to see how is it going 🙂

When i started this article,two weeks were already gone from the appearance of AROS at SCALE;  as i mentioned in the previous blog article, had finally been able to render the animation and upload it in vimeo; lately the Amiga landscape in some way emerged once again in a more mainstream environment due to several events:

first of all, the appearance of AROS in more medias than usual; the march and april issues of the PCLinuxOS magazine host a quite comprehensive review of Icaros Desktop splitted in four parts and written by Darrell ‘DJohnston’ Johnston; the dissertation starts with explaining how to install AROS using HdToolbox for partitioning your disk – giving also a very detailed insight on how HDToolbox works, pretty needed since the power of the tool and the usual advice from developers and Paolone not to use it unless you know how to – problem is even those Amiga users that used it in the past might have forgot; the article series goes on in installing Icaros, in examining the preference panels, the bundled software, including OWB and janus-UAE and, finally, in doing a general errata corrige and clarification about some mistakes of the last three parts and a fast glimpse at Broadway.

You can give it a look more in particular from those links:

Part 1 – Introduction to AROS, Icaros and installation

Part 2 – A fast overview of Wanderer

Part 3 – More Wanderer and an overlook at the bundled software

Part 4 – Errata Corrige, Janus-UAE and a glimpse of AROS Broadway

[AROS on techradar and PCLinuxOS magazine]

[the work on KS integration II]
[Workbook – a wanderer lite]
[and the work on ABI v1]
The focal point of this article is, though, the ongoing work in the ABI v1 that is actually made mostly by

Hello AROS devs,

I am happy; the ABI V1 branch is compiling and running on top of main
trunk of only a few days old.

Before I will branch for ABI V1 I will still merge some changes from the
branch in main trunk that don’t have a ABI impact.

When that is finished it is time to branch; hopefully in a week or two.
Do the m68k want to finish something before branching or is it still the
faster the better ?

[Kalamatee works again on new Wanderer]
Guess somebody still remember when in 2009 Nik “Kalamatee” Andrews started to work on the overhaul of Wanderer, with the idea to make it become modular and extensible via a plug-in system; the work was interrupted one year due to serious problems with the AROS graphic subsystem of the time;

Nei cafferkey, beside being actually busy with the wireless bounty, where is actually working on adding the support to the Realtek 8167 chipset for USB wireless sticks (that will also be extended in future for Realtek cards), is also working on improving the VESA driver; some improvements to some graphic.library routines have been made by Deadwood in order to accelerate the rendering of transparent images in themes, that gave performance problems to wanderer, especially on 68k;  in march also performance problems made [look who] review the png datatype behaviour; in this te contribution of Bernd Roesch in finding an excessive amount of calls toward the png.datatype especially on 68k helped to nail the issue;

[profiles on AROS Broadway]

ET_exec is not appropriate for AROS because it’s non-relocatablesnapshot of address space. Yes, we actually can relocate it, providedthat we keep relocs in the output (using -q option), and relocation iseven simpler in this case (adding a fixed offset to all absoluteaddresses), but there is another issue: section alignment.

ELF suggests that different sections (code and data) have differentmemory access rights. code is read-only and data are not executable.This implies that these sections are aligned to memory page borders.

In order to match different page sizes (4KB, 8KB, 16KB, etc), linkeruses “common page size”, which is 64KB. This means that there areempty 64KB between code and data in the file. It does not occupy spaceon disk, because it is encoded in section offsets. It also does notoccupy space in memory on UNIX (where address space is virtual, itsimply misses that portion), but it would occupy these 64KB if loadedon AROS, where memory has 1:1 mapping.

Yes, we could shorten this size, for example to 4KB, but can we haveproblems, especially on hosted AROS? Can there be host OSes usinglarger than 4KB pages? If so, this will mean that we can’t correctlywork on these OSes.

This issue can be worked around if we split the file upsection-by-section, in the same way as it is now. However in this caseET_exec is more difficult to handle than ET_REL, and has no advantagesover current loader. It is more difficult because for ET_RELrelocations implicit addends are destroyed, and we need to calculatethem back.

What i described here implies that in future (not so far) AROS willhave memory protection. I know how Michal and i will implement it,just it’s not ready yet.

there is already a partial protection similar to the one in AOS-4 present in the x86/64 kernel and if i remember good in the efika port[verify – ask mschulz]; i don’t know if this is a new rework or is a reprise of the work done in that occasion, though;

Well, is already known that talking about the actual state of Amiga-like OSes having memory protection implies some kind of sandboxing; i am not a kernel developer but the kernel modularisation though should provide the required elasticity for the system to support it, mean older systems probably will use different modules compared to newer ones and also i suppose that this also might make the older modules with no protection coexist in a sandboxed area so that any problems with that will not affect the system as a whole, but since i have no enough knowledge about how is really this is just my own conclusion; interesting to see that probably this post unchained a(nother) thread on AROS-exec here, where once again the topic is discussed, along with proposals and references from other sites;