Не имеет значения XOR или нет, я говорил об этом.Цитата:
Сообщение от Владимир Ситников
Вложение 32414 Вложение 32415 Разницу видите? Функция одна и та же, а вычисление разное.
Не имеет значения XOR или нет, я говорил об этом.Цитата:
Сообщение от Владимир Ситников
Вложение 32414 Вложение 32415 Разницу видите? Функция одна и та же, а вычисление разное.
Причем многие знают об этом уже давно ,а некоторые только сейчас :rolleyes:
Хотя для элементов AND, OR, XOR вообще стек не должен участвовать, так как входа у них равнозначны.
Входы может и равнозначные, но на один из входов одного элемента, подаётся сигнал с выхода другого элемента, и пока этот выход не вычислится, на входе ничего не будет. Где промежуточные вычисления хранятся?Цитата:
Сообщение от melky
Василий Кашуба, ну давайте посмотрим на AND - на одном из входов выход другого элемента - на выходе AND 0 - вычислился выход элемента и стал 1 - попал на вход AND, на выходе стало 1
На кой там в булевой логике хранить для AND значение ?
тоже для XOR, OR и так далее...
А вот если вы что-то делаете с задержками и т.д. вот только тогда может потребоваться и то, решается флагами, правда которых в ОЛ нет.
По вашему все семь выходов одновременно вычисляются? И почему вы взяли для примера булеву переменную, а не ИНТ.?Цитата:
Сообщение от melky
А вы пример переполнения стека для INT привели ? к тому же при AND со входами int тоже булевые операции выполняются только над всеми битами числа и опять же, к чему там стек ?
Может сами операторы надо последовательно выполнять, а не биты в стек заносить, там где он 300 лет не нужен ?
И? Результат вычисления разный что-ли получается?Цитата:
Сообщение от Василий Кашуба
То, что стек используется по-разному это "особенность реализации" (отсутствие оптимизации использования стека).
А если от порядка входов AND меняется результат, то это уже бага ОЛ.
Стек это внутренний механизм обработки схемы по всем выходам с обратными связями (в том числе когда одни выходы участвуют в формировании других) .Чем больше ОС тем глубже заполняется стек ..Раньше он был 6 ,потом 15 ,а потом динамическим ...
Ну так вот вопрос по оптимизации, если в участке схемы нет обратных связей, ни прямых, ни явных, зачем данный участок класть в стек ? все и так выполнится последовательно.
Выполняется последовательно ,но в одном цикле .Если поставить задержку .ТО получим в одном цикле одно значение ,а во втором другое .Например возьмите сравнение на равенство и подайте одно число(переменную) на два входа ,причем один вход сделайте задержку - получите формирователь импульса при смене числа .Не поставите задержку -будет всегда 1 . Элемент один ,переменная одна ,а линии связи разные и результат разный .
Ну зачем запутывать люд честной?Цитата:
Сообщение от rovki
Стек нужен для хранения промежуточных значений.
Про "обратную польская запись" слышали?
На Wikipedia есть пример как на стековой машине вычислять выражения.
Переводя с русского на русский, стек нужен не только для "линий задержки"/"обратных связей", а вообще для всех выражений.
При этом ОЛ не оптимизирует использование стека, и получается, что в зависимости от способа записи (от схемы) получается разное использование стека.
всю жизнь считал, что стек работает иначе. Первым записали - последним считали, последним записали - первым считали. А тут в ОЛ какой-то огород получился, а не стек.
Скорее всего так обозвали, слово красивое наверное :)
Вот как раз к вопросу о последовательности. Я показал, что вся схема вычисляется слева на право и сверху в низ. Для левой картинки сколько промежуточных вычислений нужно держать в памяти пока получится результат? А вот для правой схемы только одно промежуточное значение.Цитата:
Сообщение от melky
Вот поэтому для левой картинки в стек нужно поместить сразу все переменные, а в правой вычислять только две.Цитата:
Сообщение от Владимир Ситников
И? На результате это не должно сказываться.Цитата:
Сообщение от Василий Кашуба
Моё утверждение в том, что от перестановки местами входов XOR результат не должен изменяться (само результирующее значение должно сохраняться).
То, что стек используется по-разному -- не должно играть роли.
Может Алексея Толстого читали, помните про гиперболоид, он прекрасно понимал, что правильно назвать параболоид, но так назвал, потому что "звучит"!Цитата:
Сообщение от melky
Это если бы каждый раз считали "от выхода к входу".Цитата:
Сообщение от Василий Кашуба
А считают "от входа к выходу".
Т.е., в обоих случаях, вначале стек заполняется значениями входов, но в разном порядке (для левой 8,7,6,5,4,3,2,1, для правой наоборот) а потом идут операции and,and,and....
При and, впринципе, можно прервать вычисление такой цепочки, получив первый раз false. А при or/xor нельзя, и всёравно придётся прокрутить весь стек.
Будет оптимизация, если проверять каждый результат и пытаться прерваться? Нет. Не будет. Потому, что проверка - это лишняя команда и цикл процессора. И в среднем, при всех возможных состояниях входов может и не получиться прироста быстродействия. К тому же, при компиляции нужно уметь находить такие выражения и каждый раз вставлять для них новый код.
При одном элементе (баг, который я показывал) вообще нет смысла говорить про "порядок действий". Да и видно, что баг образовался не в коде самого лог.элемента, а ещё на входе.
А где я написал что результат на выходе разный?Цитата:
Сообщение от Владимир Ситников
Тут у вас неточность, т.к. входа вообще может не быть. Иными словами, если блок подключить только к выходу, то он всё равно будет работать, а, если блок подключить только ко входу, то работать не будет.Цитата:
Сообщение от pop70
Значит, работают "от выхода".
Вряд ли.Цитата:
Сообщение от pop70
Скорее всего, в одном случае последовательность такая (стек используется на 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
..
А дальше у вас верный вывод:
Цитата:
Сообщение от pop70
Вот тут:Цитата:
Сообщение от Василий Кашуба
И вот тут:Цитата:
Сообщение от Василий Кашуба
Цитата:
Сообщение от Василий Кашуба
Напомню, это всё были ответы на сообщение pop70 о том, что "константа 1 приходит на вход XOR как 0 и в итоге выход XOR'а оказывается 0"
Цитата:
Сообщение от pop70
Вы сначала сказали поменять связи, а потом сказали, что исходное поведение не баг.
Так вот, если убрать попытки пихать в стек все элементы, а закидывать только те части, где есть обратные связи или ЛЗ , то и получится оптимизация. Пусть лучше 10-ток AND прощелкает лишний раз без всякого стека. А ощущение, что в стек пихают все что ни попадя...
Сигнал на вход приходит не тот. Причём здесь выход, выход как раз работает правильно.Цитата:
Напомню, это всё были ответы на сообщение pop70 о том, что "константа 1 приходит на вход XOR как 0 и в итоге выход XOR'а оказывается 0"
А почему при этом "помогает изменение порядка связей"?Цитата:
Сообщение от Василий Кашуба
Или весь ваш совет заключался не в изменении порядка, а в "переподсоединении"?
Реальная схемотехника, это, да, наука о плохих контактах. Но в ОЛ схемах-то такого не должно быть. Баг.
Вот раньше был баг, вот это БАГ, связь могла повиснуть в воздухе,не присоединившись к другому элементу. :)Цитата:
Сообщение от Владимир Ситников
Почему то все просят, чтобы было всё как в железе. :)Цитата:
Реальная схемотехника, это, да, наука о плохих контактах. Но в ОЛ схемах-то такого не должно быть.
Вы не путайте порядок "компиляции"(разбора схемы") и порядок её вычисления.Цитата:
Сообщение от Владимир Ситников
Я же уже писал. При "компиляции" строится дерево с корнем у выхода. (Схема уже такое дерево) От выхода ко входу. А порядок расчёта узлов этого дерева обратный - вначале считаются дальние от корня узлы, потом, используя уже посчитанные данные - следующие - более близкие к выходу. Этот порядок определяется один раз при "компиляции", и тупо выполняется в каждом цикле программы, без каких бы то ни было "оптимизаций" в каждом цикле. И порядок этот не может быть от выхода к входу. Потому, что вначале нужно задать входные анные каждому элементу, а только потом получить то, что на выходе.
ЛЗ никак с стеку не относитсяЦитата:
Сообщение от melky
ЛЗ - это вообще статическая переменная, живущая всё время работы ПР, как и "обратная связь".
Чё Вам стека стм-ки жалко? :)
Лишь бы на память переменных не наехал. Программа вообще прямо в ППЗУ вся сидит
А в чём сакральный смысл, константу подключать к входу через ЛЗ?Цитата:
Кстати, попал на один косяк в работе ЛЗ.В макросе CTMAX.
В чём дело - хз. Повторить не могу. И в программе, и в новом макросе работает. А в том пришлось константу делать 0 и вставлять инвертор - тогда всё работает.
 Миниатюры

Я кажется понял почему программа сработала так. Так как первой обрабатывалась ЛЗ, то первый цикл для всей программы был отменён, для того чтобы получить, значение для этой ЛЗ.Цитата:
Сообщение от pop70
Слушайте, это всё вилами по воде. Как "отмена цикла" поможет "получить значение ЛЗ"? Если цикл отменён, то и в ЛЗ ничего не попадёт, значит этой ЛЗ нечего будет обрабатывать.Цитата:
Сообщение от Василий Кашуба
Не должно быть никаких лишних пропусков только из-за того, что на схему добавили ЛЗ.
Гораздо более вероятен вариант с "плохим контактом". Т.е. каким-то образом сделана связь (например, в древней версии ОЛ), которая выглядит как связь, но не работает.
Легко же проверить: сейчас значение константы передаётся прямо сразу, и нет никакого "пропуска первого цикла".
Ничего сакрального. На картинке формирователь единичного импульса по началу работы (включению ПР).Цитата:
Сообщение от Василий Кашуба
Да нет. Там какой-то косяк на обычной связи. На одной стороне 1, на другой (у входа элемента) 0.Цитата:
Сообщение от Василий Кашуба
Поставьте на входе инвертор без константы и всё будет работать.Цитата:
Сообщение от pop70
Вложение 32439
Оно и так работает. Повторял в другом макросе - работает. Хоть к верхнему входу, хоть к нижнему.Цитата:
Сообщение от Василий Кашуба
Просто, не привык входы "в воздухе подвешивать". Отсюда и константа. Атавизм от железячника :)
Так работает же и с константой.Цитата:
Сообщение от Василий Кашуба
Чего обсуждать? Баг и есть баг.
Если бы ОВЕН хотели узнать причину, то они что-нибудь сделали бы.
Ну или наоборот: отправить в ОВЕН палёный проект (если есть возможность), и спросить в чём проблема.
Я не верно выразился. Помогите с определением, как узнать то, что было, до того как всё началось. :)Цитата:
Сообщение от Владимир Ситников
"Здесь принято" отправлять проект в личку wal79. Он раскуривает проект и выдаёт своё мнение (или чинит ОЛ).Цитата:
Сообщение от Василий Кашуба
Если я правильно понимаю pop70, то у него остался файл с проектом, который работает неправильно. Как раз этот файл и нужно отправить программистам ОВЕН.
Было бы, конечно, хорошо, если бы ОЛ показывало p-code, который получается из пользовательской схемы (в том числе на промежуточных этапах). Но это не реализовано, и, полагаю, ждать этого можно "до пенсии".
PS Распечатка промежуточного кода встречается много где:
В МастерСкаде4 есть возможность увидеть генерируемый код. Они сделали как раз для целей отладки.
Если посмотреть на МЗТА, то у них тоже можно посмотреть генерируемый код.
И в моей среде, разумеется, видно как трансформируется код.
А моя просьба, дать новое определение "отмене цикла"
Цитата:
 Сообщение от Василий Кашуба 
Я не верно выразился. Помогите с определением, как узнать то, что было, до того как всё началось. 
Например, договориться, что при запуске схемы, значения всех линий задержки будут равны 0.Цитата:
Сообщение от Василий Кашуба
В чём вопрос-то?