Фичи и баги OWEN Logic

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

Вы все конечно красиво расписали. На деле не совсем так. Нет того "умного" принятия решения о модификации макроса, о котором Вы говорите.

А что вы подразумевали-то под словом "inline"?

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

Вот тут я не соглашусь.

Вы что, предлагаете, что "надёжный программно-аппаратный комплекс ОЛ-ПР" работает "как-то автомагически"?

Приведу пример:

int x = 2;
int y = x + x * x;

Чему равно y?
Разумеется, пользователю важно знать чего ожидать от программы. Программу же не наобум пишут, а с примерным представлением того, как она должна работать.
Так вот: y может быть равно 6, а может и 8.
При этом, ответ не зависит от того компилируется выражение в машинные коды или оно вычисляется интерпретатором.
Результат определяется именно тем, "как хотел создатель языка", а уж как реализован конкретный компилятор (на C, на Java, или ещё как) пользователей волнует в последнюю очередь.

В языках C, C#, Java и прочих явно оговорены правила вычислений выражений.
Эти самые правила никогда не ссылаются на "регистры процессора", "машинный код", "адреса памяти", ведь правила на то и правила, чтобы объяснять суть происходящего.
Вот в выражении x + x * x приоритет операции умножения выше, поэтому выражение эквивалентно выражению x+(x*x).
При этом, компилятор может хоть как это выражение вычислять.
Например, компилятор может использовать специальную инструкцию FMA (fused-multiply-add), которая за одну операцию вычислит именно это выражение.

Вот пример в случае C# (выдержка из спецификации C# 3.0):
Снимок экрана 2017-08-29 в 12.28.25.png

Так и в случае с ОЛ.
Пользователям важно знать по каким правилам должны работать схемы ОЛ.
Сказать, что "вся текущая реализация ОЛ это одно большое правило", конечно, можно, но это бесполезно.

Пользователям ОЛ важно уметь предсказывать результат программы "в уме" и без использования ОЛ. Поэтому и объяснение того, "как должны работать ОЛ схемы" (== спецификацию ОЛ языка) желательно описывать без привлечения фраз в духе "ОЛ загружает значение в стек, поэтому тут получается 2, а не 3". Да какая разница стек или регистр?
По-хорошему, должно быть более-менее стройное и простое объяснение в духе "результат работы ОЛ схемы будет неотличим от результата, полученного таким-то алгоритмом", а при этом сама программа ОЛ может использовать те оптимизации, которые удобны авторам.


PS. По-моему, вы путаете путаете понятие "спецификация" и "реализация".

[wal79]

А что вы подразумевали-то под словом "inline"?


Вот тут я не соглашусь.

Вы что, предлагаете, что "надёжный программно-аппаратный комплекс ОЛ-ПР" работает "как-то автомагически"?

Приведу пример:

int x = 2;
int y = x + x * x;

Чему равно y?
Разумеется, пользователю важно знать чего ожидать от программы. Программу же не наобум пишут, а с примерным представлением того, как она должна работать.
Так вот: y может быть равно 6, а может и 8.
При этом, ответ не зависит от того компилируется выражение в машинные коды или оно вычисляется интерпретатором.
Результат определяется именно тем, "как хотел создатель языка", а уж как реализован конкретный компилятор (на C, на Java, или ещё как) пользователей волнует в последнюю очередь.

В языках C, C#, Java и прочих явно оговорены правила вычислений выражений.
Эти самые правила никогда не ссылаются на "регистры процессора", "машинный код", "адреса памяти", ведь правила на то и правила, чтобы объяснять суть происходящего.
Вот в выражении x + x * x приоритет операции умножения выше, поэтому выражение эквивалентно выражению x+(x*x).
При этом, компилятор может хоть как это выражение вычислять.
Например, компилятор может использовать специальную инструкцию FMA (fused-multiply-add), которая за одну операцию вычислит именно это выражение.

Вот пример в случае C# (выдержка из спецификации C# 3.0):
Снимок экрана 2017-08-29 в 12.28.25.png

Так и в случае с ОЛ.
Пользователям важно знать по каким правилам должны работать схемы ОЛ.
Сказать, что "вся текущая реализация ОЛ это одно большое правило", конечно, можно, но это бесполезно.

Пользователям ОЛ важно уметь предсказывать результат программы "в уме" и без использования ОЛ. Поэтому и объяснение того, "как должны работать ОЛ схемы" (== спецификацию ОЛ языка) желательно описывать без привлечения фраз в духе "ОЛ загружает значение в стек, поэтому тут получается 2, а не 3". Да какая разница стек или регистр?
По-хорошему, должно быть более-менее стройное и простое объяснение в духе "результат работы ОЛ схемы будет неотличим от результата, полученного таким-то алгоритмом", а при этом сама программа ОЛ может использовать те оптимизации, которые удобны авторам.


PS. По-моему, вы путаете путаете понятие "спецификация" и "реализация".

Вы подходите со стороны программиста. Лоджик изначально создавался с позиции схемотехника. Понятно, что с некоторыми оговорками, которые уже не раз обсуждались.

[anthrwpos]

Почему Вы ищете между ними разницу. Они обе виртуальные

потому что изменения одной из них, отображаются в просмотрщике, а другой - нет.
Вставлю скрин еще раз иллюстрирующий непонятность.Вложение 32860
Переменная OUT+ 1 в макросе и 1 в графе значение
Переменная current 0.0762 в макросе и 0 в графе значение.

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

Вы подходите со стороны программиста. Лоджик изначально создавался с позиции схемотехника. Понятно, что с некоторыми оговорками, которые уже не раз обсуждались.

И?

Ответьте на вопрос прямо. Действительно считаете, что пользователям ОЛ (в том числе схемотехникам) нет никакой нужды в том, чтобы уметь предсказывать поведение схемы?

[wal79]

потому что изменения одной из них, отображаются в просмотрщике, а другой - нет.
Вставлю скрин еще раз иллюстрирующий непонятность.Вложение 32860
Переменная OUT+ 1 в макросе и 1 в графе значение
Переменная current 0.0762 в макросе и 0 в графе значение.

Ясно. Вас смутило что там 1. Когда Вы добавляли Q1 в просмотрщик на тот момент выход имел видимо значение 1. Вот Вы его и видите. Вас должна была смутить "серость" строк таблицы, которая как раз говорит о недоступности переменных.

[wal79]

И?

Ответьте на вопрос прямо. Действительно считаете, что пользователям ОЛ (в том числе схемотехникам) нет никакой нужды в том, чтобы уметь предсказывать поведение схемы?

Конечно пользователь должен понимать как создавать схему. Но Вы гребете все под свой уровень ,что не верно.

Предлагаю в этой ветке спор уже закончить. Все же ветка создана для сбора багов. За баги, о которых Вы сообщили спасибо, будем работать над ними.

[anthrwpos]

Ясно. Вас смутило что там 1. Когда Вы добавляли Q1 в просмотрщик на тот момент выход имел видимо значение 1. Вот Вы его и видите.

Таки нет, оно не постоянно 1, а отражает реальную динамику этой переменной. Это получается, баг?=)

Расскажите, пожалуйста, в какой литературе используется такая терминология.

Я не нашел по вашим ссылкам, в чем мое определение макроса расходится с описываемым там.

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

Я не нашел по вашим ссылкам, в чем мое определение макроса расходится с описываемым там.

Вы пишете:

макрос - это идентификатор, который транслируется в некий неизменный участок кода.

Функция - это идентификатор, который компилируется в адрес вызова, по которому начинается сама функция.

^^^ Это какой-то бред. Вы говорите про адреса, неизменные участки кода и т.п.
Вот как на основании ваших определений можно понять какая физически разница между макросом и функцией?

В LISP описании говорится очень ясно, и без адресов участков кода:

https://ru.wikibooks.org/wiki/%D0%9B...BE%D1%81%D1%8B : от функций макросы отличаются способом вычисления, которое проходит в два этапа: получение нового выражения (раскрытие макроса) и вычисление этого выражения.

[wal79]

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

Переменная Q1 создается в редакторе макросов специально для отладочных целей. Она только на чтение. В реальном проекте ее конечно не существует. Поэтому изменения значения выходов в редакторе макросов видны, но задать свое значение нельзя. Что касается переменной current, к примеру, она не существует ни в проекте ни в редакторе макросов конечно же (зачем?). Поэтому изменения значения Вы не видите. Как current, так и переменная выхода Q1 доступны только для чтения, поэтому они "серые". Как я уже говорил, раз появляются сомнения, значит я со своей стороны к примеру уберу возможность добавления в просмотрщик виртуальных переменных.

[wal79]

Вы пишете:



^^^ Это какой-то бред. Вы говорите про адреса, неизменные участки кода и т.п.
Вот как на основании ваших определений можно понять какая физически разница между макросом и функцией?

В LISP описании говорится очень ясно, и без адресов участков кода:

Как я уже говорил, давайте прекратим в этой ветке обсуждать это.