Amiga: add experimental stack swap support.

[AliceLR]

Closes #87.

This is an updated version of the patch, but still very much needs testing. It works fine for me with both m68k toolchains I have set up + libnix for Workbench 2.

[AliceLR]

Updated to borrow the relevant parts from codesets.library, as it has a hand-written inline assembly routine which should be far safer than attempting to use StackSwap in C.

[AliceLR]

MorphOS tested, works.

[AliceLR]

Resolved a -pedantic warning from converting a function pointer to APTR for MorphOS (AROS presumably also affected).

I haven't been able to test OS 4 or AROS yet.

[AliceLR]

This should be ready. Please test AROS and fix as necessary, since I can't test it on my end.

[sezero]

The following is needed for 64 bit Aros: (will run-test shortly)

diff --git a/src/main_amiga.h b/src/main_amiga.h
index cafd4ef..ff602f0 100644
--- a/src/main_amiga.h
+++ b/src/main_amiga.h
@@ -165,7 +165,11 @@ int main(int argc, char **argv)
 			struct main_args args;
 			int ret;
 
+			#ifdef __AROS__
+			sw.stk_Upper = (APTR)((IPTR)sw.stk_Lower + MIN_STACK_SIZE);
+			#else
 			sw.stk_Upper = (ULONG)sw.stk_Lower + MIN_STACK_SIZE;
+			#endif
 			sw.stk_Pointer = (APTR)sw.stk_Upper;
 
 #if 0

One thing is that this relies on gcc for m68k, which may be mostly true,
but VBCC is also used. An #elif defined(__M68K__) && defined(__VBCC__)
case is needed in there but I can't write the asm for it, haven't messed
with that for years. If that's a hassle though, VBCC builds need ignoring
at top of main_amiga.h.

[AliceLR]

One thing is that this relies on gcc for m68k, which may be mostly true, but VBCC is also used. An #elif defined(__M68K__) && defined(__VBCC__) case is needed in there but I can't write the asm for it, haven't messed with that for years. If that's a hassle though, VBCC builds need ignoring at top of main_amiga.h.

The software I got this asm fragment from did not have VBCC code, so this may have to be disabled for VBCC builds.

The following is needed for 64 bit Aros: (will run-test shortly)

OK, if it works, I can try to patch it in soon. (I don't think xmp uses preprocessor macro style like that, though, it's non-indented almost everywhere.)

[sezero]

Tested x86_64-aros (linux-hosted version) and it works.

Adjusted the ifdef indentation. Should I force-push the
following to your branch?

Q: Should we double the minimum stack size, e.g. 65536 for 64 bits?
EDIT: I ran the aros x64 version after running stack 4096, it ran just
fine, so I guess no bump is necessary.

diff --git a/src/main_amiga.h b/src/main_amiga.h
index 8da843b0..c3927650 100644
--- a/src/main_amiga.h
+++ b/src/main_amiga.h
@@ -32,7 +32,7 @@
 
 #include "common.h"
 
-#if defined(XMP_AMIGA)
+#if defined(XMP_AMIGA) && !defined(__VBCC__)
 
 #include <proto/exec.h>
 
@@ -165,7 +165,11 @@ int main(int argc, char **argv)
 			struct main_args args;
 			int ret;
 
+#ifdef __AROS__
+			sw.stk_Upper = (APTR)((IPTR)sw.stk_Lower + MIN_STACK_SIZE);
+#else
 			sw.stk_Upper = (ULONG)sw.stk_Lower + MIN_STACK_SIZE;
+#endif
 			sw.stk_Pointer = (APTR)sw.stk_Upper;
 
 #if 0

[AliceLR]

Tested x86_64-aros (linux-hosted version) and it works.

Adjusted the ifdef indentation. Should I force-push the following to your branch?

OK, I will patch this in soon.

Q: Should we double the minimum stack size, e.g. 65536 for 64 bits? EDIT: I ran the aros x64 version after running stack 4096, it ran just fine, so I guess no bump is necessary.

I don't think that's necessary, because libxmp's stack usage looks something like:

• 16k + change when computing an MD5.
• 16k + change when depacking with an external depacker (edit: except for the XFD depacker, which allocates buffers).
• Otherwise, predominantly structs in loaders that do not contain very many (if any) pointers or size_t. I didn't thoroughly test this, but XM and/or playback was fine with an 8k stack when I patched the aforementioned 16k buffers to be 2k. I highly doubt any individual loader is capable of putting 32k on the stack, but if I'm wrong, we can fix it later. (:
• Glad we got rid of alloca in stb_vorbis or it'd be another consideration here... I didn't test any OggMod XMs though, so I don't know how much it puts on the stack outside of that.

[sezero]

Tested x86_64-aros (linux-hosted version) and it works.
Adjusted the ifdef indentation. Should I force-push the following to your branch?

OK, I will patch this in soon.

Looked at vbcc: we don't have m68k asm for it but it responds to global var __stack
which you provide: Updated patch below.

diff --git a/src/main_amiga.h b/src/main_amiga.h
index 8da843b..931fec2 100644
--- a/src/main_amiga.h
+++ b/src/main_amiga.h
@@ -52,6 +52,11 @@ const char XMP_USED stack_cookie[] = "$STACK: 32768";
 extern int __stack;
 int XMP_USED __stack = MIN_STACK_SIZE;
 
+#if defined(__VBCC__) && !defined(XMP_NO_STACKSWAP)
+/* no m68k asm for vbcc, but it responds to global var `__stack` */
+#define XMP_NO_STACKSWAP
+#endif
+
 /* Workbench 2.04 through 3.1: manually set stack size via StackSwap.
  * This needs to be performed through inline ASM to be safe.
  *
@@ -165,7 +170,11 @@ int main(int argc, char **argv)
 			struct main_args args;
 			int ret;
 
+#ifdef __AROS__
+			sw.stk_Upper = (APTR)((IPTR)sw.stk_Lower + MIN_STACK_SIZE);
+#else
 			sw.stk_Upper = (ULONG)sw.stk_Lower + MIN_STACK_SIZE;
+#endif
 			sw.stk_Pointer = (APTR)sw.stk_Upper;
 
 #if 0

Q: Should we double the minimum stack size, e.g. 65536 for 64 bits? EDIT: I ran the aros x64 version after running stack 4096, it ran just fine, so I guess no bump is necessary.

I don't think that's necessary, because libxmp's stack usage looks something like:

* 16k + change when computing an MD5.

* 16k + change when depacking with an external depacker (edit: except for the XFD depacker, which allocates buffers).

* Otherwise, predominantly structs in loaders that do not contain very many (if any) pointers or `size_t`. I didn't thoroughly test this, but XM and/or playback was fine with an 8k stack when I patched the aforementioned 16k buffers to be 2k. I highly doubt any individual loader is capable of putting 32k on the stack, but if I'm wrong, we can fix it later. (:

* Glad we got rid of `alloca` in stb_vorbis or it'd be another consideration here... I didn't test any OggMod XMs though, so I don't know how much it puts on the stack outside of that.

OK :)

[AliceLR]

OK, I've applied the vbcc and AROS patch.

Looked at vbcc: we don't have m68k asm for it but it responds to global var __stack which you provide: Updated patch below.

+#if defined(__VBCC__) && !defined(XMP_NO_STACKSWAP)
+/* no m68k asm for vbcc, but it responds to global var `__stack` */
+#define XMP_NO_STACKSWAP
+#endif

I slimmed this part down a little bit by combining it into the existing #if, though.