Ну, да, хрень какая-то.Сообщение от wal79
На всякий случай, упростил схему. Действительно воспроизводится на одном XOR элементе.
Снимок экрана 2017-08-10 в 16.07.14.png
Ну, да, хрень какая-то.
На всякий случай, упростил схему. Действительно воспроизводится на одном XOR элементе.
Снимок экрана 2017-08-10 в 16.07.14.png
Так вам показали же лог: Вложение 32565
Переменная №3 это и есть "хранилище, которое используется для того, чтобы подать 1 на вход XOR'а".
В логе видно, что ОЛ почему-то пыталось "поместить значение константы в переменную 3" уже намного позже вычисления самого XOR'а (XOR обрабатывал переменную 4=="линия задержки" и переменную 3=="простая связь" ).
ЛЗ к этой самой "переменной 3" (надеюсь) никак не относится.
Это всё, конечно, красивые рассуждения про "космические карабли", но точно такой же баг может образоваться и без констант.
Поэтому баг нужно исправлять не "починкой констант", а починкой самого компилятора, который допустил use-before-def.
Вот тот же самый баг без констант:
Снимок экрана 2017-08-10 в 16.21.59.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" вообще нет в логе.
Здесь у вас ошибка.
Судя по логу, секция "инициализации начальных значений до цикла" отсутсвует как класс. Да, это может звучать "не по канонам", но это неважно, ведь точно такая же ошибка может возникнуть и при любых других вычислениях (обработке входов, например)
Результат используется в нескольких местах (из "константы" выходят две связи), и вполне логично, что компилятор сохранил этот самый результат в промежуточную переменную.
Могла бы эта переменная соптимизироваться? Могла. Но эта оптимизация повлияла бы лишь на скорость работы.
А скорость работы сейчас всех устраивает.
Значения входа пишутся в переменные в начале цикла - до расчёта. Это тот же самый баг-багище чтения из ненужной и неинициализированной переменной.
Не может. Входы по определению пишутся до расчёта цикла.
Отсутствие инициализации констант и статических переменных при запуске программы (до первого цикла) - это путь к непредсказуемому поведению ПР при включении.
На время первого цикла, на выходах может оказаться любой мусор, никак не связанный с запрограммированным поведением. Это БАГИЩЕ, недопустимый в промавтоматике.
Похоже, вы не поняли сущность бага: значение, к которому подключено несколько связей, сохраняется во вспомогательную переменную.
Поэтому не так важно что находится на входе, а будет использовано именно значение из вспомогательной переменной.
То же самое будет и в любом другом вычислении. Надо просто результат вычисления подключить двумя связями (простой и ЛЗ) и можно получить баг (в зависимости от указанного приоритета ЛЗ).
Ваши права
Ответить с цитированием