Критическая ошибка в среде программирования Овен ЛОДЖИК или это я д-ак

[rovki]

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

[Владимир Ситников]

Стек это внутренний механизм обработки схемы по всем выходам с обратными связями (в том числе когда одни выходы участвуют в формировании других) .Чем больше ОС тем глубже заполняется стек ..Раньше он был 6 ,потом 15 ,а потом динамическим ...

Ну зачем запутывать люд честной?

Стек нужен для хранения промежуточных значений.
Про "обратную польская запись" слышали?

На Wikipedia есть пример как на стековой машине вычислять выражения.


Переводя с русского на русский, стек нужен не только для "линий задержки"/"обратных связей", а вообще для всех выражений.

При этом ОЛ не оптимизирует использование стека, и получается, что в зависимости от способа записи (от схемы) получается разное использование стека.

[melky]

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

[Василий Кашуба]

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

Вот как раз к вопросу о последовательности. Я показал, что вся схема вычисляется слева на право и сверху в низ. Для левой картинки сколько промежуточных вычислений нужно держать в памяти пока получится результат? А вот для правой схемы только одно промежуточное значение.

[Василий Кашуба]

Ну зачем запутывать люд честной?

Стек нужен для хранения промежуточных значений.
Про "обратную польская запись" слышали?

На Wikipedia есть пример как на стековой машине вычислять выражения.


Переводя с русского на русский, стек нужен не только для "линий задержки"/"обратных связей", а вообще для всех выражений.

При этом ОЛ не оптимизирует использование стека, и получается, что в зависимости от способа записи (от схемы) получается разное использование стека.

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

[Владимир Ситников]

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

И? На результате это не должно сказываться.
Моё утверждение в том, что от перестановки местами входов XOR результат не должен изменяться (само результирующее значение должно сохраняться).

То, что стек используется по-разному -- не должно играть роли.

[Сергей0308]

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

Может Алексея Толстого читали, помните про гиперболоид, он прекрасно понимал, что правильно назвать параболоид, но так назвал, потому что "звучит"!

[pop70]

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

Это если бы каждый раз считали "от выхода к входу".
А считают "от входа к выходу".
Т.е., в обоих случаях, вначале стек заполняется значениями входов, но в разном порядке (для левой 8,7,6,5,4,3,2,1, для правой наоборот) а потом идут операции and,and,and....
При and, впринципе, можно прервать вычисление такой цепочки, получив первый раз false. А при or/xor нельзя, и всёравно придётся прокрутить весь стек.
Будет оптимизация, если проверять каждый результат и пытаться прерваться? Нет. Не будет. Потому, что проверка - это лишняя команда и цикл процессора. И в среднем, при всех возможных состояниях входов может и не получиться прироста быстродействия. К тому же, при компиляции нужно уметь находить такие выражения и каждый раз вставлять для них новый код.
При одном элементе (баг, который я показывал) вообще нет смысла говорить про "порядок действий". Да и видно, что баг образовался не в коде самого лог.элемента, а ещё на входе.

[Василий Кашуба]

И? На результате это не должно сказываться.
Моё утверждение в том, что от перестановки местами входов XOR результат не должен изменяться (само результирующее значение должно сохраняться).

То, что стек используется по-разному -- не должно играть роли.

А где я написал что результат на выходе разный?

[Владимир Ситников]

Это если бы каждый раз считали "от выхода к входу".
А считают "от входа к выходу".

Тут у вас неточность, т.к. входа вообще может не быть. Иными словами, если блок подключить только к выходу, то он всё равно будет работать, а, если блок подключить только ко входу, то работать не будет.
Значит, работают "от выхода".

Т.е., в обоих случаях, вначале стек заполняется значениями входов, но в разном порядке (для левой 8,7,6,5,4,3,2,1, для правой наоборот) а потом идут операции and,and,and....

Вряд ли.

Скорее всего, в одном случае последовательность такая (стек используется на 2 элемента максимум, т.к. они сразу обрабатываются):

push in1 # Стек: in1
push in2 # Стек: in2, in1
and # берёт 2 элемента со стека, выполняет and, кладёт на стек результат
push in3 # Стек: in3, результат AND(in1, in2)
and # Стек: результат AND(in1, in2, in3)
push n4
and
push n5
and
...

А в другом -- такая (сначала всё забиваем в стек, а потом вычисляем):

push in1 # Стек: in1
push in2 # Стек: in2, in1
push in3 # Стек: in3, in2, in1
push in4 # Стек: in4, in3, in2, in1 <-- потребление стека растёт, а вычислений пока не происходит
...
and
and
and
and
..

А дальше у вас верный вывод:

Будет оптимизация, если проверять ...