Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 11

порочный альянс макросов и конечных автоматов под управлением непреодолимой воли

Любая разработка на Си в 2025 году с точки зрения вебских фронтендеров.

Рассчитывал увидеть переключение контекста вручную с сохранением и восстановлением содержимого стека под каждую "параллельную" функцию. Но это конечно потребовало бы ассемблера.

Можно и без асма обойтись - взять setjmp или старый ucontext. Ну такие решения нужны для stackful-корутин, которые часто называют fibers или green threads.

:-) Проснулся чувачок через 20 лет после Protothreads

Опять любители голого Си переизобретают велосипед, причём не самым удобным способом.

В свежем C++ есть поддержка корутин, можно было бы его взять. Автор или об этом не знает (скорее всего), или не осилил запустить компилятор C++ под целевую платформу.

Ручное сохранение состояния - тоже так себе идея. Можно было бы даже на голом Си реализовать вместо этого stackful корутины. Они достаточно просты - при старте надо выделить блок памяти под стек, при yield сохранить текущее состояние регистров, а при resume восстановить его. Последнее требует однократного написания небольшого количества ассемблерных вставок, которые можно далее использовать во всех корутинах.

А под целевую платфлому есть компилятор самых свежих крестов?

При желании clang можно заставить работать практически под какую-угодно платформу. Но видимо желания/мотивации у автора статьи не было и навелосипедить что-то отдалённо-похожее на нормальные корутины через макросы оказалось проще.

Ну и особой свежести стандарта C++ не требуется, корутины добавили в стандарт C++20, сейчас же актуален C++23 и C++26 уже на подходе.

  1. Решил одну проблему, заменив С на С++.

  2. Теперь у тебя 1000 проблем.

Зачем брать монструозный C++, если можно взять Rust или Zig? Я вот на C++ с универа не писал, и вернуться туда даже при желании потребует больше времени, чем освоится с тем же Zig.

Помню, в одной из контор, где я работал, чувак написал подобную штуку на макросах для обработки программной I2C шины в прерываниях.

Мержревест был категорично остановлен мною И код отправился в мусорку. А чувак пошёл писать нормальный обработчик.

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

Пришлось реально считать по тактам, когда использовали AVRки с их прерываниями. STMки с их приоритетом прерываний и DMA здорово выручили, благо они уже тогда более-менее были доступны. Но сам факт, такой код, как вы и сказали, пришлось бы переписывать

По сабжу: никогда не пробовал Rust, интересно было бы посмотреть, если бы автор статьи накидал для сравнения

Зарегистрируйтесь на Хабре, чтобы оставить комментарий