Сопрограммы в языке программирования C

[Dale]

парень который до этого придумывал аналогичный по функциям алгоритм, писал на асемблере и отлаживал сразу в железке - два месяца смеялся и говорил что как я делаю -  невозможно....
а потом съел собственную шляпу, как обещал) он вообще не верил что такой подход сработает....
хотя я сам не очень ожидал ТАКОГО результата... глаза боятся - руки делают)) а может повезло просто)))

А где же тут везение? Самый логичный подход - сначала проработать алгоритмическую часть на хорошо известной и оснащенной платформе, а потом реализовать рабочий алгоритм на целевой платформе. По-моему, гарантированный путь к успеху.

Мне скорее непонятна логика смешливого парня. Если ему неясно, что ваш подход к решению задачи не просто возможен, а еще и логичен и правилен, то ему придется переходить на шляпную диету, что вряд ли пойдет на пользу организму, подорванному отладкой ассемблерной программы на железяке (бррр, как представлю, так мороз по коже)...

Самое интересное для меня здесь - какой инструментарий использовался для тестирования? Я искал такой фреймворк самостоятельно, но ничего подходящего найти не удавалось: практически все ориентировано на объектно-ориентированные языки, для чистого С ничего не попадалось. Вот только в книге Греннинга нашел ссылку на Unity, сейчас пытаюсь его освоить.

[Dale]

В принципе морально готов приступить к воплощению плана (https://forum.shelek.ru/index.php/topic,25760.msg246872.html#msg246872)

Возможно сделать это двумя путями: либо строго и формально, либо в доступной форме, с применением аналогий и иллюстраций. Во втором случае будет менее научно, но доступно для новичков.

Какой путь выберем?

[RXL]

Я думаю, что лучше умеренно наглядно. И круг понимающих будет шире, и не слишком нудно будет писать

[Ochkarik]

Dale, нет, минимально он, часть алгоритма запускал в нашей среде...  основную часть. беда в том, что качество алгоритма по этой минимальной части предсказать сложно. дальше он не пошел, поскольку С++ он не очень знает, и изучать не хотел. да и алгоритмика не его основная обязанность.
а парень просто не верил в возможности моделирования. а по мне, грамотно составленная модель не должна ничем отличатся от реальности. иначе это хреновая модель.
а везение - в том что все получилось. я по началу думал просто базовую часть алгоритма проработать на x86. я до этого с DSP процессорами дела не имел.
фреймворк - я уже писал это CSS от TI. конкретно под их процессоры. но это просто аналог студии с эмуляторами процессоров. в алгоритме не требовалось обслуживать перефирию. только получать данные с порта и уложится по тактам между прерываниями. она поддерживает как C так и C++. плюс RT-библиотеки эмуляции работы с файлами. плюс всякие профайлер и прочие мелочи.
честно говоря, я не вижу проблемы использовать С++ и отлаживаться в любой удобной среде. функции плюсов можно и не использовать - никто не мешает потом тупо сменить расширение файла)

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

по мне тоже лучше наглядно... чтоб не как в анекдоте:
"барин, про паровоз то я все понял... только вот куда лошадь запрягать?"

[Dale]

Я думаю, что лучше умеренно наглядно. И круг понимающих будет шире, и не слишком нудно будет писать

по мне тоже лучше наглядно... чтоб не как в анекдоте:
"барин, про паровоз то я все понял... только вот куда лошадь запрягать?"

ОК, тогда следите за новостями в теме. Тема интересная, скучно не будет ни мне писать, ни вам читать.

а парень просто не верил в возможности моделирования. а по мне, грамотно составленная модель не должна ничем отличатся от реальности. иначе это хреновая модель.

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

фреймворк - я уже писал это CSS от TI. конкретно под их процессоры. но это просто аналог студии с эмуляторами процессоров.
...
а функции тестирования - они все равно задачей определяются. мне было удобно работать через тестовые массивы, сравнивая результаты контрольных точек. кому то может быть что то еще потребуется.... тут не знаю, есть ли универсальные методы. по моему сугубо от задачи.

Нет, я в данном случае о другом - об инструментарии модульного тестирования. В программировании есть устоявшиеся методики тестирования, которые мне (да и не только мне) хотелось бы перенести в область firmware. Они требуют специального фреймворка. Но об этом еще будет отдельный разговор, это сама по себе обширная тема. Сначала закроем тему о сопрограммах, чтобы не оставалось темных пятен. Не будем распыляться.

[Sla]

К сожалению, на практике воспользоваться преимуществами сопрограмм проблематично, поскольку традиционные языки программирования высокого уровня не обеспечивают поддержки этой концепции

Это мне напомнило одно решение

Код:

Label1:
          Команда
          Команда
          Команда
Label2:
          Команда
          Команда
          Команда
Label3:
          Команда
          Команда
          Команда
Label4:
          Команда
          Команда
          Команда
ret

Call Label1
Call Label2
Call Label3
Call Label4

[RXL]

Слав, это у тебя пример ассемблера?

[Sla]

Точно
Ошибку с меткой исправил. (копипаст)

[RXL]

Я на ассемблере для 8051 использовал немного другой принцип - через таблицы переходов по смещению. Дело было давно и синтаксис уже почти забыл. Условно, это можно так описать:

Код: (ASM)

sub1: ; общая точка входа
  mov reg, [state] ; состояние автомата
  add reg,  jump_table - $ + 2
  mov reg, [PC + reg] ; получаем смещение
  add reg,  end_jump_table - $ + 2
  sjmp reg ; переходим

jump_table:
  db point1 - end_jump_table, point2 - end_jump_table, point3 - end_jump_table
end_jump_table:

point1: ...
  ret
point2: ...
  ret
point3: ...
  ret

Для небольшого количества состоянии и короткого кода вполне подходило. Для более длинного кода приходилось делать ступенчатый переход: сперва по таблице, а потом ljmp в другую точку. Конечно, можно было хранить полноценные 16-битные таблицы, но это из-за экономии памяти и простоты работы с 8-битными данными (с 16-битами там работала всего одна пара регистров и PC).
Главное достоинство таблиц переходов - в точном подсчете количества тактов (RT программа была).

В общем, я описал принцип: одна точка входа, N подпрограмм. Это подходит под сопрограммы?

[Sla]

RXL, Здесь идея была в том, что есть повторяющиеся части
можно было бы организовать следующее

Код:

l1:
    Mov
ret
l2:
    Call l1
    Add
ret
l3: 
    call l1
    call l2
    sub
ret

Call l1
Call l2
Call l3

Таким образом появляется 2 лишних рета, а это время и место





Добавлено через 10 минут и 47 секунд:
RXL, дело в том, что использование таблиц перехода требует очень внимательного подхода в проектировании системы.
51-ый имеет 255 активных команд и в случае неверного перехода, начинает выполняться неизвестно какой код.

Если таблица переходов и условия выровнены, то это хорошо, а если нет? требуется выравнивание.

Например, ты получаешь на вход сигнал (0, 1, 3, 4)
Соответственно ты  составляешь таблицу переходов и пишешь процедуры для каждого сигнала.
А  вдруг ты с порта получаешь несуществующий сигнал, (7). Твои действия?
Ошибка неявная, но опасная - таких вещей делать нельзя.

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

зы, давай не будем трогать 51-й

[RXL]

У меня сигнал не внешний - это было внутреннее состояние автомата и изменялось только внутри.
В принципе, да - геморрой с таблицами был. Особенно когда не хватало 8-битного смещения.

В общем, перечитал Вики и понял различие.

Добавлено через 15 минут и 13 секунд:
Получается, что функции поиска подстрок по разделителю подходят под определение сопрограммы. Ведь между вызовами контекст сохраняется (в статических переменных внутри или в параметрах). Логично?

[Dale]

Я так понимаю, что сперва в релиз отправляем эту статью: https://forum.shelek.ru/index.php/topic,25445.0.html

В принципе, без разницы. Они совершенно не пересекаются по тематике, и ни одна из них не поясняет материал другой. Так что чисто технический вопрос, публикуем, что удобнее. Или что вызывает меньше нареканий насчет оформления.

В "Сопрограммах" я еще не определился со стилем оформления ключевых слов вроде "switch". Сейчас они вроде хорошо визуально выделяются, но выглядят неэстетично.

P.S. Хотя с учетом того, что к "Сопрограммам" я сейчас для ясности дописываю "приквел", лучше, чтобы публикации "Сопрограмм" и комментариев к ним шли по времени подряд.

[Dale]

Это мне напомнило одно решение ...

Аналогичная конструкция была в языке Fortran, по крайней мере до версии Fortran77 включительно. Дальнейшими не интересовался. Там можно было написать:

Код:

SUBROUTINE A(X, Y)
...
ENTRY B(X)
...
ENTRY C
...
RETURN

ENTRY - это дополнительные точки входа в подпрограмму, наподобие тех, что сделаны в ассемблерном примере. Их можно вызывать так же точно, как и обычную подпрограмму.

Потом чистоплюи от структурного программирования провозгласили, что наличие нескольких точек входа и выхода в подпрограмме нарушает основные принципы СП, и дополнительные точки входа попали под запрет. Хотя, во-первых, C попадает в категорию языков программирования высокого уровня с большой-пребольшой натяжкой, и в нем для сохранения эффективности в подобных случаях могли бы и оставить; во-вторых, return можно ставить хоть на каждой строчке функции, не нарушая синтаксиса языка, и об этом как-то конфузливо умалчивается; в-третьих, пресловутый goto таки жив до сих пор, и мир не перевернулся, даже неохотно допускается, что порой он может быть уместен.

[Dale]

...
В общем, я описал принцип: одна точка входа, N подпрограмм. Это подходит под сопрограммы?

Вряд ли. Мне этот фрагмент больше показался похожим на хорошо оптимизированный switch.

Получается, что функции поиска подстрок по разделителю подходят под определение сопрограммы. Ведь между вызовами контекст сохраняется (в статических переменных внутри или в параметрах). Логично?

А тут зависит от реализации. Если функции передаются строка и разделитель, а она выдает массив подстрок, то определенно нет. А вот если функция при каждом вызове возвращает очередную подстроку, то это формально похоже на сопрограммы.

"Формально похоже" - потому, что сопрограммы - это не только механизм, но и способ использования. Приставка "со" как бы намекает, что они полностью симметричны и равноправны; одна из них, выполняя свою работу, не знает, что делает другая. Например, в примере из статьи у нас первая сопрограмма делает декомпрессию сжатого формата и передает результат парсеру; парсер не знает, что исходные данные сжаты, а декомпрессор не знает, что эти данные парсятся. Это похоже на конвейер

Код:

decompress | parse

, но только в "легковесной" реализации, без процессов и канала между ними. Если мы заменим наш декомпрессор на разархиватор ZIP или, скажем, на декодер шифрованных сообщений, нам не придется трогать парсер, ведь ему все равно, откуда на вход поступает обработанный поток.

Точно так же, если вместо парсера мы включим счетчик слов/предложений/знаков препинания или программу шифрации сообщений, наш декомпрессор никак не изменится, потому что он ничего не знает о своей сопрограмме.

В примере с функцией расщепления строки по разделителю такой симметрии нет: фунция не самостоятельна и лишь обслуживает вызывающую, возвращая ей результат. В данном случае мы не могли бы записать это в виде конвейера, как в предыдущем. Поэтому полноценными сопрограммами они не являются; хотя одна из них и сохраняет состояние между вызовами, но этого недостаточно. Да это и логично, ведь тогда мы бы любую функцию, где есть хоть одна переменная static, могли бы считать сопрограммой. А это более экзотическая штука.

Я планирую следующую статью посвятить обзору синхронизации процессов и более подробно разобрать классическую задачу "производитель-потребитель". Тогда по идее должно начать проясняться. А еще в следующей, пожалуй, опишу решение этой задачи через сопрограммы. Вот тогда, думаю, будет уже полная ясность.

[npak]

Я бы не стал призывать отменить процедуры и перейти на со-процедуры.

По-моему, процедуры удобны для разбиения сплошного потока управления на меньшие кусочки. Что для вас проще анализировать, сопровождать, отлаживать - одну функцию на 300 строк или десять функций по 30 строк? Мое сугубое ИМХО, что проще работать с функциями меньшего размера. Такими, чей код целиком умещается на экран. В этом случае использование со-процедур не дает никаких преимуществ перед обычными процедурами с передачей данных через стек.

Другое дело, когда программа логически представляет собой несколько потоков управления. Как в классическом ООП - каждый объект есть отдельная независимая активная сущность, а взаимодействуют объекты через обмен сообщениями. В этом случае со-процедуры дают возможность организовать внутри одного физического потока (thread) любое количество логических потоков (fiber, soft-thread).

Например, так устроен фреймворк моделирования железа (и firmware) SystemC (библиотека классов и макросов С++). В этом фреймворке система представляет собой набор модулей, соединенных каналами. Обработчик событий модуля большую часть времени проводит внутри функции ожидания событий wait():

Код:

 while(true) { wait(); doSomth(); }

Выглядит это точь в точь блокировка потока в многопоточном программировании. Но благодаря тому, что wait внутри содержит вызов со-процедуры планировщика такую "многопоточность" можно реализовать внутри одного физического потока.

Резюме: обычные функции нужны для декомпозиции алгоритма на более мелки части. Со-процедуры для передачи сообщения из одной активной сущности в другую

[Dale]

Я бы не стал призывать отменить процедуры и перейти на со-процедуры.

Я бы тоже не стал, естественно.

Дело в том, что переведенная статья оказалась как бы вырвана из контекста. Я заинтересовался ей потому,  что занимаюсь разработкой firmware для микроконтроллеров с довольно скромными ресурсами - несколько килобайт памяти программ (в топовых моделях до 256, но чаще 4, 8, 16...), считанные килобайты (а то и доли килобайта) оперативной памяти. В этих условиях использование операционной системы с поддержкой процессов, потоков, синхронизации, средств обмена сообщениями и т.д. - непозволительная роскошь. Уже хотя бы потому, что контексты процессов/потоков нужно где-то сохранять, а у нас оперативной памяти с гулькин нос.

С другой стороны, использование таких средств для задач реального времени жизненно необходимо, поскольку монолитное приложение с опросом событий и вызовом соответствующих подпрограмм для их обработки получается весьма неуклюжим.

Сопрограммы я рассматриваю как один из вариантов кооперативной мультизадачности для таких автономных встроенных программ, а способ их организации в статье - как вариант с наименьшими накладными расходами. Это ни в коей мере не общие рекомендации для написания программ общего назначения - для этого есть куда более подходящие средства.

По-моему, процедуры удобны для разбиения сплошного потока управления на меньшие кусочки. Что для вас проще анализировать, сопровождать, отлаживать - одну функцию на 300 строк или десять функций по 30 строк? Мое сугубое ИМХО, что проще работать с функциями меньшего размера. Такими, чей код целиком умещается на экран.

Тут, пожалуй, спорить не о чем, классики давно разложили тему управления сложностью программ по полочкам, даже в здешней библиотеке есть переводы Дейкстры на эту тему. Но в данном случае тема сложности как бы ортогональна предмету статьи, особенно с учетом предыдущего замечания.

В этом случае использование со-процедур не дает никаких преимуществ перед обычными процедурами с передачей данных через стек.

Смотря с какой целью их вводить в программу. Если с целью управления сложностью - вопрос спорный; можно подобрать примеры и "за", и "против". Тем более что сопрограммы для многих непривычны, как показало обсуждение, а непривычным инструментом пользоваться труднее, даже если он равноценен. Но, повторюсь, для данной конкретной задачи они выбраны по другому критерию.

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

Это гораздо ближе. Только у меня на самом деле и потока-то нет, если не считать зашитую в контроллер программу единственным потоком.

Резюме: обычные функции нужны для декомпозиции алгоритма на более мелки части. Со-процедуры для передачи сообщения из одной активной сущности в другую

Это вполне годится в качестве эпиграфа к статье

Собственно, я именно вторую его часть и проталкиваю в данном обсуждении. По первой у нас как-то разногласий не возникло.

[npak]

Я бы не стал призывать отменить процедуры и перейти на со-процедуры.

Я бы тоже не стал, естественно.

Дело в том, что переведенная статья оказалась как бы вырвана из контекста. ...
Сопрограммы я рассматриваю как один из вариантов кооперативной мультизадачности для таких автономных встроенных программ, а способ их организации в статье - как вариант с наименьшими накладными расходами. Это ни в коей мере не общие рекомендации для написания программ общего назначения - для этого есть куда более подходящие средства.

Вот об этом, ИМХО, и стоит писать в первую очередь. Сначала задать контекст, затем рассмотреть плюсы и минусы процедур и со-процедур в этом контексте.

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

Это гораздо ближе. Только у меня на самом деле и потока-то нет, если не считать зашитую в контроллер программу единственным потоком.

Именно его я бы и посчитал за поток.

Резюме: обычные функции нужны для декомпозиции алгоритма на более мелки части. Со-процедуры для передачи сообщения из одной активной сущности в другую

Это вполне годится в качестве эпиграфа к статье

Собственно, я именно вторую его часть и проталкиваю в данном обсуждении. По первой у нас как-то разногласий не возникло.

Гут Вот об этом и надо написать, либо во введении к переводу, либо в заключении. Но лучше во введении, чтобы обычные люди, не погруженные в проблематику околожелезного программирования, не терялись от напора автора статьи и не считали его идиотом, которому неймется внедрять всякую абстрактную хрень.

[npak]

занимаюсь разработкой firmware для микроконтроллеров с довольно скромными ресурсами - несколько килобайт памяти программ (в топовых моделях до 256, но чаще 4, 8, 16...), считанные килобайты (а то и доли килобайта) оперативной памяти. В этих условиях использование операционной системы с поддержкой процессов, потоков, синхронизации, средств обмена сообщениями и т.д. - непозволительная роскошь. Уже хотя бы потому, что контексты процессов/потоков нужно где-то сохранять, а у нас оперативной памяти с гулькин нос.

С другой стороны, использование таких средств для задач реального времени жизненно необходимо, поскольку монолитное приложение с опросом событий и вызовом соответствующих подпрограмм для их обработки получается весьма неуклюжим.

Dale, вам знакомо такое слово TinyOS? Это язычок и набор библиотек для разработки программ для smart dust - микроконтроллеров с батарейкой, сенсором и беспроводной сетью (стандарта IEEE 802.15.4).
Если из TinyOS выбросить часть, отвечающую за беспроводную сеть, останется прикольный язык и аккуратная архитектура и методология компонентного проектирования firmware.

[Dale]

Вот об этом, ИМХО, и стоит писать в первую очередь. Сначала задать контекст, затем рассмотреть плюсы и минусы процедур и со-процедур в этом контексте.

Гут Вот об этом и надо написать, либо во введении к переводу, либо в заключении. Но лучше во введении, чтобы обычные люди, не погруженные в проблематику околожелезного программирования, не терялись от напора автора статьи и не считали его идиотом, которому неймется внедрять всякую абстрактную хрень.

Так вся штука в том, что сам автор статьи и не собирается программировать железо. В данном случае он гордится собой, что смог приспособить устройство Даффа под конечный автомат для хранения состояния сопрограммы после потери управления.

Это уже я решил, что это очень пригодится для железячных программ, когда случайно наткнулся на статью. И возникает проблема курицы и яйца: если публиковать сначала перевод, потом свои комментарии, то при чтении перевода все выглядит либо слишком заумным, либо и вовсе надувательством, которое вроде и компилироваться бы не должно, но по недоразумению ошибок не выдает. Если же начать комментировать еще не опубликованное, получается еще более странно. Тем более что начинать приходится уж больно издалека: чтобы сопрограммы обрели смысл, нужно описать проблему "производитель-потребитель", а для этого сначала описать принципы синхронизации, а для этого сначала описать взаимодействие процессов, хотя бы примитивно и неформально... Будет еще более непонятно, с чего бы это я взялся за такие прописные истины, которые все и так знают (или по крайней мере думают, что знают). И нескольких абзацев введения или предисловия тут никак не хватит.

[Dale]

Dale, вам знакомо такое слово TinyOS? Это язычок и набор библиотек для разработки программ для smart dust - микроконтроллеров с батарейкой, сенсором и беспроводной сетью (стандарта IEEE 802.15.4).

Очень поверхностно. Пока остановил выбор на FreeRTOS, потому что у меня более-менее целостный набор инструментов только начинает собираться вокруг GCC (я только начинаю работать с firmware). Боюсь переходить на среду разработки с другим языком, потому что едва нашел инструменты для юнит-тестирования и документацию к ним.

[npak]

И возникает проблема курицы и яйца: если публиковать сначала перевод, потом свои комментарии, то при чтении перевода все выглядит либо слишком заумным, либо и вовсе надувательством, которое вроде и компилироваться бы не должно, но по недоразумению ошибок не выдает.

Правильно. Вы взяли очень узкую штучку, которая сама по себе принадлежит к малоизвестной технике программирования. Читатели Шелека, в большинстве своём, в глаза не видели со-процедур и никогда не пользовались setjmp/longjmp. Поэтому сначала нужно ввести со-процедуры, зачем это нужно. Потом обсудить, как это можно реализовать (например, сохранением/восстановлением регистра стека ручками). И только после того, как публика подготовлена и все поняла, можно переходить к шаманской технике, предложенной в статье.

ИМХО, разумеется.   

[Dale]

Бегло посмотрел материалы по TinyOS. Похоже, насчет Tiny они все же слукавили, там в аппаратных требованиях от AVR - модель Mega128, из числа топовых. Большинство моделей этого семейства существенно слабее.

[Dale]

...сначала нужно ввести со-процедуры, зачем это нужно. Потом обсудить, как это можно реализовать (например, сохранением/восстановлением регистра стека ручками). И только после того, как публика подготовлена и все поняла, можно переходить к шаманской технике, предложенной в статье.

Это тема для не слишком тонкого учебника, пожалуй. Предисловием тут не отделаешься.

Да и массовой вряд ли станет. Ведь в большинстве языков программирования сопрограммы попросту недоступны. Я еще студентом реализовывал их на "больших" машинах, но без ассемблера обойтись не удавалось. Хотя мне и попадалось заявление, что введение yield в C# позволяет использовать сопрограммы, но это больше похоже на провокацию.

[npak]

Это тема для не слишком тонкого учебника, пожалуй. Предисловием тут не отделаешься.

Вы посмотрите на название темы: "Сопрограммы в языке программирования C"

Когда я увидел такое название, решил, что в теме рассказывают о том, как реализуются сопрограммы в Си. Вообще - обзор существующих методов. Название-то общее.

Если же вы собираетесь писать статью о менее широком предмете, то так и нужно писать в заглавии: "Применение устройства Даффа для реализации сопрограмм в С". Даже если автор исходной статьи написал заглавие с претензией на общность.

[Sla]

npak, это перевод - такое название у автора.

[npak]

Sla, я так и понял. Теперь призываю Dale сделать авторизованный перевод, как минимум поменяв название и, как максимум, дописав предисловие и заключение.

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

С другой стороны, на четырехкилобайтных ППЗУ и не так раскорячишься.

[Dale]

Если же вы собираетесь писать статью о менее широком предмете, то так и нужно писать в заглавии: "Применение устройства Даффа для реализации сопрограмм в С". Даже если автор исходной статьи написал заглавие с претензией на общность.

Оно-то, конечно, так... Но с другой стороны:

Правильно. Вы взяли очень узкую штучку, которая сама по себе принадлежит к малоизвестной технике программирования. Читатели Шелека, в большинстве своём, в глаза не видели со-процедур и никогда не пользовались setjmp/longjmp.

А теперь возьмем множество тех, кто знаком с сопрограммами, и найдем его пересечение с множеством тех, кому что-то говорит сочетание слов "устройство Даффа". Добавим пару-тойку любопытствующих. Это и будут все, кто рискнет прочитать статью. Но у нас ведь форум, а не академический журнал, который издается не для читателей, а для тех, кому нужно набрать публикации.

Уж лучше по честному, на ассемблере с заменой контекста.

Да, но за эту честность придется заплатить отсутствием переносимости. На рынке микроконтроллеров нет такого единодушия, как среди десктопов. Если по какой-то причине придется перейти на другое семейство контроллеров, все ассемблерные достижения придется отправить на помойку.

[npak]

Как скажете.

я давно не был на форуме, поэтому процедуру рецензирования статей не знаю. Но если это нужно как-то зафиксировать, то моё мнение таково:
1. Статья очень интересная, но запутанная. Для неподготовленного читателя непонятная. Я, например, въехал в суть дела только со второго раза. Но надо сказать - въехав, восхитился изобретательностью автора.
2. Рекомендую изменить название на менее общее или расширить содержание статьи до охвата содержания.

Уж лучше по честному, на ассемблере с заменой контекста.

Да, но за эту честность придется заплатить отсутствием переносимости. На рынке микроконтроллеров нет такого единодушия, как среди десктопов. Если по какой-то причине придется перейти на другое семейство контроллеров, все ассемблерные достижения придется отправить на помойку.

Да, это именно так делается. Создается ассемблерное микроядро, в которое запрятаны все хакерские штучки, вроде переключения контекстов и обмена сообщениями, а весь остальной код пишется в машинно-независимом виде на Си. При переезде на новую платформу нужно переписать микроядро, от этого никуда не деться.

[Ochkarik]

npak, как вариант, почему бы тогда не попробовать написать микроядро на Си? по крайней мере платформо-независимую часть

[Dale]

1. Статья очень интересная, но запутанная. Для неподготовленного читателя непонятная.

Уже понемногу начали подготавливать (см. наброски новой статьи в этом же разделе). Неформально, конечно же.

Я, например, въехал в суть дела только со второго раза. Но надо сказать - въехав, восхитился изобретательностью автора.

Согласен, не беллетристика. Сам это оценил, когда попался на глаза оригинал. Но ведь стоит потраченных усилий.

2. Рекомендую изменить название на менее общее

Если большинство будет "за", то я не против, конечно... Хотя в заголовке обещали сопрограммы на С, начинаем читать - а там и правда сопрограммы на C. Вроде и не обманули.

или расширить содержание статьи до охвата содержания.

Если расширить, это уже будет статья не Тэтхема, а моя. Напишу свою собственную уже на основе реального, а не надуманного примера, если получится применить этот прием в прошивке задуманного устройства. Иначе получится как в одесском анекдоте про песни "Битлз" в перепевке Рабиновича, а не хотелось бы.