Difference between revisions of "Decisions and Work"
(New Page for Decisions created, not to forget some important things we have to thing about) |
(Added DoMethod Problem) |
||
| Line 2: | Line 2: | ||
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. | 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.) | 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 === | |
# ABIv0 as abi_default, ABIv1 as abi_AROSv1 | # ABIv0 as abi_default, ABIv1 as abi_AROSv1 | ||
# ABIv1 as abi_default, ABIv0 as abi_AROSv0 | # ABIv1 as abi_default, ABIv0 as abi_AROSv0 | ||
| − | + | === Decision === | |
No decision | No decision | ||
| − | + | ---- | |
| − | + | == VarArgs Versions of Functions == | |
| + | === Problem === | ||
How to create varargs Versions of functions. The current implementations in the three platforms are different. | How to create varargs Versions of functions. The current implementations in the three platforms are different. | ||
| Line 46: | Line 47: | ||
The Third option would be to invent something new, like an advanced record/class whatever to make it possible and easy useable. | The Third option would be to invent something new, like an advanced record/class whatever to make it possible and easy useable. | ||
| − | + | === Solutions === | |
# Go for "array of PtrUInt" everywhere | # Go for "array of PtrUInt" everywhere | ||
# Go for "array of const" everywhere | # Go for "array of const" everywhere | ||
| Line 52: | Line 53: | ||
==== Decision ==== | ==== Decision ==== | ||
No 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. | 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 === | |
# Remove "systemvartags" from Amiga and move the varargs versions to the original unit | # Remove "systemvartags" from Amiga and move the varargs versions to the original unit | ||
# Introduce "systemvartags" for AROS/MorphOS as well and move all varargs to there | # Introduce "systemvartags" for AROS/MorphOS as well and move all varargs to there | ||
| − | + | === Decision === | |
No 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. | There is no AmigaLib currently for AROS and for Amiga and MorphOS its very different what should be inside this unit. | ||
| Line 71: | Line 72: | ||
If there a AmigaLib one should define whats in there. In principle it would be nice to have the SetHook();[https://github.com/alb42/lazarus/blob/lazarus-aros/lcl/interfaces/mui/muiglobal.pas#L49] Function in there to set a Hook structure in the right way, especially MorphOS is very different than the other. | If there a AmigaLib one should define whats in there. In principle it would be nice to have the SetHook();[https://github.com/alb42/lazarus/blob/lazarus-aros/lcl/interfaces/mui/muiglobal.pas#L49] Function in there to set a Hook structure in the right way, especially MorphOS is very different than the other. | ||
| − | + | === Solutions === | |
# Introduce AmigaLib for AROS, move DoMethod and so on to there | # Introduce AmigaLib for AROS, move DoMethod and so on to there | ||
# Remove AmigaLib for Amiga/MorphOS move the functions to other units | # Remove AmigaLib for Amiga/MorphOS move the functions to other units | ||
| − | + | === Decision === | |
No 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. | ||
| + | |||
| + | <source lang="pascal"> | ||
| + | //Amiga/MorphOS | ||
| + | DoMethod(Obj, [MethodID, param1, param2, ....]); | ||
| + | //AROS | ||
| + | DoMethod(Obj, MethodID, [param1, param2, ....]); | ||
| + | </source> | ||
| + | |||
| + | |||
| + | === Solutions === | ||
| + | # DoMethod(Obj, [MethodID, param1, param2, ....]); | ||
| + | # DoMethod(Obj, MethodID, [param1, param2, ....]); | ||
| + | === Decision === | ||
| + | No decision | ||
<!-- Template for new Problem | <!-- Template for new Problem | ||
| − | + | ---- | |
| − | + | == Problem Title == | |
| + | === Problem === | ||
Description of the Problem | Description of the Problem | ||
| − | + | === Solutions === | |
# First Solution | # First Solution | ||
# Second Solution | # Second Solution | ||
| − | + | === Decision === | |
No decision | No decision | ||
End of Template--> | End of Template--> | ||
Revision as of 12:01, 23 December 2015
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
- ABIv0 as abi_default, ABIv1 as abi_AROSv1
- 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
- Go for "array of PtrUInt" everywhere
- Go for "array of const" everywhere
- 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
- Remove "systemvartags" from Amiga and move the varargs versions to the original unit
- 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
- Introduce AmigaLib for AROS, move DoMethod and so on to there
- 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
- DoMethod(Obj, [MethodID, param1, param2, ....]);
- DoMethod(Obj, MethodID, [param1, param2, ....]);
Decision
No decision