:) Фактически, а не на словах доказать, насколько ты хороший программист, можно лишь на практике. За прожитые годы вынужден был проделывать это неоднократно. Как по мне, на словах должно быть достаточно одного примера — разработка операционки для стенда обучения программированию на однокристалке. Объем программы примерно 2k, зашиваемая в EPROM, средствами разработки которой выступили исключительно голова, ручка и тетрадные листочки в клеточку. Код писался, прокручивался и отлаживался в голове, а на листки записывался сразу начисто и сразу рабочим.
Относительно простоты задач Вы категорически не правы. Задачи бывают ох какие объемные (управление производственными линиями и цехами) и ох какие сложные, с кучей алгоритмов, при том реализуются они на совсем небольших контроллерах, поскольку внешних сигналов-то немного, зато режимы работы установки и различные алгоритмы работы по своему числу и сложности реализации подчас требуют напряженного многомесячного труда многоопытного программиста.
Вы не так понимаете. Это очень современные платформы, только специализированные. Другое дело, что сам бы с удовольствием поменял эти современные платформы, на совсем другие современные.
А кто это должен делать?
Ну, наверное Вы, раз умеете сразу работающий код писать)
) Так в настоящее время я ж прикладной программист, программист ПЛК, а не разработчик IDE на языках верхнего уровня
От него сперва отказались, заменив другим, намного более убогим
Зачем?
Насколько знаю, тупоголовыми менеджерами двигали две вещи: 1) мечтали объединить два софта (один предпочитали и использовали в Азии, другой в Европе) в единый пакет, в итоге же, получили не единый пакет, а три раздельных; 2) старый пакет разрабатывался партнером, с которым, как и с другими многолетними партнерами, новый менеджмент корпорации сумел рассориться…
А через некоторое время из этого убогого ещё и изъяли все текстовые языки, кроме ST.
Ну так не обновляйте ПО.
Увы и ах, новое оборудование поддерживается только обновленными версиями.
Все персональные, годами наработанные библиотеки и старые программы, написанные текстом, в нем больше не открываются.
Если это текст, то его открыть можно любым блокнотом. Или компилировать нечем?
В новом компилировать нечем. Ни программные куски, ни библиотеки, написанные текстом, в программу, созданную в этом пакете даже не добавить.
Ну это да, если, конечно, не считать тех, что вы сами создали.
Сам я сразу пишу работающий код.
Если так, почему никто не взял да не написал нормальный пакет программирования?
А кто это должен делать? Сами программисты ПЛК?
Лет 7-8 назад был пакет программирования с малым количеством изъянов. От него сперва отказались, заменив другим, намного более убогим, выход которого анонсировали в течение лет эдак 10-ти (анонсировали, конечно, не убогий, а передовой). А через некоторое время из этого убогого ещё и изъяли все текстовые языки, кроме ST. И новые контроллеры программируются только новым софтом. Все персональные, годами наработанные библиотеки и старые программы, написанные текстом, в нем больше не открываются. Так что имеем то, что имеем.
Понятно. Просто если в средстве разработки писать непосредственно на языке команд контроллера, то там командная последовательность банально транслируется в код безо всяких ошибок.
С учетом, что в другом своем комментарии сказали об ассемблере x86-64, то это вполне логично звучит.
Если у меня листинг программы самописный, составленный непосредственно из инструкций ПЛК, то в этом случае вообще никаких багов. Баги появляются тогда, когда программа составляется в IEC IL, или графических Ladder Logic/FBD, вот тогда компиляция уже зависит от фантазий разработчика пакета программирования. Если же она написана на языке высокого уровня (ST), то тут вообще широкое поле для фантазии — коду после компиляции можно удивляться бесконечно.
Умножение и деление 32-битных чисел не по 450нс, поболее — 3,4 и 3,7мкс соответственно. Вот логические операции, которые для ПЛК являются базовыми, поскольку его задача управление процессами, в т.ч. реализация релейно-контакторной логики, занимают 210нс.
Почему процессор так быстро считает, предположить можно — он, скорее-всего, на ПЛМ реализован, т.е. операции поразрядного сложения и вычитания со сдвигом заведомо аппаратно реализованы на вентилях. Остается выдернуть операнды из памяти в процессор, активировать соответствующую цепочку логических элементов, и результат записать обратно в память. То есть основное время занимает загрузка-выгрузка из памяти. Это хорошо объясняет то обстоятельство, что время выполнения команд с 32-битными операндами мало отличается от 16-битных.
Рассказываю о том, чему был непосредственным свидетелем. А вот во втором моменте я именно это имел в виду, владение Си, как латынью, а не то, что они именно СИшными программистами трудятся.
У меня их выпало нааамного больше. Причем, Сименс когда-то я тоже программировал. И был момент, когда в качестве программиста ПЛК Сименс все АСУТПшные компании города, делавшие проекты на их контроллерах, рвались «приобрести» меня за любые деньги, на любых условиях. Но я уже более полугода как перешел работать с ПЛК Митсу, которая профукала рынок.
Вы правы, верно, общее кол-во задействованных словных регистра — 4. Прошу прощения, это я затупил к ночи, зациклился на делении остатка, тогда как делить следует частное.
Тем не менее, алгоритм я бы несколько модифицировал:
1. Путем сложения удваиваем делимое.
2. Сверяем знаки делимого и делителя: если знаки не совпадают (исключающее или) вычитаем из делимого значение делителя, в противном случае, прибавляем его.
3. Путем сложения удваиваем делитель.
4. Выполняем деление.
Вуаля.
Ещё разок: одну никак не получится — у Вас числителе Double Int, поэтому знаменатель тоже Double Int, до деления результат тоже может оказаться Double Int, так что делить его на 2 придется в формате Double Int, что в итоге даст +4 ячейки к тем двум, куда были переданы входные значения…
А сравнение знаков в Cи смотрится классно)
Это да, можно, командой WAND…
Команд деления у меня только две. Первый шум начался из-за команды умножения. Я ей заменил две команды — обнуления старшего слова и сложения — в моей технике суммарно они выполняются столько же времени, сколько одна команда умножения.
Она знаки числителя и знаменателя не учитывает) И ячейка памяти никак не одна: числитель должен быть Double Integer, знаменатель, соответственно, Double Integer, результат первой операции деления 2хDouble Integer. Результат второй даст ещё +Double Integer
) Так в настоящее время я ж прикладной программист, программист ПЛК, а не разработчик IDE на языках верхнего уровня
Насколько знаю, тупоголовыми менеджерами двигали две вещи: 1) мечтали объединить два софта (один предпочитали и использовали в Азии, другой в Европе) в единый пакет, в итоге же, получили не единый пакет, а три раздельных; 2) старый пакет разрабатывался партнером, с которым, как и с другими многолетними партнерами, новый менеджмент корпорации сумел рассориться…
Увы и ах, новое оборудование поддерживается только обновленными версиями.
В новом компилировать нечем. Ни программные куски, ни библиотеки, написанные текстом, в программу, созданную в этом пакете даже не добавить.
Сам я сразу пишу работающий код.
А кто это должен делать? Сами программисты ПЛК?
Лет 7-8 назад был пакет программирования с малым количеством изъянов. От него сперва отказались, заменив другим, намного более убогим, выход которого анонсировали в течение лет эдак 10-ти (анонсировали, конечно, не убогий, а передовой). А через некоторое время из этого убогого ещё и изъяли все текстовые языки, кроме ST. И новые контроллеры программируются только новым софтом. Все персональные, годами наработанные библиотеки и старые программы, написанные текстом, в нем больше не открываются. Так что имеем то, что имеем.
Если у меня листинг программы самописный, составленный непосредственно из инструкций ПЛК, то в этом случае вообще никаких багов. Баги появляются тогда, когда программа составляется в IEC IL, или графических Ladder Logic/FBD, вот тогда компиляция уже зависит от фантазий разработчика пакета программирования. Если же она написана на языке высокого уровня (ST), то тут вообще широкое поле для фантазии — коду после компиляции можно удивляться бесконечно.
Почему процессор так быстро считает, предположить можно — он, скорее-всего, на ПЛМ реализован, т.е. операции поразрядного сложения и вычитания со сдвигом заведомо аппаратно реализованы на вентилях. Остается выдернуть операнды из памяти в процессор, активировать соответствующую цепочку логических элементов, и результат записать обратно в память. То есть основное время занимает загрузка-выгрузка из памяти. Это хорошо объясняет то обстоятельство, что время выполнения команд с 32-битными операндами мало отличается от 16-битных.
Тем не менее, алгоритм я бы несколько модифицировал:
1. Путем сложения удваиваем делимое.
2. Сверяем знаки делимого и делителя: если знаки не совпадают (исключающее или) вычитаем из делимого значение делителя, в противном случае, прибавляем его.
3. Путем сложения удваиваем делитель.
4. Выполняем деление.
Вуаля.
А сравнение знаков в Cи смотрится классно)
Команд деления у меня только две. Первый шум начался из-за команды умножения. Я ей заменил две команды — обнуления старшего слова и сложения — в моей технике суммарно они выполняются столько же времени, сколько одна команда умножения.