Про реентерабельность, малоизвестная фича 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 добавить поля для сообщений - и ось на подходе

[ReAl]

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

Да, system() некоторые вещи сделает красивее, но при этом если несколько задач из списка позовут system() (да ещё и из функции - а иначе кайфу в вызове system() никакого по сравнению с просто установокй метки и возвратом) - стек как-то глубоко пойдёт, надо помнить о возможности.
В этом смысле вместо

Код

STD_TASK(wait2)
{
    ENTRY(step1)
    {
    if(TCNT1 != 0xff00)
            system();
    }    
}

"стандартный" protothread-овский

Код

    PT_WAIT_UNTIL(pt, TCNT1 != 0xff00);

по стеку экономнее, так как ставит метку и даёт возврат из функции, а там уже просматривается список потоков.
Никто не мешает комбинировать.

И управляющую структуру я бы выделил в виде заголовка

Код

typedef struct Tag_TCB_header
{
    void (*task)(struct Tag_TCB *tcb);
    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
   // тут может ещё сразу таймерную переменную для таймаутов/sleep()
} TCB_header_t;

а локальные параметры не через указатель, а как продолжением структуры

Код

typedef struct tag_some_task_tcb
{
    TCB_header_t th;
    unsigned some_param;
    unsigned char some_buf[8];
} some_task_tcb_t;

при обращении не будет лишнего уровня косвенности.

А вообще Vit на protothread-подобных вещах стаю собак сожрал, это с ним обсуждать надо.