Blog: http://binarydoodles.ilcannocchiale.it

Technologies: 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 Staf Verhaegen; we already know  that is a very important and time consuming task, that will redefine the binary interface for AROS programs and that will break all actual AROS software, that will need to be recompiled to work again;
on sunday march 20 Staf announced a milestone for its work:

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 ?

as you can understand that will be a problem


[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]

[Mschulz and Sonic modularize AROS kernel]

[the SONIC bomb]
Another topic that i want to talk about is the mail that Pavel "Sonic" Fedic sent to the developer mailing last last April first; despite the date, the content was indeed serious; the talk was about the elf binary format structure, and about memory consumption; i seen Michal Schulz doing experimentation with the memory allocator in the last march, i knew about the experiments of Pavel porting AROS on IOS and i knew about the modularization of the kernel and the rework of the graphic subset; however seeing this paragraph from Pavel in my opinion officialise this:

ET_exec is not appropriate for AROS because it's non-relocatable snapshot of address space. Yes, we actually can relocate it, provided that we keep relocs in the output (using -q option), and relocation is even simpler in this case (adding a fixed offset to all absolute addresses), but there is another issue: section alignment.

ELF suggests that different sections (code and data) have different memory 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), linker uses "common page size", which is 64KB. This means that there are empty 64KB between code and data in the file. It does not occupy space on disk, because it is encoded in section offsets. It also does not occupy space in memory on UNIX (where address space is virtual, it simply misses that portion), but it would occupy these 64KB if loaded on AROS, where memory has 1:1 mapping.

Yes, we could shorten this size, for example to 4KB, but can we have problems, especially on hosted AROS? Can there be host OSes using larger than 4KB pages? If so, this will mean that we can't correctly work on these OSes.

This issue can be worked around if we split the file up section-by-section, in the same way as it is now. However in this case ET_exec is more difficult to handle than ET_REL, and has no advantages over current loader. It is more difficult because for ET_REL relocations implicit addends are destroyed, and we need to calculate them back.

What i described here implies that in future (not so far) AROS will have 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;

Pubblicato il 9/3/2011 alle 7.56 nella rubrica diario.

Il Cannocchiale, il mondo visto dal web