У меня возник вопрос к уважаемым авторам scmRTOS. Суть его в следующем, зачам нужен глобальный объект Kernel класса TKernel?
Ядро в системе присутствует в единственном экземпляре, других объектов класса TKernel нет и непланируется. При этом каждое обращение вида: Kernel.someField или Kernel.someFunction() приводят к загрузке указателя this, и далеко не всегда компилятор может от него избавиться.
Я провёл небольшой эксперимент: объявил все данные и функции члены TKernel статическими и соответственно изменил обращение к ним с Kernel. на TKernel::. Вся функциональность при этом естественно сохраняется, а размер кода несколько уменьшяатся (от 32 до 150 байт в зависимости от приложения в версии для AVR). Что может быть существенно.
Так вот есть ли (или был ли) какой нибудь сакральный смысл Kernel как таковом?

Так оно исходно и было в первой версии - все члены были статическими. Потом в 2.0 в порядке эксперимента было реализовано с нестатическими членами, эксперименты показали (на MSP430, насколько помню), что проигрыша нет, доступ через this весьма эффективен, а работать с объектом удобнее, чем с совокупностью разрозненных данных (пусть даже объединенных в одном пространстве имен класса). С тех пор просто никто особенно не озабочивался этим вопросом.

У меня есть еще одно (кроме идеологического, приведенного вами) возражение против нестатической реализации: при регистрации процессов идет запись в таблицу адресов, которая является членом класса TKernel, а т.к. порядок инициализации в общем случае не определен, то возникает запись в член-данное неициализированного объекта. На практике тут ничего опасного нет - объект создается статически, значит, память уже выделена, таблица эта в конструкторе не трогается поэтому никаких коллизий не возникает. Но некрасиво и идеологически криво. Видимо, имеет смысл откатить все это хозяйство обратно.

Есть информация по теме. Сейчас озаботились доработкой проекта и выпуском нового релиза. В том числе рассматривается и этот вопрос. Обсуждение активно ведется в группе проекта: scmrtos-ru@googlegroups.com. Оказалось, что переход на статики не везде хорош: в частности, на платформе CortexM3/GCC прилично раздувается код. Если тема еще интересна, можете принять участие в обсуждении и поиске оптимального решения.

К большому сожалению, читать темы на scmrtos-ru@googlegroups.com практически невозможно с сайта, с кодировками полная лажа. Хорошо, что хоть по подписке всё нормально приходит.

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

Могу выложить ветку обсуждения. Если используемая вами почтовая программа понимает формат unix mailbox, то в нём. Если нет, то в html. Как вам удобнее?

Да пожалуйса. Лучше, наверное, в html. Можно сразу мне на почту konstantin.chizhov12 собака gmail.com.

Ушло.

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

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


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

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

АНТОХА, если не трудно, вышли и мне (в html) на адрес: avct собака ipc тчк tsc тчк ru.

Наверное, лучше сюда в архиве выложить.

Да, наверное так проще:  scmrtos_googlegroups.zip ( 253.43 килобайт ) Кол-во скачиваний: 147

Только давайте не будем делать это традицией, и все желающие читать продолжение - срочно подпишутся, хорошо?