Supervisor stack size?
 

So if I understand correctly, when you have an interrupt server it will be run in supervisor mode using the supervisor stack.

How big is the supervisor stack ? Is this documented anywhere ?

You will find this info in SysStkUpper/SysStkLower fields in ExecBase.

Great thanks, is this configurable in a system friendly way?

Or would use switch to your own stack if you needed a bigger stack in a server?

Moving the supervisor stack is possible, i even have code for doing it, but i wouldn't recommend doing that all the time...


Never did this, but it's in theory possible to use your own allocated stack.

However, normally the supervisor stack should be big enough. If you're doing heavy duty work it might be better to create a new task and send it some signal from the interrupt server.

You can allocate a new supervisor stack - all provided you insert this information into execbase as otherwise graphics below v45 gets a hickup. However - what for? The supervisor stack is only needed for interrupt processing, and its default size of 6K is really large enough. There is no "own supervisor stack", there is only "one supervisor stack". So I wonder - why do you think that the default size is not large enough? Note well, the supervisor stack is completely separate from the user stack which is separate for each task, and which has a size that is task-dependent and configurable individually, for example with the magic $STACK: cookie in the code hunk.

What's the exact format, and what versions of Kickstart support this?

I always felt that the managing the stack via the c:stack command and the program icon was a terrible solution.

I'd like to know, too.. Sounds interesting, don't think I ever heard that mentioned before..

From what i know setting stack size this way requires at least kick 3.1.
I prefer using a pair of StackSwap() calls.

Well I don't have an immediate specific need for something > 6k in mind, but games programmers are always pushing the boundaries of everything, so it's nice to know where the boundary is. As for "6K is really large enough", sounds a bit like another famous quote about ram size that also started with a 6 and ended with a K ;)

I could imagine for example if you wanted to do a quick and dirty conversion of a non system friendly game, to make it system friendly that had it's main loop running out of the VBL and it used a lot of stack. Obviously there are other ways around it, but the OS provides a way of adding these interrupt servers, yet there are (unwritten?) rules about what you can do in them.

I have not found this cookie in any executable. Is it an OS4 feature?

AFAIK this is OS4 only.

No. Everything from 3.9 onwards, including 3.1.4, supports it. This feature is part of the shell, and part of the workbench. It made its way into the shell first, workbench came later.

It appears to be this:
https://wiki.amigaos.net/wiki/Contro...lication_Stack

I never knew about this feature either.

A newline at the end of the string is missing.

is a classic terminating zero char required also?

Still unclear to me what logic applies if CLI or WB-icon specifies a larger stack than the cookie.
In my tests it didn't work in 3.9.

You can only increase the stack size, not decrease it. And sure, it does work. The feature came in with the updated shell in one of the BoingBags, the cookie must be in the first hunk, and it requires a line feed and a \0 beyond the number. The workbench does not honor it before 3.1.4.

So to summarize, it's

$STACK:1234\n\0

inserted into the first hunk, and it only works correctly in AmigaOS 3.1.4 (both in the shell and on the Workbench) and the stack size will be set to the largest of the three indicators?

It already works with the V45 shell which was first delivered with one of the boingbags, I forgot which. The shell was not updated in the original 3.9 release IIRC.

So not very useful then - and also a disgusting kludge. Though I guess it's better than expecting users to type a 'stack' command before running programs from the CLI, and then unceremoniously crashing when they don't.