Decisions and Work

Purpose

On this page open decisions and work should be collected. Only the Problem, Solutions and Decision should be written here, all discussions should be done on the discussion Page.

---

ABIv0 / ABIv1 in AROS

Problem

With x86_64 the first ABIv1 is introduced to Freepascal, but it is not working currently because of the differences in the SDK. To change that is not a big problem, but if is done, it would be good to have a general approach for the ABIv0/ABIv1 switching. Freepascal already has a concept of ABI switching. Here a Default must be set (abi_default) and a new one. The first reaction would be to make ABIv0 as abi_default (because thats the only one working) and create another one abi_AROSv1 or something like this. But if we look to the future the i386 ABIv0 will be gone (far distant future after singularity or so) then there will be no abi_default or so, which is a little bit strange, isn't it?. The decision also must be synchronized with freepascal ideas about this ABI feature in Freepascal. (Charlie got the task to discuss this.)

Solutions

1. ABIv0 as abi_default, ABIv1 as abi_AROSv1
2. ABIv1 as abi_default, ABIv0 as abi_AROSv0

Decision

No decision

---

VarArgs Versions of Functions

Problem

How to create varargs Versions of functions. The current implementations in the three platforms are different.

• Amiga uses "array of const" together with broken readintags() and readinlong()
• AROS uses "array of const" together with own TTagsArray AddTags function
• MorphOS uses "array of DWord"

The Amiga implementation is for sure broken because readintags/readinlong are using one global array so if you call a Method which triggers an Event which want to do an other function with tags you get a crash because the second tag use overwrite the tags of the initial method. (the reason the approach was completely removed in AROS)
The AROS implementation has its problem on the string, especially shortstring side.

AddTags(TagList, [TAG_SOMETHING, shortstringvar]);
somefunction(GetTagPtr(TagList));

Might work or not. The contents of shortstringvar could be already overridden by something else. The contents is copied to a string and connected to a PChar, but this is freed after the AddTags call already, so this have to be considered also as broken. You can avoid this by putting the string as PChar into the varargs call. Besides this all "array of const" expect the value inside to be a LongInt Value (Note: It's Signed) The most Tags have are over MaxInt so they give a very bad Warning about range violation on every compile. Of course it possible to If "array of const" is even possible for 64 bit is untested currently, but I guess it is.
The MorhOS uses "array of DWord", which is the easiest and cleanest approach in my understanding. of course it should be "array of PtrUInt" to be on the save side for 64Bit.
Overall there should be one solution for all three platforms. To keep the casting to a minimum one could use the TAG_() idea, magorium used in his Trinity/Triforce approach [1].

function TAG_(TagItem: PtrUInt): PtrUInt; overload; inline;
function TAG_(TagItem: PtrInt): PtrUInt; overload; inline;
function TAG_(TagItem: Pointer): PtrUInt; overload; inline;
function TAG_(TagItem: boolean): PtrUInt; overload; inline;

The Third option would be to invent something new, like an advanced record/class whatever to make it possible and easy useable.

Solutions

1. Go for "array of PtrUInt" everywhere
2. Go for "array of const" everywhere
3. Invent something New

Decision

No decision

---

Systemvartags

Problem

In Amiga there is this funny "systemvartags" unit which contains all the varargs Versions of the other units. This means if you include this unit you get dependencies to all the units included.

Solutions

1. Remove "systemvartags" from Amiga and move the varargs versions to the original unit
2. Introduce "systemvartags" for AROS/MorphOS as well and move all varargs to there

Decision

No decision

---

AmigaLib

Problem

There is no AmigaLib currently for AROS and for Amiga and MorphOS its very different what should be inside this unit. Functions like DoMethodA, DoSuperMethodA and so on reside currently in intuition at AROS. If there a AmigaLib one should define whats in there. In principle it would be nice to have the SetHook();[2] Function in there to set a Hook structure in the right way, especially MorphOS is very different than the other.

Solutions

1. Introduce AmigaLib for AROS, move DoMethod and so on to there
2. Remove AmigaLib for Amiga/MorphOS move the functions to other units

Decision

No decision

---

DoMethod

Problem

At the moment there is a big difference between AROS on the one side and Amiga/MorphOS on the other side when calling DoMethod and such functions.

//Amiga/MorphOS
DoMethod(Obj, [MethodID, param1, param2, ....]);
//AROS
DoMethod(Obj, MethodID, [param1, param2, ....]);

Solutions

1. DoMethod(Obj, [MethodID, param1, param2, ....]);
2. DoMethod(Obj, MethodID, [param1, param2, ....]);

Decision

No decision