Icaros torrents

Staf's AROS tries

Current or future development topics/planning

• dos.library changes:
  
  • BPTR is always word based
  • Changes to the handlers
• %ebx register reserved on i386 as base for relative addressing and as libbase pointer passed to library functions

• Working 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 libbase.

• 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.
• Another 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 ?).
    This 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.
  This 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.
  In 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 achieved.
  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.
  In 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
    This 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:
  • a 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 librom.a
  • a std C implementation, stdio is done as a light weight wrapper around amiga OS filehandles
  • Full 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, ...)
  Is 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.
  My 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 ?)
  I 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 ?)
  IMO 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.
• How to extend OS3.x shared libraries ? Where to put AROS extension without hurting compatibility with future versions of MOS and/or AOS ?
• Discuss 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.
  This 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 the moment.

1. Programs 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, ...
2. Each 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.