These changes adds an additional record field to record structure TMsgPort in
order to support SMP for ABIv11 (non m68k targets only).
This additional field contains two opaque IPTR's/PtrUInt's and therefor breaks
compatibility between ABIv0, ABIv1 and ABIv11 as well as make them binary
incompatible.
It also renders ABIv11 incompatible with itself when this change was introduced
on march 18 2022. Recompilation of existing code for this ABI is thus required.
See: b9bc67accc
These changes makes sure that the use of record structure spinlock is not
active/available when compiling for AROS ABIv11 as that ABI does not support
spinlocks as implemented for AROS ABIv1.
Note that this is a ABI and Binary Compatible break between ABIv1 and ABIv11.
These changes makes sure that the use of record structure TSpinlock can only
be enabled/active for AROS ABIv1 as that ABI is currently the only ABI that
is able to support SMP by using the spinlock record structure.
This commit will add an additional spinlock field to record structures
TMsgPort and TSemaphoreRequest for a SMP enabled build.
This will break ABI and Binary Compatibility between ABIv0 and ABIv1 and for
ABIv1 (for a SMP enabled build).
Recompilation in such case is required as both record structures TMsgPort and
TSemaphoreRequest are embedded in other record structures which causes a
myriad of changes to those records including different record sizes and other
field offsets.
Note that SMP is currently only available for ABIv1 and afaik only supported
for AROS target x86_64 while AROS target i386 has initial support for SMP
(but not actively enabled).
SMP enabled build can be 'activated' by defining AROS_PLATFORM_SMP and
AROSEXEC_SMP.
In 2015 ABIv1 introduced support for spinlocks for SMP enabled builds (1) by
use of a special spinlock structure.
This structure was later updated to end up in its current form in 2017 (2)
This commit adds this record structure to both RTL (execd) and unit (exec).
The structure can be "enabled" by defining AROSPLATFORM_SMP during build.
1) b6045c27fd
2) 0ffdbdc48f
These changes break API/Binary Compatibility between ABIv0 and ABIv1.
Field stdOut is replaced by undefined field named _pad for ABIv1 while
(still) being present as stdOut for ABIv0.
Field DebugConfig is completely removed from ABIv1 (still present for ABIv0).
If your code depends on either of these two fields then you need to make
appropriate changes when compiling for ABIv1.
Removing dependency on either of these two mentioned fields is preferred.
Both RTL (execd.inc) and unit (exec.pas) are updated.
See also 194cc5e1c5
These changes break Binary Compatibility between ABIv0 and ABIv1.
Record TETask was not compliant to ABIv1 because field et_Compatibility is
only required for ABIv0 (06538a1790).
Therefor these changes update record TETask for both RTL (execd.inc) and unit
exec (exec.pas) so that field et_Compatibility is only present for ABIv0.
The impact of these changes should be minimal because all relevant fields are
still accessible (some located at another offset) and code should never rely
on the size of this structure.
Update some amigados unit record field members for AROS compatiblity.
These changes reflect the changes made in the doslib RTL (that were present in
the previous commit).
Update some amigados record structures to be 32/64-bit compatible.
These changes reflect the changes made in the doslib RTL (that were present in
the previous commit) but note that some of Unit amigados' record structures
were already up to date.
Memory sizes are expressed in IPTR/PtrUInt in order to be compatible to both
32 and 64-bit.
This changes some of Exec API call signatures and should not impact
existing code.
These changes reflect the changes made in the exec RTL (that were present in
the previous commit) but note that Unit Exec record structures were already
up to date.
See: d7df812342
Final step that attempts to ensure that fields of particular records are
'STACKED' (stack aligned) properly for both 32 and 64 bit.
AROS introduced STACKED structure members, which are members that are padded
according to the current used stacksize which in itself is based on the target
CPU.
These structures are required to have a particular defined size in memory and
have a particular field alignment, therefor these records are always end-padded
(whether required or not) so that we are able to force the compiler to add
padding depending on the RECORDMIN setting.
Other available FPC directives and/or solutions seem currently not able to
solve that issue and we do not wish to manually check each structure to
determine if it requires end-padding or not (based on bitness) simply because
it is unmaintainable.
This change attempts to ensure that these record structures compile using the
correct memory size and field layout for both 32 and 64-bit CPU's.
The introduction of stack aligned record fields solves a lot of 64-bit related
crashes when working with native OOP such as MUI and BOOPSI.
Note: Not tested on big endian.
Preparations for the introduction of stack aligned record fields (AROS STACKED
structure members).
MethodID really is 32-bit wide so we need to change those back to their
original size.
Preparation for the introduction of stack aligned records fields (AROS STACKED
structure members).
Remove unmaintainable superfluous ifdef's that are used inside certain record
structures (in an attempt to use correct padding on 64-bit targets) because
they are not in line with the introduction of stack aligned record fields.
