Ну, да, хрень какая-то.Сообщение от wal79
На всякий случай, упростил схему. Действительно воспроизводится на одном XOR элементе.
Снимок экрана 2017-08-10 в 16.07.14.png
Ну, да, хрень какая-то.
На всякий случай, упростил схему. Действительно воспроизводится на одном XOR элементе.
Снимок экрана 2017-08-10 в 16.07.14.png
Ну и как тут вычисляется?
Пошагово?
По всем канонам здравого смысла:
Начало
1. Конст1:=1* (может быть ещё при компилляции, и запись в тело программы, в пзу)
2. ЛЗ1:=0
3. ЛЗ2:=0
Инициализировали все переменные.
НЦ
4. Выход:=ЛЗ1
5. ЛЗ2- В стек
6. Константа - в стек
7. XOR
8. Результат - в ЛЗ1
9. Константа - в ЛЗ2
КЦ
3 дерева:
1.От выхода(шаг 4)
2. От ЛЗ1 (на выходе)(шаги 5-8)
3. От ЛЗ2 (на входе)(шаг 9)
Если 3е выполняется раньше второго, то на вход хоr с линии задержки прилетит 1 к моменту расчёта xor.
Но ни при каких условиях на второй вход не прилетит 0 от константы.
Да хватит привязываться к константам и ПЗУ.
Рассмотрите лучше пример, где я воспроизвёл баг на "входе" макроса.
Значение входа-то уж никак в ПЗУ не запишешь.
Значения входа пишутся в переменные в начале цикла - до расчёта. Это тот же самый баг-багище чтения из ненужной и неинициализированной переменной.
Да посмотрите же на лог.
В конкретном случае ОЛ приняло решение константу 1 сохранить в переменную. Наверное, из-за того, что используется в нескольких местах.
Поэтому и последовательности операций "константа-в стек; xor" вообще нет в логе.
Здесь у вас ошибка.
Судя по логу, секция "инициализации начальных значений до цикла" отсутсвует как класс. Да, это может звучать "не по канонам", но это неважно, ведь точно такая же ошибка может возникнуть и при любых других вычислениях (обработке входов, например)
Не может. Входы по определению пишутся до расчёта цикла.
Отсутствие инициализации констант и статических переменных при запуске программы (до первого цикла) - это путь к непредсказуемому поведению ПР при включении.
На время первого цикла, на выходах может оказаться любой мусор, никак не связанный с запрограммированным поведением. Это БАГИЩЕ, недопустимый в промавтоматике.
Похоже, вы не поняли сущность бага: значение, к которому подключено несколько связей, сохраняется во вспомогательную переменную.
Поэтому не так важно что находится на входе, а будет использовано именно значение из вспомогательной переменной.
То же самое будет и в любом другом вычислении. Надо просто результат вычисления подключить двумя связями (простой и ЛЗ) и можно получить баг (в зависимости от указанного приоритета ЛЗ).
Приоритет ЛЗ тут никаким боком вообще.
Эдак и приоритет выходов может привести к тому, что в расчёте будет использована "промежуточная переменная", которую ещё никто не посчитал.
А эта "промежуточная переменная" должна быть посчитана при первом же проходе через неё, не важно с какой стороны разветвления расчёт к ней пришёл.
Ваши права
Ответить с цитированием