Porting to AmigaOS4 thread

@Elwood

i knew about this try, but it never produced any binaries/usable files and is stuck in 2013

even if they were successfull back then it would be outdated by now

@devs

i know there is this stack cookie thing, but is it really needed?

i seems kinda outdated, at least how i understand it

one gives the stack cookie the program can use *if* the environment provides not enough stack size, i.e. WB or shell

but its still limited to the size i give in the cookie?
unless i change the stack size in its icon or in the shell?

why?

why not simply enhance the stack where needed?
the OS should be capable of providing on-the-fly stack enhancement, shouldnt it?

or is the stack a "closed" memory area reserved just for the app that demands/needs it?

and is the stack memory locked for the app while it runs?

what if i gave a 2 GB stack cookie to a single app...would the system freeze?
or would no other programs be able to register any more memory (which would in turn lead to a crash or freeze the system sooner or later, i think...?) heh

or would the memory only be used if it really would be needed and otherwise be free to any other app?
if that is true, then why not simply set the stack size for every program to the available amount of memory system-wide?

@Raziel
Quote:The C compiler (at least GCC, not sure about VBCC) has an option to increase the stack size automatically when required, but AmigaOS 4.x doesn't support that and will crash if the stack size is too small.
The "stack cookie" is only one of the options, there is the shell stack size or the Workbench Icon stack size as well, and the largest one of all options will be used, but if all of them are too small for a given program it will crash on AmigaOS 4.x.
The stack can't be swapped out by the pager, if you'd use 2 GB stack any program will crash immediately because of the 2 GB limit of a single, ancient Exec(SG) function. Using 1 GB may work for most software, but you'll only have the other 1 GB available for anything else.

@Raziel

if stack is:

02 VAR1
04 VAR2
06 VAR4

you pass a ref to 04, and then replace the stack,
as then something can't access 04 anymore, so you have crash.

if swap out stack and use different stack.
but do not free the old one, you coninue on:

4000 VAR5
4004 VAR6

if you resotre the stack before exiting your function.

@joerg

thank you very much for the answer, that's what i figured

@LiveForIt

that went far over my head

@LiveForIt
AmigaOS doesn't have any problems with fragmented stacks, even porting Rust to AmigaOS, the programming language used for example by the current FireFox versions, would be much less of a problem than for example porting the Linux version was to BSD Unixes.
AmigaOS always supporting stack swapping, for example the ancient IExec->StackSwap() and newer replacement functions in Exec(SG).

@joerg

to conclude that, it wasn't the stack, but a problem in-code resp. a missing feature
https://github.com/sba1/adtools/issues/159
(wrong tracker, i know, please point to the correct tracker, thank you)

@all

I'm too dumb to give up, so i'm testing my *skills* (lol) on another porting project, but i hit a wall (as guessed) with a pretty standard header file.

disclaimer:
i'm on cross-compiler since cmake is mandatory for the project and native cmake is hopelessly outdated and broken...so...

The file in question has

in it's header flock, but produces errors on compiling

there is also another file called "Math.cpp" within the source files...could that be interfering?

I read here, that it could be the cause, but i don't understand why



any idea other than renaming that Math.cpp file?

Thank you very much

because adtools was broken.. We have fixed it in the branch but an update was never released. So the only way is to recompile it

@afxgroup

may i ask to what post you're referring to?

@all

as it seems newlib doesnt have

any way to work around it?

Can you report an issue with a small reproducible at https://github.com/AmigaLabs/adtools/issues.

I thought newlib did have that. But I cannot remember. If it does, you can just call the newlib one ?

@rjd324

i can point you to the project i was trying to port (small)
https://files.musepack.net/source/musepack_src_r475.tar.gz

just start

and let it run until it hits memcmp

the configure script probably needs some (heavy?) editing still, i just wanted to see how far it will go w/o changing anything

@all

gcc: fatal error: '-pipe' not supported

any way around it?


edit:

gcc -v
Using built-in specs.
COLLECT_GCC=/Development/Coding/SDK/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/Development/Coding/SDK/gcc/bin/../libexec/gcc/ppc-amigaos/11.3.0/lto-wrapper
Target: ppc-amigaos
Configured with: /home/stix/kod/adtools/gcc/repo/configure --with-bugurl=https://github.com/sba1/adtools/issues --with-pkgversion='adtools build 11.3.0' --host=ppc-amigaos --target=ppc-amigaos --disable-nls --prefix=/gcc --with-gmp=/home/stix/kod/adtools/native-build/root-cross --with-mpfr=/home/stix/kod/adtools/native-build/root-cross --with-mpc=/home/stix/kod/adtools/native-build/root-cross --enable-languages=c,c++ --enable-haifa --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-tls --enable-threads=amigaos --enable-lto --disable-c++tools
Thread model: amigaos
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (adtools build 11.3.0)


guess it`s not built in?