Supervisor stack size?

[alpine9000]

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 ?

[meynaf]

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

[alpine9000]

Originally Posted by meynaf

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?

[meynaf]

Originally Posted by alpine9000

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

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

Originally Posted by alpine9000

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

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.

[Thomas Richter]

Originally Posted by alpine9000

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

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.

Originally Posted by alpine9000

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

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.

[Leffmann]

Originally Posted by Thomas Richter

... 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.

[hooverphonique]

Originally Posted by Leffmann

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

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

[meynaf]

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

[alpine9000]

Originally Posted by Thomas Richter

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.

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.

[Bruce Abbott]

Originally Posted by Thomas Richter

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.

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

[Wepl]

AFAIK this is OS4 only.

[Thomas Richter]

Originally Posted by Bruce Abbott

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

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.

[nogginthenog]

Originally Posted by Leffmann

What's the exact format

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

static const char USED min_stack[] = "$STACK:102400";

I never knew about this feature either.

[Thomas Richter]

Originally Posted by nogginthenog

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

static const char USED min_stack[] = "$STACK:102400";

I never knew about this feature either.

A newline at the end of the string is missing.

[hooverphonique]

Originally Posted by Thomas Richter

A newline at the end of the string is missing.

is a classic terminating zero char required also?

[Wepl]

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.

[Thomas Richter]

Originally Posted by Wepl

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.

[Leffmann]

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?

[Thomas Richter]

Originally Posted by Leffmann

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.

[Bruce Abbott]

Originally Posted by Thomas Richter

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.