Общаемся обо всём!

[Aether]

Можно ссылочку?

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

"... у некоторых современных самолётов ..." обобщением бы не было, так как есть отдельный класс СВВП, например,  https://ru.wikipedia.org/wiki/Hawker_Siddeley_Harrier, который выпускался серийно с 1967 года. И то, это не делает их кирпичами.

Не просто готов, но и делаю это весь рабочий день кряду.

Поэтому я и написал, что ответ получил.

Ну никак не поспевает открытая Ардуина за нашими потребностями...

Один паломник поинтересовался у мудреца:
- Долго ли ждать перемен к лучшему?
- Если ждать, то долго! - ответил мудрец.

[Dale]

"... у некоторых современных самолётов ..." обобщением бы не было

Да, действительно, проглядел. Оставил лазейку, и отсутствие явного обобщения "у всех самолетов" тут не оправдание, каюсь.

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

- Если ждать, то долго! - ответил мудрец.

Ну а вот если не ждать? Столь же долго, или есть реальная и конструктивная альтернатива, кроме как нетерпеливо ерзать?

[RXL]

PS: RXL, с вертолётами ты уже играл, будешь переходить к моделям самолётов собственного изготовления?

Конструкции самолетов — это моя специальность, по которой ни дня не работал. В середине 90-х молодые специалисты отечественной авиации были не нужны. А на модельки времени нет.

[Aether]

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

Не совсем, данная фигура может выполняться в очень узком интервале скоростей конкретно СУ-27, про остальных не знаю, что-то вроде 350-400 км/ч, но могу ошибаться. В противном случае он свалится, и тут уж как повезёт, не всегда пилотам удаётся вывести самолёт в случае штопора.

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

Примерные параметры:
Харриер / СУ-27 / Боинг - 737

Максимальный взлётный вес в кг: 7 900 (верт.) / 33 000 / 79 000
Максимальная тяга двигателей в кгс: 9 500 / 15 000 (бесф.) - 25 000 (форс.) / 25 000
Соотношение тяга/вес: 1,20 / 0,45 - 0,76 / 0,32
Масса двигателей в кг: 1 700 / 3 000 / 6 500
Соотношение масса дв./вес: 0,22 / 0,09 / 0,08

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

Ну а вот если не ждать?

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

[Aether]

Конструкции самолетов — это моя специальность, ...

А моя это конструкция двигателей самолётов, а остальное почти также.

[Dale]

Что-то создавать, или говорить о том, что стоит создавать.

Вот лично мне для счастья очень не хватает программно-аппаратного комплекса для функционального и приемочного тестирования встроенных систем.

Аппаратура: интерфейсная плата, подключаемая к PC (по USB) и к испытуемой системе (ИС) через ее интерфейсы. Получает от PC команды для генерации воздействий на ИС (цифровые и аналоговые сигналы), регистрирует отклик ИС и передает в PC.

Программное обеспечение: драйвер интерфейсной платы; система тестирования, позволяющая описывать тестовые сценарии на специальном проблемно-ориентированном языке (DSL) и проверяющая соответствие поведения реальной ИС описанному на DSL идеалу.

Наличие такой системы позволило бы перенести идеи разработки, управляемой спецификацией поведения (BDD), в мир разработки оборудования. Сначала описываем требования к устройству на языке, понятном как разработчикам, так и нашему комплексу. Затем начинаем разработку, а комплекс периодически производит автоматическое тестирование, тут же давая знать, как только что-то пошло не так.

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

Обсуждали эти идеи с коллегами из США, они проявили живой интерес, но к разработке подключаться не торопятся, ссылаясь на высокую занятость в собственных проектах (это на самом деле так, не просто вежливый отказ). Соотечественники традиционно к идеям тестирования относятся прохладно, ибо тестирование плохо совместимо с генетически закодированным "авосем".

Вот такая потенциальная тема для разработки.

[Aether]

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

У нас тестирование аппаратной части производится, но для этого обычно ведутся отдельные разработки испытаний и стендов. Задача, которую Вы ставите слишком широка. Например, в каком скоростном диапазоне должно тестироваться то или иное устройство? Очевидно, что есть малые режимы - для отладки узлов, рабочие режимы - для отладки систем, испытания с повышенной скоростью - для сдачи систем. Так вот, спектр систем велик, есть устройства, которые ограничиваются величинами кГц, есть средняя категория в десятки и максимум сотню МГц, плюс СВЧ. Спрашивается, сколько стоят, например, осциллографы на 1 ГГц? А в Вашем устройстве сбора информации должно быть на портах ввода по одному осциллографу. Какова пропускная способность USB? Не такая уж и большая, значит осциллографы должны записывать данные синхронно в некий банк ОЗУ, откуда потом их извлекать и анализировать. Анализировать в реальном времени скорее всего будет невозможно, так как синхронизация всех узлов должна быть жёсткой.

Другой проблемой является сам принцип: есть тестируемое (Т1), а есть тестирующее (Т2) устройства. Как убедиться, что Т2 в данном режиме не имеет отклонений, получается ряд Т1 - Т2 - Т3 - Т4 устройств, хорошо, если он сходится на уровне доступном восприятию человека. А это значит, что можно миновать много шагов просто сразу разрабатывая модули необходимого устройства на микро уровне. Плюс отладка технологии производства - всё может быть верно, но что-то придёт с другой стороны.

Третья проблема, вот, например, сумматор - два числа A и B по 64 бит дают сумму. С точки зрения математики проблемы нет, а вот устройство следует проверить. Как это сделать, проверять все комбинации A+B?

Получается 2¹²⁸ комбинаций, предположим, что скорость счёта будет на уровне 1 ГГц, что примерно 2³⁰, тогда потребуется 2⁹⁸ секунд, что составляет примерно 10 049 234 210 332 868 796 745 лет. Надеюсь, что не ошибся. А это означает, что некоторые аппараты невозможно тестировать целиком, удостовериться можно лишь в частных измерениях. Производители ИС, насколько знаю, делают внутренние блоки самоконтроля, которые могут проверить этот сумматор по частям внутри самой ИС.

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

Давайте попробуем взять типовую задачу - съём параметров работы транзистора от статического режима до ГГц в рамках Вами желанной системы.

[Dale]

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

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

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

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

спектр систем велик, есть устройства, которые ограничиваются величинами кГц, есть средняя категория в десятки и максимум сотню МГц, плюс СВЧ. Спрашивается, сколько стоят, например, осциллографы на 1 ГГц? А в Вашем устройстве сбора информации должно быть на портах ввода по одному осциллографу.

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

Какова пропускная способность USB? Не такая уж и большая, значит осциллографы должны записывать данные синхронно в некий банк ОЗУ, откуда потом их извлекать и анализировать. Анализировать в реальном времени скорее всего будет невозможно, так как синхронизация всех узлов должна быть жёсткой.

Для сигналов достаточно жесткого реального времени планирую проверку реализовать в самой интерфейсной плате. Например, она получает команду проверить, что на такой-то вход поступают импульсы длительностью 1 мкс и периодом 10 мкс с допуском 5%. Плата по USB передает не оцифрованный сигнал, а лишь результат проверки "да/нет" (возможно, с конкретизацией, по каким критериям "нет"). Это должно принципиально снизить ограничения по скорости USB.

Другой проблемой является сам принцип: есть тестируемое (Т1), а есть тестирующее (Т2) устройства. Как убедиться, что Т2 в данном режиме не имеет отклонений

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

Третья проблема, вот, например, сумматор - два числа A и B по 64 бит дают сумму. С точки зрения математики проблемы нет, а вот устройство следует проверить. Как это сделать, проверять все комбинации A+B?

Получается 2¹²⁸ комбинаций, предположим, что скорость счёта будет на уровне 1 ГГц, что примерно 2³⁰, тогда потребуется 2⁹⁸ секунд, что составляет примерно 10 049 234 210 332 868 796 745 лет. Надеюсь, что не ошибся. А это означает, что некоторые аппараты невозможно тестировать целиком, удостовериться можно лишь в частных измерениях. Производители ИС, насколько знаю, делают внутренние блоки самоконтроля, которые могут проверить этот сумматор по частям внутри самой ИС.

Это вечная проблема при диагностике схем с большим количеством комбинаций. Сумматор - это еще не самый худший случай. Если проверять, скажем, все состояния модуля оперативной памяти на 8 гигабайт, Ваши 2⁹⁸ секунд покажутся коротким мгновением. Поэтому перебором такие схемы не тестируют.

Для сумматора мы можем обойтись проверкой каждого двоичного разряда, а также формирования переносов. В каждом из разрядов всего 3 входа и 2 выхода, всего 8 тестов. Повторяем 64 раза, это не так уж долго.

Давайте попробуем взять типовую задачу - съём параметров работы транзистора от статического режима до ГГц в рамках Вами желанной системы.

Это несколько другая задача, нежели функциональное тестирование встроенной системы. По крайней мере, в ранних релизах интерфейсного блока в нем точно не будет ни высоковольтного источника напряжения (понадобится при испытаниях на пробой), ни генератора СВЧ. Для снятия характеристик элементной базы оптимальной будет другая структура стенда.

[Aether]

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

В принципе, самое важное это правильно выбрать тип интерфейса между хабом и удалёнными блоками. У самолётов, судов и зданий длина может быть довольно велика, поэтому расстояние надёжной связи должно быть около 500 м, но при этом достаточно скоростной - 9600 может быть маловато. Канал приёмный и передающий имело бы смысл объединить, так как при диком количестве проводов получается ситуация, как в старом АТС. По каждому каналу в независимости от команды с компьютера от хаба должны идти пакеты с чётким временным шагом в шапке которых должно передаваться значение главного таймера для синхронизации. Каждый блок должен самоидентифицировать свой тип, а вот порядковый номер блока одного типа лучше ставить вручную посредством какого-нибудь DIP переключателя. Таким образом, один канал представляет из себя четыре провода: два - это информационная витая пара и ещё два - это питание (24 V, max 500 mA) от общего источника, от которого, кстати лучше питать и компьютер. Вот вкратце моё видение. Ну и в шапке ответа также должно передаваться время, когда то или иное действие было выполнено.

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

[Dale]

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

Чем он проще:

1. Электронный блок компактен. Следовательно, не потребуется передавать информацию на большое расстояние. Можно обойтись USB, которая штатно присутствует на любом ПК.
2. Электронный блок сразу вырабатывает электрические сигналы, которые легко либо непосредственно ввести в интерфейсную плату, либо нормализовать простыми средствами (например, "сухой контакт" заземлить и притянуть резистором к логической единице; понизить большое напряжение делителем или маленькое поднять инструментальным усилителем, переменное - выпрямить пиковым/квадратичным детектором, в случае слишком большого динамического диапазона - логарифмировать; преобразовать ток в напряжение датчиком Холла, и т.п.).

Чем сложнее:

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

Что касается исследования свойств макросооружений вроде аэробусов, мостовых пролетов и т.п., тут явно придется городить целую распределенную систему сбора данных. В качестве первого кандидата на транспорт данных я бы рассмотрел стандартную сеть CAN, благо в моих закромах томятся несколько пригоршней специализированных микросхем для нее. Может быть, практичнее окажется двузвенная архитектура: сеть CAN из концентраторов, на которые скидывают данные радиочастотные датчики. Возможно, найдется подходящая open source SCADA, чтобы не городить велосипед.

Но это, как я уже говорил, несколько другая история, хотя и в чем-то родственная.

[Aether]

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

Вариант языка из систем HDL не рассматривался?

Может быть, практичнее окажется двузвенная архитектура: сеть CAN из концентраторов, на которые скидывают данные радиочастотные датчики.

Как только появится промежуточный концентратор - появятся его задержки и нюансы. Опять таки, всё упирается в исходную постановку задачи. Для моста в 1-10 км естественно придётся городить сеть, возможно и на базе радиосвязи, хотя это не так надёжно. Я как-то писал о том, что уже сейчас есть пластиковое оптическое волокно, но пока дорого оно и не очень далеко действует передача - затухание сильное в материале.

[Dale]

Вариант языка из систем HDL не рассматривался?

Я не знаю, как на нем можно описать сценарий взаимодействия с системой.

Первый (и пока основной) претендент на эту роль - Gherkin. Я уже приноровился описывать на нем приемочные тесты, и коллег на него подсадил прочно.

Например, если мы описываем поведение сигнализации при срабатывании датчика движения в помещении, получится нечто вроде (при использовании русского диалекта Gherkin):

Код:

Функция: охрана замкнутого помещения при помощи инфракрасного датчика движения.

Сценарий: подача сигнала тревоги при активации датчика.
    Пусть система находится в состоянии "охрана"
    Если сработал датчик движения
    То система должна перейти в состояние "тревога"
    И сирена должна включиться
    И панель тревоги должна мигать с частотой 2 герца с допуском 10%

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

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

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

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

Если там будет большое количество видеотрафика, это может быть проблемой (хотя от меня до Youtube 20 хопов, и ничего). А та же температура вполне подождет секунду.

Я как-то писал о том, что уже сейчас есть пластиковое оптическое волокно, но пока дорого оно и не очень далеко действует передача - затухание сильное в материале.

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

[Aether]

Я не знаю, как на нем можно описать сценарий взаимодействия с системой.

Я прикрепил файл в предыдущем посте, который описывает блок тестирования. Verilog позволяет описывать аппаратные тесты.

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

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

Вообще, люблю "С" по большей части. Для меня было открытие, когда я перешёл с BP, который учил традиционно первым из языков высокого уровня, на BC. Пропала необходимость создавать непонятно какие конструкции. Но есть вещи, которые до сих пор не нравятся, в первую очередь, отсутствие работы с флагами. А также не хватает особого флага ошибки с аппаратной стороны, назовём его "e" флаг, который бы освобождал использование аккумулятора только для передачи полезных данных. Также был бы не плох флаг "ef", который бы поднимался бы при потере значимости в результате операции FPU. Заодно при этом установленном флаге, FPU мог бы аппаратно пропускать инструкции - какой смысл продолжать расчёт, если смысл вычисления уже потерян. Мне кажется, в конструкциях языков более высокого уровня, таких как: throw-catch, идёт перерасход вычислительных ресурсов.

[Dale]

Verilog позволяет описывать аппаратные тесты.

Тут главный вопрос: будут ли эти тесты столь же выразительны и понятны заказчику? Это реально очень важно.

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

Парсер уже есть, и очень хороший. Это Cucumber (написанный на языке Ruby) и его многочисленные клоны на разных языках (я регулярно использую парочку, но оригинал все же нравится больше).

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

Более общий вариант - трансляция предметно-ориентированной конструкции "Если сработал датчик движения" в низкоуровневую "Если сигнал на входе B11 перешел из 1 в 0". Такую трансляцию можно делать динамически по таблице либо статически при помощи макроподстановки, дело вкуса.

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

Вообще, люблю "С" по большей части.

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

Еще ему долгое время принадлежала ниша встроенных приложений, но сегодня и оттуда его очень активно теснит оттуда C++, который объективно безопаснее и выразительнее. Редкий месяц обходится без вебинара о переходе с C на C++ для микроконтроллеров, я уже и посещать их перестал - одно и то же.

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

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

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

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

А что вообще аккумулятор делает в языке уровня выше ассемблера (пусть и совсем ненамного выше)? В стандарте языка C никаких аккумуляторов нет. Да и вообще - что это такое само по себе?

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

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

Мне кажется, в конструкциях языков более высокого уровня, таких как: throw-catch, идёт перерасход вычислительных ресурсов.

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

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

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

[RXL]

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

Python style. Например, конец итерирования объекта и неудачный поиск в словаре оператором []. В Python исключение там норма.

[Aether]

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

Я делал себе в рамках хобби стенд для экспериментов с электроникой из специальной монтажной доски (не фольгированный стеклотекстолит толщиной 4 мм) с отверстиями и пазами, а за ней располагался силовой узел, дающий разные напряжения, и узел связи с ПК через USB средствами Arduino. Конечно, не лучшее решение, так как вся мощь USB состоит в пакетной передаче данных, а не в имитации последовательного порта, но драйверы в среде Windows я никогда не писал, а на ноутбуке не удобно держать две ОС, да и делать модуль, скажем на PIC 16F1454, для хоббийных проектов было лень. Сверху размещались тестируемые сборки на печатных платах. Разметка отверстий была выполнена так, чтобы можно было устанавливать платы разных размеров. (Файл разметки одной из досок прикреплю, её размер 380 х 360 мм.)

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

Согласен, просто есть конструкции, например, конструктор возвращает указатель на структуру созданного объекта, либо "0" в случае ошибки. Так вот, в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна, а в других архитектурах возможна. Да и с точки зрения математики, код должен перерабатывать что угодно адекватно. Система возврата и обработок ошибок в рамках "С" запущена, код получается не компактным, а хочется читать суть, а не ряды проверок.

А что вообще аккумулятор делает в языке уровня выше ассемблера (пусть и совсем ненамного выше)? В стандарте языка C никаких аккумуляторов нет. Да и вообще - что это такое само по себе?

В рамках "С" речь идёт о соглашении о вызове, то есть обычно, когда мы пишем "return 0;" этот самый "0" попадает в eax (или регистр этой группы), который традиционно называется аккумулятором. С точки зрения железа, особенно в ранних архитектурах, под ним подразумевалось такое схемотехническое решение, чтобы обработка данных через него шла быстрее. Собственно, при программировании на ассемблере и сейчас стоит использовать его где только можно. Комбинация "xor eax, ex + push eax..." быстрее чем при использовании других регистров и намного быстрее и компактнее, чем заполнение нулевыми литерами.

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

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

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

Исключение суть прерывание, мой анализ показал, что МП должен быть увлечён только одним прерыванием - это смена задач, а остальное от лукавого, так как вносит смуту. Отработка задач реального времени - это работа для МК.

Собственно, как например я вижу работу флага e. Представим, что у нас malloc не выделил память, тогда по возвращению e будет установлен (RETERR), а на запись в регистр нуля даже не надо тратить время.

Далее, все CALL инструкции при поднятом флаге ошибки пропускаются, а безусловные и условные переходы выполняются. Если мы обрабатываем ситуацию, то пишем переход через блок обработки, а если нет, то сам компилятор добавляет код при выходе из тела программы в месте "}" ставя выход из всей программы сразу. В итоге, значительный объём проверок просто будет не нужен. В версии DEBUG компилятор поставит сообщения об ошибке к каждой функции, а в RELEASE можно будет поймать ошибку по положению указателя на момент выхода из программы. Для управления не критичной ситуации с ошибкой потребуется нечто вроде "BCF E", которая сотрёт флаг ошибки и позволит продолжить выполнение функций.

[Sla]

Язык человека понятен заказчику, но непонятен машине.

хм.. Всегда думал, что например пролог как раз для этого и был предназначен.

Ладно-ладно, не совсем точное сравнение.

Зачем парсер - если есть конструктор фраз
Взять с
Проверить там, через ... сек

Т.е. вполне вписывающаяся в структуру теста

Да, конечно, нужно обучать..

зы. Это моя первая работа - разработка диагностического комплекса.
Каждый блок прогонялся через тесты, которые были упорядочены в массиве
по принципу
PinUp -10
PinOut - 100
inputSignal - d1
outputSignal - a=0,4-0,45

ox 28лет...ДВК
И работало!!!!

[Dale]

в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна

Разве Intel научился делать бесконечную память? И даже если так, как быть с конечной разрядностью адреса?

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

Несправедливо ожидать столь многого от языка из начала 1970-х. Именно поэтому и идет эволюция языков.

когда мы пишем "return 0;" этот самый "0" попадает в eax (или регистр этой группы), который традиционно называется аккумулятором.

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

На x86, к счастью, свет клином не сошелся (хотя многократно пытался). В мире embedded правят бал другие архитектуры (ARM, PowerPC etc), в которых ничего подобного нет.

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

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

Исключение суть прерывание

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

мой анализ показал, что МП должен быть увлечён только одним прерыванием - это смена задач, а остальное от лукавого, так как вносит смуту.

Какую же смуту вносит прерывание от сетевого адаптера, получившего фрейм, или от диска, завершившего операцию обмена данными?

Собственно, как например я вижу работу флага e. Представим, что у нас malloc не выделил память, тогда по возвращению e будет установлен (RETERR), а на запись в регистр нуля даже не надо тратить время.

Пробовали оценить реальную экономию времени?

Далее, все CALL инструкции при поднятом флаге ошибки пропускаются, а безусловные и условные переходы выполняются. Если мы обрабатываем ситуацию, то пишем переход через блок обработки, а если нет, то сам компилятор добавляет код при выходе из тела программы в месте "}" ставя выход из всей программы сразу. В итоге, значительный объём проверок просто будет не нужен. В версии DEBUG компилятор поставит сообщения об ошибке к каждой функции, а в RELEASE можно будет поймать ошибку по положению указателя на момент выхода из программы. Для управления не критичной ситуации с ошибкой потребуется нечто вроде "BCF E", которая сотрёт флаг ошибки и позволит продолжить выполнение функций.

IMHO довольно запутанно и хрупко. А если при оптимизации компилятор раскрыл код inline функции и убрал CALL?

[Aether]

Разве Intel научился делать бесконечную память? И даже если так, как быть с конечной разрядностью адреса?

Дело не в количестве памяти, а в том принципе, что любая функция, которая возвращает результат, не имеет нормальной возможности сообщить об ошибке. А попытки "уплотнения", которые используются в ряде случаев - это больше костыли. Битовые поля - это хорошо, но помним, что выделять придётся целую ячейку памяти или целый регистр под 1 бит. Регистр в этом случае получается дорогим, а обращение к памяти - это сразу потеря в производительности. И если это ещё и в цикле, то само собой торможение умножается.

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

А много программистов ставят условие на проверку бесконечности или ухода в область денормализованных чисел, когда точность результата становится сомнительной? Больно много выпороть придётся, а значит дело не в лени, а в системе.

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

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

Какую же смуту вносит прерывание от сетевого адаптера, получившего фрейм, или от диска, завершившего операцию обмена данными?

В общем случае иерархия. Строго говоря, ни одно устройство последовательной обработки не может обработать параллельные каналы, и чтобы это обойти придумываются способы выделить важное и оставить на потом остальное. Казалось бы просто, но при таком подходе могут создаться ситуации, когда два устройства по вине третьего будут вечно ждать друг друга, когда маленький поток с частыми вызовами срезает производительность всего другого. Ваша статья есть по энкодерам, вот вопрос: что важнее: следить за каналами изменения следящих оптопар или за изменением состояния внешнего порта? А теперь представьте, что такую систему обяжут следить ещё за тремя объектами, и повесят их на прерывания - то, что рано или поздно он ошибётся в координате - гарантировано. В итоге, я выделяю задачей МК следить за целевым устройством через прерывание, а общаться, например, с ПК бесконечным циклом основного кода. А сам ПК (МП) должен иметь нормальную систему менеджмента, как аппаратную, так и компонент ОС, и не пытаться успеть всё сделать разом, задачи реального времени тут весьма ограничены, ненадёжны. И блокировать работу потоков, ставить их на ожидание до прихода данных с диска - это он должен - его задача. Опять таки решение системное.

Пробовали оценить реальную экономию времени?

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

IMHO довольно запутанно и хрупко. А если при оптимизации компилятор раскрыл код inline функции и убрал CALL?

Ничего не изменится.

Код: (C)

{
...
    {
        p = create_object(); // Заполняем указатель на объект, выделяя память.
        if (p == 0) {... Обрабатываем ошибку ...} // Вот этих обработчиков уйма.
        ...
        // Продолжаем работу с созданным объектом
        ...
    }
...
}

Код: (C)

{
...
    {
        p = create_object(); // Заполняем указатель на объект, выделяя память.
        if (_err) { // Если нам нужен свой обработчик ошибки.
        ... Сбрасываем флаг ошибки ...
        ... Обрабатываем ошибку ...}
        // А если обработчик не нужен, то ничего не пишем, так как в DEBUG компилятор должен добавить:
        if (_err) {
        ... Сброс флага ошибки ...
        dprintf("object1.c line 540 create_object error\n");
        ... Выход ...
        } // А в RELEASE этого не будет, он просто проедет до конца тела этого блока.
        ...
        // Продолжаем работу с созданным объектом
        ...
    }
    // Вот здесь идёт проверка, которую вставляет компилятор,
    // если при выходе из тела блока флаг поднят, то программа завершается.
...
}

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

[Dale]

Дело не в количестве памяти, а в том принципе, что любая функция, которая возвращает результат, не имеет нормальной возможности сообщить об ошибке.

Ну как же не в количестве, когда:

Так вот, в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна, а в других архитектурах возможна.

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

Исключение - вполне себе нормальная возможность сообщить об ошибке, очень правильная конструкция.

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

Если выделять целую ячейку под бит, зачем тогда битовые поля?

А много программистов ставят условие на проверку бесконечности или ухода в область денормализованных чисел, когда точность результата становится сомнительной? Больно много выпороть придётся, а значит дело не в лени, а в системе.

Не вижу проблемы включить стандартный заголовок <fenv.h>, а в нужном месте вызвать fetestexcept(). Программистам, которым лень сделать такую малость в приложении, где это реально важно, лучше заняться чем-нибудь другим, например, мести улицу (хотя и мести они наверняка будут так же неаккуратно).

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

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

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

Как видим, общего совсем немного.

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

Разделение времени процессора между несколькими процессами - типичное решение, найденное еще на заре эры компьютеров.

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

Только при условии невежества разработчика системы в области взаимодействия процессов. Достаточно, например, пройти курс по системам реального времени в университете Або (Coursera), чтобы не делать таких грубых ляпов.

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

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

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

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

Это же всего две задачи. Нужно поставить на МК ОС реального времени и запускать независимые задачи под ее управлением. Можно сделать гораздо больше. Вот в былые времена дали бы Вам, скажем, СМ-1420 следить за двумя лампочками? А ведь тот же STM32 производительнее раз в сотню.

Ничего не изменится.

Как же так?

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

Функция, вызываемая через CALL, будет пропущена. Функция, развернутая inline, будет выполнена. Если у них  есть побочные эффекты (а это нередкое явление), состояние программы будет разное.

Обычный механизм исключений гораздо прозрачнее и удобнее в использовании.

[Aether]

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

Ситуация: Вы поручаете предоставить Вам 50 байт памяти, когда всего есть 1 КБ. Менеджер памяти возвращает "0" - это не правильно? Нет, всё верно, выделено 50 байт, адрес начала этого блока пространства "0". Такая ситуация не встречается у Интела, но в PIC есть такое понятие, как непрямая адресация. Через неё образуются зоны памяти, которые отсчитываются со своего нуля. Вообще, в любой системе, где код и данные лежат в разных пространствах, ситуация, что Вы получите начало адресного пространства при выделении вероятна. И это не будет ошибкой. А чтобы обойти эту ситуацию на "С" придётся заранее выделять специальную структуру, в которой будет храниться и адрес и состояние ошибки - это неудобно. С точки зрения математики, ноль - это тоже число.

Если выделять целую ячейку под бит, зачем тогда битовые поля?

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

Не вижу проблемы включить стандартный заголовок <fenv.h>, а в нужном месте вызвать fetestexcept().

Вот это как раз костыль, когда самого языка оказывается мало, и прибавляется библиотека, которая пытается как-то это причесать и обобщить.

Не ошибется, если я правильно расставлю приоритеты прерываний и спланирую обработку.

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

А ведь тот же STM32 производительнее раз в сотню.

Я это отношу уже к МП, просто производители решили убить двух зайцев.

Функция, вызываемая через CALL, будет пропущена. Функция, развернутая inline, будет выполнена. Если у них  есть побочные эффекты (а это нередкое явление), состояние программы будет разное.

Я имел ввиду, что с флагом установленным "e" выполняются только команды условного и безусловного переходов, а также команды работы с флагами, в предыдущем посте я это как бы уточнил вскользь, то есть пропуск CALL часть стратегии. Поэтому, развёрнутая функция просто будет представлена более длинной серией NOP. На состоянии программы это не отразится. Если тело блока не отработает ошибку, сбросив флаг, программа завершится. Тут всё решается внутри потока - никаких исключений, прерываний и иже с ними.

У нас просто разные мнения и подходы. Хотя иногда мы говорим об одном и том же, но разными словами.

[Sla]

А вообще всё становится веселее, особенно, когда на Вашем устройстве кто-то другой вдруг вздумает запустить ещё и какой-нибудь датчик,

Нет такого кто-то. Система для некто - закрыта.

Есть аппаратные прерывания, есть программные (те же исключения)

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

Битовые операции.. Ага-ага.. расскажите про 51 серию там совсем нет битовых операций, и битовых регистров.

Не имеет значения не каком языке написан софт. Компилятор сам разберется.

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

Если есть некие процессы требующие быстрого реагирования, то они разносятся в пространстве.
Не надо отдавать все на обработку МП. Задача управляющего МП сбор и реагирования на внешние сигналы.
И принимать решение важности сигнала.

[Dale]

Ситуация: Вы поручаете предоставить Вам 50 байт памяти, когда всего есть 1 КБ. Менеджер памяти возвращает "0" - это не правильно?

Нет. Это признак того, что объем "кучи" исчерпан, и блок выделен не был.

Прекращаем импровизировать, берем в руки стандарт (например, ISO/IEC 9899:1999), читаем. Сначала описание malloc:

7.20.3.3 The malloc function

Synopsis
   #include <stdlib.h>
    void *malloc(size_t size);

Description

The malloc function allocates space for an object whose size is specified by size and whose value is indeterminate.

Returns

The malloc function returns either a null pointer or a pointer to the allocated space.

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

6.3.2.3 Pointers

...
3. An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.⁵⁵⁾ If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

---
⁵⁵⁾ The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant; see 7.17.

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

Нет, всё верно, выделено 50 байт, адрес начала этого блока пространства "0".

Не скажу за всю Одессу, ограничимся только GCC, мануал к которому лежит в пределах протянутой руки. Там указано, что линкер располагает в начале памяти секцию .data (инициализированные статические переменные), затем секцию .bss (неинициализированные статические переменные), затем идут "куча" и в конце - стек. Так что у "кучи" не так много шансов оказаться по нулевому адресу.

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

С точки зрения математики, ноль - это тоже число.

У стандарта C свое мнение по данному вопросу, с которым мы уже ознакомились выше.

Битовые поля, как я понимаю, метод организации структуры

Да, способ плотно упаковать в слово цепочки из одного или нескольких бит.

Вот это как раз костыль, когда самого языка оказывается мало, и прибавляется библиотека, которая пытается как-то это причесать и обобщить.

А говорите - любите C. Тут без этих костылей шагу не ступить. Неужто забыли про errno? Если нет, то чем этот костыль хуже?

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

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

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

А вообще всё становится веселее, особенно, когда на Вашем устройстве кто-то другой вдруг вздумает запустить ещё и какой-нибудь датчик, и в его обработчик или поток будет всунут блок расчёта через итерации какого-нибудь синуса. И это сразу не проявится - скорости то достаточно, но раз в месяц что-нибудь будет обязательно случаться.

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

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

Я имел ввиду, что с флагом установленным "e" выполняются только команды условного и безусловного переходов, а также команды работы с флагами

А толку с тех условных переходов, если условия перехода вычисляются предыдущим кодом, который не выполняется? Это же генератор случайных чисел (и неуловимых глюков)

[Aether]

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

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

А говорите - любите C.

Любовь зла.

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

?

А толку с тех условных переходов, если условия перехода вычисляются предыдущим кодом, который не выполняется? Это же генератор случайных чисел (и неуловимых глюков)

Я не сказал, что у меня уже готовое решение. Пока только идея.

Как я вижу работу МП: есть выделенный поток управления, главная задача которого - это доступ к железу, организации памяти, созданию потоков и их переключению. Сами потоки изолированы от железа, не должны порождать никакие прерывания, исключения, чтобы не нарушить расчётного времени собственного исполнения в диспетчере задач, и сделать систему более "прозрачной". В свою очередь, приход и уход данных с сетевой карты или диска также не должен быть прерыванием. Просто, приняв данные, канал связи должен выставить флаг о приёме, чтобы ОС в свободное от выполнения потоков время сумела спокойно проанализировать эти данные и предпринять необходимое. То есть, с точки зрения системы, прерывания для МП не так важны, его задачи не должны гарантировать время, вспомним, что таймеры в том же Linux гарантируют время не меньшее, чем заказанное. То есть, попросив 1 мс можно получить 10 мс, 1 с, но никак не 1 мс или меньше. А с точки зрения МК, которые обслуживают жёсткий режим по времени, прерывания важны, но их не может быть много, я сторонник, если нужно, вставить несколько МК, чем вставить один МП и заниматься отладкой его программных компонентов по времени.

[RXL]

Комбинация "xor eax, ex + push eax..." быстрее чем при использовании других регистров и намного быстрее и компактнее, чем заполнение нулевыми литерами.

А ты уверен?
xor eax, eax может быть закодирован одной из двух операций:
XOR r32, r/m32
XOR r/m32, r32
И никакого преимущества над другими РОН регистрами.
С push таже ситуация:
PUSH r32
PUSH r/m32
Никакого преимущества.
Кстати, PUSH imm32 работает с той же скоростью. Различие только в размере инструкций в предвыборке. В цикле скорость один в один.

Добавлено через 12 минут и 43 секунды:

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

Это что за такие трудности? Просвети, пожалуйста.

Исключение суть прерывание, ...

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

...
Далее, все CALL инструкции при поднятом флаге ошибки пропускаются, а безусловные и условные переходы выполняются.
...

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


Добавлено через 4 минуты и 33 секунды:

в рамках системы Интела, да, ситуация когда менеджер памяти вернёт 0 невозможна

Разве Intel научился делать бесконечную память? И даже если так, как быть с конечной разрядностью адреса?

POSIX совместимые ОС могут добывать память из ниоткуда убивая при ООМ самый жирный процесс. В Linux, чтобы убийства не были стихийными, можно задать вес процессу (напоминает nice). Но и тогда я бы не стал утверждать, что память никогда не кончится.

[Aether]

А ты уверен?

Нет, не уверен, так как процессоры меняются. Просто вспомнил из рекомендаций к 80486, что по возможности стоит использовать "al ah ax eax" везде, где только можно. Вроде тогда считал и действительно выходило выгоднее.

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

Это что за такие трудности? Просвети, пожалуйста.

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

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

Только под этим я и понимаю исключение. А про ловлю ошибок через механизмы языка throw-catch я уже писал ранее - без аппаратной поддержки это повлечёт перерасход чего-нибудь. Структуры служебные появятся.

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

Не понял?

POSIX совместимые ОС могут добывать память из ниоткуда убивая при ООМ самый жирный процесс. В Linux, чтобы убийства не были стихийными, можно задать вес процессу (напоминает nice). Но и тогда я бы не стал утверждать, что память никогда не кончится.

И тут тоже.

[RXL]

Ну ты вспомнил. Уже и Пентиум устарел лет на 20. Технический прогресс, однако.

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

Результат вычисления валидных нормализованных плавающих чисел предсказуем: это валидное нормализованное значение, либо одно из специальных для данной инструкции: inf и nan. Причем нечисла тоже предсказуемы и зависят от аргументов. Проверь до и/или после. На сложные места напиши тесты.

У тебя необоснованное предубеждение перед try-catch.
В стандарте Си есть longjmp: http://www.cplusplus.com/reference/csetjmp/longjmp/
Делаешь setjmp, уходишь на любой уровень вложенности, выполняешь longjmp и практически бесплатно возвращаешься к setjmp. Это и есть пресловутый try. От longjmp к setjmp передается int — можно считать это кодом ошибки.
Что на самом деле было? Функция setjmp сохранила контекст: адрес инструкции и адрес указателя стека до ее вызова. Функция longjmp восстановила стек, передала int (через стек) и сделал goto. Что тут должно тормозить? А вот возвращаться назад с кодом ошибки через несколько вызовов, вот это точно тормоз.

C-style распространения ошибки — это обнаружения ошибки на одном уровне и передача ее следующему уровню в иерархии.

И тут тоже.

http://shtsh.blogspot.ru/2012/04/oom-killer.html

[Aether]

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

На NASM могу передать и то и то, используя, например, пару EAX-EBX, но как это представить на "С" - возврат двух параметров от функции?

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

Ты упоминал Борланд... У них там есть fastcall соглашение, как раз максимизирует регистровую передачу при вызовах.

fastcall опасен, так как не стандартизирован. Раньше было так: запускаем в функцию EAX-EBX-ECX-EDX-далее стек, а выход EAX. Сейчас, например, TCC делает примерно так: CX-DX-стек, а выход EAX. В общем, это можно использовать только в пределах локального проекта. Но проблему возврата с двумя параметрами это не решает.

Результат вычисления валидных нормализованных плавающих чисел предсказуем: это валидное нормализованное значение, либо одно из специальных для данной инструкции: inf и nan. Причем нечисла тоже предсказуемы и зависят от аргументов. Проверь до и/или после. На сложные места напиши тесты.

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

Так я и проверяю, но на это уходят ресурсы.

[RXL]

... Структуры служебные появятся. ...

Ты экономишь байты, тратя время, силы и придумывая новые велосипеды. Я писал и под 51 со 128 байтами (их них 32 - 4 банка РОН, стек тоже в этой "куче"), и под PIC, включая самый младший (16 байт). Не надо распространять эти практики на все программирование. Контроллеры тоже нынче обрастают памятью.

[Aether]

А вот возвращаться назад с кодом ошибки через несколько вызовов, вот это точно тормоз.

Ну, у нас был несколько гипотетический разговор. Я имел ввиду, что если в теле функции произошла ошибка, то следует установка такого флага, далее, в уровне из которого был совершён вызов функции она должна быть отработана. Если отработка не произошла, то программа завершается аппаратно. Тут нет никаких вызовов, но детали нужно ещё продумать. И оценить: было бы это эффективным?