Про реентерабельность, малоизвестная фича GCC Опции

[_Pasha]

Только не говорите, что знали и часто пользуетесь!

В общем, тем, кому позарез нада получить сабж, оказалось все очень просто

Код

void somefunc (volatile int param)
{ 
  volatile int local1;
  volatile char local2;
//body
local1 |= param;
return;
}

Как объявили все volatile - компилятор все, включая входные параметры, кладет в стек-фрейм.

И логика проста: без соответствующих оптимизаций функции генерятся реентерабельными. Volatile как-раз и отключает эту оптимизацию локальных переменных.

В общем, в мануале ГЦЦ настолько туманно это описано, что побудило поделиться радостной новостью.

[_Pasha]

Еще одна ТАСКАЛКА (от слова task) получилась.
[attachment=36203:coos.zip]
Несколько слов

Код

typedef struct Tag_TCB
{
    void (*task)(struct Tag_TCB *tcb);
    void *param;
    void *entry;
    struct Tag_TCB *next;
    
    unsigned lock:1;// lock counter
    unsigned stop:1;// stop flag
    unsigned exit:1;// request to delete from list
    unsigned PID:5; // process ID
} TCB_t;

*param - для создания статических локальных переменных с учетом требований реентерабельности.
*entry - для использования переопределяемых точек входа с помощью гнусной фичи labels as values
В общем - мне пока понравилась такая мысль:
с одной стороны - через вызов system() можно отдавать управление другим задачам во время ожидания событий
с другой стороны, чтоб не мучать стек обратными вызовами, можно использовать переопределяемые точки входа и смело выходить из задачи, пока не наступит нужное нам событие.

Как Вам такой гибрид, уважаемый ReAl ?
PS к тому же system() можно спрятать внутри любой реентерабельной функции, а точки входа - низзя.
Теперь в TCB добавить поля для сообщений - и ось на подходе