Staf's AROS triesHere you can find some comments on
the development I'm doing for the AROS operating system together
with some ideas of how the future of AROS can look like.
Current or future development topics/planningThe current and future topics and development efforts.
1. i386 ABI V1 changes
Changes currently in the ABI_V1 branches (trunk/branches/ABI_V1):
Ongoing changes in the branches:
to be done (discussion has to happen and actions to be defined and assigned):
on C library and ETask. The purpose of this change is to remove all
arosc specific extensions from the AROS Task structure. I am extending
the autogenerated code from genmodule so that it provides the features
so that arosc.library can store all its state in it's own per-opener/per-task
2. SDK compatibility with vbcc and maybe SAS/C
- SysBase location
- Currently it is a special global variable handled by the ELF loader; but some people don't seem to like it...
I would like to keep it like that.
problem is that currently SysBase is one global pointer shared by all
tasks. This is not SMP compatible as we need a SysBase at least for
each CPU/core separately. Michal then proposed to call a function
everytime you need SysBase. I proposed to use virtual memory for that;
e.g. that SysBase pointer has the same virtual address for each task
but points to a different physical address for each CPU.
- exec: AllocTrap/FreeTrap and ETask ?
- See ongoing changes above
- kernel.resource (can it wait for ABI>1.0 ?).
resource is meant to gather all arch and cpu specific code for
exec.library. This way exec.library would not need any arch specific
code but would use a call to kernel.resource functions when arch
specific information or actions are needed.
This change can be
delayed until after ABI V1.0 as exec.library is fixed; but programs
that use the kernel.resource directly will not be compatible with the
next iteration of the ABI.
- dos.library compatibility
- Switch everything to DOS packets and remove the current system based on devices.
has been heavily discussed on the maillist. The current AROS
implementation uses devices for message passing and the classic system
used Port and DOS Packets. The latter is considered by many people as a
hack on AmigaOS without fully following the rest of the OS internal
structure. That's also reason why the alternative for AROS was
developed in the first place.
But it became clear that we'll have to
implement a DOS packets interface anyway and thus the question became
if we should have two alternative implementations in AROS anyway.
the beginning I was also a big opponent to the DOS packets mostly
because the device interface allowed to run some code on the callers
task and thus avoid task switches to reduce throughput. Using the
PA_CALL and PA_FASTCALL feature of AROS ports the same could be
In the end it was concluded that everything you could do
with the device interface could also be done in the ports interface and
vice versa and that having two systems next to each other is bloat.
current implementation filehandles and locks are the same and this
should also be changed when switching to the DOS packets interface.
- C library
- ??? no static version of arosc.library
makes building arosc quite complex and all programs should be able to
use the shared version anyway. I don't think currently any program uses
the static version of library.
- ??? remove librom.a
I would split arosc.library in three parts:
std C subset that can be put in ROM as the first library, that thus
does not need dos.library. This should then replace all usage of
- a std C implementation, stdio is done as a light weight wrapper around amiga OS filehandles
POSIX implementation; possibly also including some BSD functions. This
would then provide a (nearly) full POSIX implementation. This library should be
optional and real amiga programs should not need this library.
- varargs handling (stdarg.h, va_arg, SLOWSTACK_ARGS, ...)
currently heavily discussed on the mailling list, but I myself don't
have the time to delve into it. A summary of different proposals with
some example code to see the effect on real code would be handy.
proposal is to switch to the startvalinear & co. from the adtools
gcc compiler. This will use the same solution as is used for OS4.
Advantage is that a limited change of code is needed to adapt this.
Disadvantage is that the adtools gcc has to be used for compiling AROS.
- oop.library optimization (can it wait for ABI>1.0 ?)
think current oop.library and the hidds are still sub-optimal and need
some more investigation. I think this work can wait till after ABI V1.0
and mentioning in the ABI V1.0 that programs that use oop.library or
hidds directly won't be compatible with ABI V2.0.
- libcall.h/cpu.h clean-up (can it wait for ABI>1.0 ?)
some cruft has been building up in these files and they could use a
good discussion of what things can be removed and what things can be
combined and then properly documented. Probably this does not impact
the ABI so it may be delayed but changes to these files may cause
source compatibility problems. E.g. programs will not compile anymore
with the new version if they depend on some specific feratures and need
to be adapted but programs compiled with the old version will keep on
running on AROS.
to extend OS3.x shared libraries ? Where to put AROS extension without
hurting compatibility with future versions of MOS and/or AOS ?
and flame about these patches on the maillist before applying them to
the main trunk. Possibly improve or rewrite part of them.
- Write (i386) ABI reference manual and put it on the web.
will involve a lot of discussion on the maillist to nail down the V1.0
version several APIs. During the writing of this manual a lot of things
will pop up that have not be tought through yet, so ABI V1 and AROS 1.0
can only be released if this task is finished.
One of the important
discussions is to clear out what is handled by the compiler and what is
defined by the ABI of AROS itself. This border is quite vague at
3. Bugs hunting
4. Resource tracking
I would like to propose a new way of resource tracking. It should be based on two principles:
that wants to use resource tracking have to open exec.library expicitly
and not use the pointer that it originally got from the system. All
actions from then on will be tracked by exec. If exec.library is closed
again it will roll back all cleanup actions that have not been
performed yet: closing opened libraries, freeing non-freed memory, ...
of the libraries have to do their own tracking of resources and perform
the right clean up actions when they are closed by the program or
during the clean up by exec.