Фичи и баги OWEN Logic

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

Такая вот ерунда: выход с одного макроса не попадает на другой.
bug.PNG
Сам проект
машины.owl

И сам макрос работает неадекватно (на симуляции точно, на железе еще не проверял). Понаблюдайте, у него скочат выходы то в ту то в обратную сторону. Если зайти в сам макрос и там просимулировать, введя те-же входящие параметры, то такого поведения нет.

И ещё один баг внутри ФБ VLV1, в режиме симуляции. Снимок.PNG

[wal79]

И ещё один баг внутри ФБ VLV1, в режиме симуляции. Снимок.PNG

А в окне просмотра переменных что показывают переменные inc и saw?

[wal79]

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

С багом 1 соглашусь. При сохранении проекта изменения в макросе должны были примениться.
Про баг 2 уже сказал, что нет "умного" принятия решения. Вы описываете то, что хотели бы видеть. Таких хотелок Вы не представляете сколько у меня есть по лоджику. У меня сжатые сроки и абсолютное отсутствие человекоресурсов. Поэтому что есть, то есть.

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

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

А что вы подразумевали-то под словом "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. По-моему, вы путаете путаете понятие "спецификация" и "реализация".

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

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

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

И?

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

[wal79]

И?

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

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

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

[Project M]

Владимир, посмотрите описание Inline функций в языках интерпритаторах (например в iDev-OS).
Кстати, программисты-Британцы, кипятком писают от возможности вставлять Inline функции, и с огромным удовольствием делают строку кода бесконечной длинны. (а для программистов-русских совершенно запутанную программу)

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

Владимир, посмотрите описание Inline функций в языках интерпритаторах (например в iDev-OS).

И?

http://www.noritake-itron.com/Web/it...s/Top_Cmd.html
The commands which require a function as a parameter ie IF, RUN, INT and KEY can have the function code embedded inside the commands by enclosing the required code in square brackets.
This allows you to reduce the number of lines of code for simple functions and where the function is unlikely to be used elsewhere.

Т.е. inline func в смысле iDev-OS это лишь "безымянная функция". Разумеется, к ОЛ это никак не относится, т.к. ОЛ макросы именованные и т.п.


wal79 рассказал, то основополагающая методология разработки ОЛ -- спонтанная, и никакие спецификации не нужны. Поэтому и не нужно объяснять что значат "прозрачные макросы", "inline макросы", "линия задержки", "обратная связь", "виртуальные переменные" и далее по списку.

[wal79]

И?

Т.е. inline func в смысле iDev-OS это лишь "безымянная функция". Разумеется, к ОЛ это никак не относится, т.к. ОЛ макросы именованные и т.п.


wal79 рассказал, то основополагающая методология разработки ОЛ -- спонтанная, и никакие спецификации не нужны. Поэтому и не нужно объяснять что значат "прозрачные макросы", "inline макросы", "линия задержки", "обратная связь", "виртуальные переменные" и далее по списку.

Просьба обсуждение перенести в другую ветку.