[Arlleex 183]

14 минут назад, AHTOXA сказал:

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

На самом деле, если последить за движением рук плюс-плюс-сообщества (например, Яндекс-практиков), то вроде и много довольно здравых идей. Но реализация настолько ужасающая, что банально не хочется всех этих хитроумных конструкций у себя в коде. Я за некий средний оптимум. Полухин в яндексе двигает идеи в комитет по стандартизации C++, а он какой-то фанатик на своем уме, иногда смотришь видео с их нововведениями в язык, и в обморок падаешь, потому что он несет только ему понятную идею. Показывает скрин с кодом и самодовольно ржет в стиле "смотрите, ну как вам я наговнокодил?". В зале тишина - никто не понимает, что это такое. В конце, как обычно, люди задают простые вопросы, потому что ничего не поняли. Но особенно ржачно, когда я открываю их приложение яндекс-такси, вызываю бричку, она рисуется на карте. Выключаю экран. Потому включаю - бричка по пути ко мне *резко* разворачивается в приложении и со скоростью света летит обратно в точку отправления, а потом снова возвращается и уже едет нормально. И это уже давно известный баг - но нет, им бы не баги чинить, а C++ костылями обставлять.

Эх, наболело.

[jcxz 241]

17 минут назад, Arlleex сказал:

На самом деле, если последить за движением рук плюс-плюс-сообщества (например, Яндекс-практиков), то вроде и много довольно здравых идей. Но реализация настолько ужасающая, что банально не хочется всех этих хитроумных конструкций у себя в коде. Я за некий средний оптимум. Полухин в яндексе двигает идеи в комитет по стандартизации C++, а он какой-то фанатик на своем уме, иногда смотришь видео с их нововведениями в язык, и в обморок падаешь, потому что он несет только ему понятную идею. Показывает скрин с кодом и самодовольно ржет в стиле "смотрите, ну как вам я наговнокодил?". В зале тишина - никто не понимает, что это такое. В конце, как обычно, люди задают простые вопросы, потому что ничего не поняли.

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

А нам, практикам, важнее ехать. Чем шашечки. Шашечки оставим диванным теоретикам...  

Если код понятнее и прозрачнее пишется при помощи плюсов - используем их; если нет - ну их нафик. Не нужно слепо следовать догмам. Чай не Средние Века на дворе.

[AHTOXA 18]

49 минут назад, tonyk_av сказал:

Можно пояснить, что это такое и как реализуется на практике применительно к ARM? Или ссылку для чтения.

Вот тема 1. Вот тема, в которой раскрываются неоднозначности и сложности использования LDREX/STREX. Можно также использовать встроенные в компилятор функции (инстринсики/builtins), вот например для gcc.

36 минут назад, Arlleex сказал:

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

Полухину просто нравятся головоломки. Я его выступления смотрю как некое шоу:) Но в целом он, по-моему, продвигает в стандарт здравые вещи.

Ну и по поводу тенденций развития. Начиная с c++11, и до c++17 включительно мне почти всё нравится. В 20 тоже есть хорошие штуки, но я пока не углублялся. Понятно, что совсем без странных штук не обойтись, но их можно просто не использовать - парадигма "ты платишь только за то, что используешь" более-менее поддерживается.

 

 

[tonyk_av 44]

40 minutes ago, jcxz said:

Почитать можете в мануалах на ядро Cortex-M3/M4. Описание команд LDREX/STREX/CLREX.

Понял. Читал про такие, но не встречал примеров использования. Разберусь при случае, ибо, да, полезная штука. Выигрыш от использования в итоге вряд ли будет заметен на общем фоне, но коли есть, то грех не использовать.

[jcxz 241]

6 минут назад, tonyk_av сказал:

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

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

Кроме того: преимущество эксклюзивного доступа перед критической секцией - это неблокирующая операция. А значит - не вызывает увеличение задержки обработки других прерываний. Что иногда важно. Иногда даже - критически важно. В некоторых задачах.

[tonyk_av 44]

1 minute ago, jcxz said:

преимущество эксклюзивного доступа перед критической секцией - это неблокирующая операция.

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

[jcxz 241]

7 минут назад, tonyk_av сказал:

Ещё не всё прочитал, но, похоже, далеко не всегда это хорошо.

Ну - всему своё место конечно.

7 минут назад, tonyk_av сказал:

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

Так и операции эксклюзивного доступа это гарантируют. Что ваша R-M-W-операция не будет прервана.

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

 

PS: Кстати - где-то в MSDN, при описании аналогичных функций x86-процессоров, читал совет: "предпочитать использовать как раз такие операции эксклюзивного доступа (только на x86) везде где можно; вместо критических секций". И полностью с ним согласен. Там (под Win) они дают ещё бОльший выигрыш, чем у нас на ARM.

[Arlleex 183]

2 часа назад, jcxz сказал:

Так и операции эксклюзивного доступа это гарантируют. Что ваша R-M-W-операция не будет прервана.

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

Насчет спин-блокировки: у нее есть тоже некоторые минусы - а именно недетерминированность времени входа в состояние "ресурс захвачен". При высокочастотном прерывании, например, в том же Cortex-M реализация может сбрасывать флаг эксклюзивного доступа. Из-за этого можем некоторое время повисеть в цикле попытки захвата спина.

[EdgeAligned 85]

Опять ушли на отвлеченные темы. Видимо, на этом форуме мало кто всерьез разбирается с С++...

3 часа назад, Arlleex сказал:

иногда смотришь видео с их нововведениями в язык  и в обморок падаешь

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

Возвращаясь к теме пинов на С++.

Есть такая интересная штука при описании класса одиночного пина

static constexpr uint8_t Position = PinPos;
using PortType = TPort;

она позволяет получить доступ к шаблонным параметрам класса и на её основе можно оптимально скомпоновать виртуальный порт из разбросанных по разным местам физических пинов. Всё бы круто и няшненько было, но не обошлось без бочки дегтя в ложке меда - когда попытаешься сделать класс виртуального порта с произвольным числом пинов, натыкаешься на проблему недопиленного вариативного шаблона. Сделать то можно, но через опу - нужны вспомогательные классы для "просмотра" вариативного шаблона по принципу цикла while. 
В принципе, я сделал, работает, и довольно классная штука получается в целом. Но вспомогательного текста многовато. И новые редакции языка до сих пор не позволяют выполнить эту штуку без лишнего текста.

[x893 60]

Вся суета с железом занимает максимум 5% от всего остального.

Геммороится из-за этого  с шаблонами и прочей лабудой нет никакого смысла.

А дальше описания ног, что то не идёт дальше у мастеров программирования.

 

[tonyk_av 44]

9 hours ago, x893 said:

Геммороится из-за этого  с шаблонами и прочей лабудой нет никакого смысла.

А дальше описания ног, что то не идёт дальше у мастеров программирования.

Абсолютно согласен. Для меня важно, чтобы работа с ногами была простой, ибо 99% и у меня, и у CPU уходит на другие задачи.

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

[EdgeAligned 85]

Ну не сказать чтобы уж малоактуален вопрос ногодрыга. С электромеханическими кнопками и одиночными светодиодами, надеюсь, многие из вас имели дело, не так ли? 🙂 К тому же, многие виды дисплеев имеют вход D/C для ногодрыжного переключения типа данных с SPI. А ведь есть еще и исполнительные устройства, управляемые одиночными пинами. Так что рано ногодрыг списывать со счетов.

А вот вам практическая загадка на тему темы ++:
есть вот такая штука:

struct A {
void Foo() { }
};

template<typename C>
struct B {
using D = C;
void Foo() { }
};

struct C {
void Foo() { }
};

struct D {
void Foo() { }
};

struct E {
void Foo() { }
};

int main()
{
	using E = B<A>::D;
	E e;
	e.Foo();

Внимание, знатоки, вопрос: какой из методов Foo() вызовется для объекта e?
Отвечает <typename Александр_Друзь> 🙂

(ответ обоснуйте)

[dimka76 62]

On 9/12/2024 at 6:28 PM, EdgeAligned said:

 К тому же, многие виды дисплеев имеют вход D/C для ногодрыжного переключения типа данных с SPI. 

Если МК имеет интерфейс внешней параллельной памяти, то D/C решается аппаратно.
А если МК не имеет интерфейс внешней параллельной памяти, то там вся шина будет ногодрыгом.

On 9/12/2024 at 6:28 PM, EdgeAligned said:

Внимание, знатоки, вопрос: какой из методов Foo() вызовется для объекта e?

Запустить в отладчике и посмотреть )))

[EdgeAligned 85]

Нет, я то ответ на вопрос знаю, а задачку задал как раз для вас, уважаемые знатоки 🙂 Тема то про ++ же. Ну, кто в ++ разбирается, мм? 🙂 

14 минут назад, dimka76 сказал:

Если МК имеет интерфейс внешней параллельной памяти, то

то SPI не подключается к ней. 

[Arlleex 183]

2 часа назад, EdgeAligned сказал:

Внимание, знатоки, вопрос: какой из методов Foo() вызовется для объекта e?
Отвечает <typename Александр_Друзь> 🙂

(ответ обоснуйте)

Будет вызов A. А что тут обосновывать? Есть более интересные примеры...