Особенности программирования БВК АМС

[bs]

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

[bs]

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

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

[Unispace]

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

Вы спорите с людьми, которые не занимаются железными проектами с встроенным ПО. Они живут в своем виртуальном "высоком" мире, не чувствуют нутром связь железа и кода, параноидально отстаивают свои миражи и психуют с оскорблениями, если их позицию пытаются оспорить. Они никогда не поймут то, о чем я или вы говорим, об аккуратности и строгости подхода. Асм им видится неким непонятным атавистичеким врагом, хотя этот асм может иметь и макросы, и стандартную библиотеку процедур. Эти "высокие" товарищи  могут и не знать, что множество функций, модулей в языках высокого уровня, в языках моделирования пишется на асме, с целью оптимизации по размеру и скорости.  Этим товарищам неведомо, что вместо их высокопроверенных ОС, написанных на эрлангах, в экстренном случае на борт ФГ нужно отправить несколько сот байт кода, выполняющих строго заданную функцию, а больше отправить просто нельзя, из-за ограничений по времени и условиям связи. И что такой код может быть написан только на машинном языке, с отличным пониманием связки железо-код. И еще они не понимают и не хотят понимать, что умеющий качественно, тщательно писать на асме ВСЕГДА будет писать хороший код и на языке высокого уровня, что асм может быть хорошей школой, а сам проект - на языке высокого уровня. Всю эту тему можно слить в утиль, от высоких программистов тут идут лишь пустые сотрясательства воздуха и ни один из них так и не ответил на простой вопрос  - "готовы вместо трендежа работать над проектом и проявить свои умения?".

[avp]

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

Речь не о проверки компилятором, а о "обработчиках". Если на асме простой условный переход по флагу, то на ЯВУ потребуется изменение синтаксиса.

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

Ps. В этом плане "ручная верификация" программ на асме действительно создавать высоканадёжный код. Только  медленно.

[dmdimon]

эффективность разработки как процесса, а не как эффективность его результата.

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

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

[bs]

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

А вы ни разу не допускаете возможности того, что это предположение ошибочно в виду вашей предвзятости в этом вопросе?

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

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

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

Это не пустой треп - уж я на асме исписал будь здоров и прошел путь от i8080 до протмода i386-х, не считая убогих микроконтроллеров и процов DSP.

[bs]

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

Да реально. Возьмем работу с FPU на С++ в платформе i80x86. Рантайм позволяет изменять флаги FPU, отвечающие за индикацию ошибок. Сам FPU умеет генерировать прерывание в случае ошибочных ситуаций. Это прерывание транслируется в исключение. Исключение можно обрабатывать там, где это уместно. Можно игнорировать или просто отключить генерацию прерывания FPU.

[dmdimon]

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

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

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

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

[bs]

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

А я не говорил, что это легко. Я говорил про качество результата

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

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

[avp]

Да реально. Возьмем работу с FPU на С++ в платформе i80x86. Рантайм позволяет изменять флаги FPU, отвечающие за индикацию ошибок. Сам FPU умеет генерировать прерывание в случае ошибочных ситуаций. Это прерывание транслируется в исключение. Исключение можно обрабатывать там, где это уместно. Можно игнорировать или просто отключить генерацию прерывания FPU.

Это частный случай. Выброс аппаратного исключения.
Я говорю про явную проверку в коде различных низкоуровневых условий. Например переполнения. В ЯВУ переполнение может быть как допустимым (арифметика по модулю) и недопустимым (вычисления). На асме всё можно точно закодить и проверить.

[Unispace]

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

Это не пустой треп - уж я на асме исписал будь здоров и прошел путь от i8080 до протмода i386-х, не считая убогих микроконтроллеров и процов DSP.

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

[bs]

Я говорю про явную проверку в коде различных низкоуровневых условий. Например переполнения. В ЯВУ переполнение может быть как допустимым (арифметика по модулю) и недопустимым (вычисления). На асме всё можно точно закодить и проверить.

Ну по аналогии при необходимости всегда можно сделать библиотеку типов со вставками на асме с такой жесткой проверкой всех операций и генерацией исключений по результатам проверок. Так что даже такая глобальная паранойя вполне реализуется и на ЯВУ.

[Artemkad]

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

:shock: Это примерно как утверждать, что "очень надежный код можно получить на Ассемблере". Т.к. Си имеет максимально широкие возможности наловить глюков из-за своих широчайших возможностей по доступу к аппаратуре.

[Artemkad]

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

Вообще-то это делается еще на этапе создания/наполнения оптимизатора в компиляторе. Как пример могу привести реализацию циклического сдвига на Си для 1 байтного числа которую компиляция очень часто приведет к одной/двум(зависит от камня) процессорным командам с использованием бита переноса.

Код Выделить Развернуть


// циклический сдвиг влево движок форума не пропустил :roll:
x=((x >> 1)  |  (x << 7)); // циклический сдвиг вправо

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

Ps. В этом плане "ручная верификация" программ на асме действительно создавать высоканадёжный код. Только  медленно.

По моему опыту - с некоторого размера нет! Начинаешь терять суть кода в отдельных кусках. Приходится урезать самому себе набор доступных "хаккерских" приемов т.к. "спецэффекты" вылазят полным ходом в самых разных местах. Могу ограничить объем Асм-кода для одного высококлассного разработчика примерно 40-60кБ (правда туда можно засунуть всю логику работы ФГ ) - дальше время получения надежного кода улетает за десятки лет разработки. Кроме того во весь рост встает проблема совместной работы нескольких программистов над одним кодом - с Асмом начинаются ТАКИЕ разборки, что быстрее вместе не писать....

[bs]

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

Это немного не то. Да, они будут выдавать более оптимальный с точки зрения ресурсов и быстродействия код на ЯВУ, но это не самый важный критерий для ПО КА.

Зато я вижу море программеров окошек, делающих свою работу спустя рукава, небрежно и плохо.

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

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

Не совсем понял о каком нагромождении каких конструкций речь, поэтому идентификацию провести не смог

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

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

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

Или вносят свои особенности, которые в итоге требует меньше тестирования.

Асм воспитывает такую аккуратность и полезен как этап профессионального опыта.

Асм безусловно очень полезен как этап проф. опыта. Но аккуратность программирования можно воспитывать не только им.

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

А не спешите с такими выводами. В этой теме уже были озвучены следующие интересные факты:

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

- ФГУП "НПЦ Автоматики и приборостроения им. Пилюгина" уже в далеком прошлом перевело все свои разработки на ГРАФИТ-ФЛОКС (графический язык реального времени). А это подразумевает не только отсутствие ассемблера, но и в принципе разработку ПО инженерами, которые к программированию отношения не имеют вообще! Не говоря уже про ассемблер.

[Not]

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

Это немного не то. Да, они будут выдавать более оптимальный с точки зрения ресурсов и быстродействия код на ЯВУ, но это не самый важный критерий для ПО КА.

Уже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров. Попробуйте перемножить матрицы на векторном процессоре на ассемблере. Или попробуйте вручную загрузить конвейер для эффективной обработки той же матрицы. Причем речь не о встроенных конвейерах АЛУ, а именно о внешних, управляемых пользователем. Трансляторы же с ЯВУ делают это значительно лучше.

[bs]

Уже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров.

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

[goran d]

Уже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров. Попробуйте перемножить матрицы на векторном процессоре на ассемблере. Или попробуйте вручную загрузить конвейер для эффективной обработки той же матрицы. Причем речь не о встроенных конвейерах АЛУ, а именно о внешних, управляемых пользователем. Трансляторы же с ЯВУ делают это значительно лучше.

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

[Artemkad]

Уже и по оптимальности ручной код начинает проигрывать машинно-сгенерированному из С. Это связано с внедрением в БЦВМ гибридных архитектур, векторных процессоров, настраиваемых конвейеров. Попробуйте перемножить матрицы на векторном процессоре на ассемблере. Или попробуйте вручную загрузить конвейер для эффективной обработки той же матрицы. Причем речь не о встроенных конвейерах АЛУ, а именно о внешних, управляемых пользователем. Трансляторы же с ЯВУ делают это значительно лучше.

Не начинает. На малых кусках код машина делает оптимальнее, но интегрально Асм-программа получается все равно эффективнее. Причина в разных подходах. Когда пишешь на Асме начинаешь прежде всего с удобного размещения наиболее часто используемых величин (как минимум флаги состояний) в наиболее доступных регистрах. А потом стиль просто навязывает разбиение задачи на фрагменты ложащиеся на регистровую матрицу камня с максимальным использованием минимальных регистров (того, что заложено в аппаратуру камня). Причем максимально используются доступные элементы контроллера типа системы прерываний, таймеров и DMA. Не потому, что доступнее, а потому, что так проще.
Посмотри к примеру конструкцию выше как использовать бит переноса в Си. Но ведь это ГЕМОРРОЙ и поэтому циклический сдвиг так редко встречается в Си-программах. А вот скажи, 128 битное суммирование на 8 битной машине в Си - исполнении не пробовал? А многобитную криптографию на циклических сдвигах? Но ведь это все простейшие операции при возможности работы с битами состояния процессора (на Асме)!

[Unispace]

А не спешите с такими выводами. В этой теме уже были озвучены следующие интересные факты:

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

Любой процессор исполняет машинные коды, а не модулу-2. Да, были и есть такие очень специальные процессоры и системы, которые имеют именно машинные команды вычисления матрицы или преобразования Хартли. При разработке можно без проблем обойтись без асма, но все-таки процессор будет оперировать кодами, и при возникновении какой-либо экстренной ситуации или дебаге может возникнуть необходимость обратиться именно к кодам. Я работал с очень сложной системой, где ПО из миллионов строк было написано на языке выского уровня класса Ада. Но мы обязаны были изучить архитектуру процессоров, на которых исполнялся сгенерированный компилятором код, и в экстренных случаях уметь править ПО прямо в коде, потому что иного способа просто не было. Чтобы поправить все в листинге, сгенерировать код заново, понадобилось бы не меньше суток. Теперь представьте, что в ФГ нашли ошибку за 10 минут до сеанса, а средства создания образа, который нужно срочно загрузить в ФГ, смогут сгенерировать этот образ через полчаса. Или вариант, когда нужно загрузить очень короткий код, без всяких ОС, страниц памяти и прочего, просто код, который сразу, без всяких долгих инициализаций, запустит двигатели. Остается только один путь  - править сам образ или создать этот короткий машинный код. Так что коды есть и будут присутствовать в таких системах, пока процессоры не научатся исполнять язык высокого уровня напрямую