Hardella IDE

[Yegor]

И как?

Весело. Как там нынче с копи-пастом в проекционных редакторах?

Error: type DWORD is not a subtype of BYTE

Аккуратнее с этой фигнёй. BYTE, WORD и DWORD вообще не являются числами по стандарту 61131-3. Для них не определены арифметические операции и прочая числовая семантика. Это битовые поля. Если уж взялись, то рекомендую открыть стандарт и попробовать сделать по нему, а не как в кодесисе (для которого INT#TRUE является числом, например).

Т.е. добавляем отдельный блок "BEGIN ... END;", разрешаем объявлять локальные переменные/константы прямо посреди кода (или только сразу после begin/if/while, чтобы уж совсем говнокод не плодить), добавляем возможность наследования структур, объявления методов в них и получится норм?

Я думаю, отдельным блоком переменные сделаны не просто так. Это часть поддержки редактирования программ на работающем контроллере и часть единообразия с графическими языками. Мне б тоже хотелось анонимные функторы типа IF TON#(IN := x, PT := y).Q THEN ..., но это уже совсем другой язык получается.

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

А чего мелочиться? Прикрутить сюда кодогенерацию через тот же LLVM, а там и до отладчиков недалеко.

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

Весело. Как там нынче с копи-пастом в проекционных редакторах?

Своеобразно, но норм: https://www.youtube.com/watch?v=o4PN...=youtu.be&t=90

Аккуратнее с этой фигнёй. BYTE, WORD и DWORD вообще не являются числами по стандарту 61131-3. Для них не определены арифметические операции и прочая числовая семантика. Это битовые поля. Если уж взялись, то рекомендую открыть стандарт и попробовать сделать по нему, а не как в кодесисе (для которого INT#TRUE является числом, например).

Ну, в стандарте так и сказано, что "результат приведения типов, не описанных явно отдаётся на откуп производителю".
Но INT#TRUE, это, безусловно, жесть.

А неявное преобразование BYTE -> WORD, скорее норма.
Аналогично и неявные преобразования между USINT <-> BYTE. Чего в этом плохого?
А чего плохого в том, чтобы в WORD переменную можно было записать BYTE значение?
Не на ассемблере же пишем.

Мне, на самом деле, не нравится, что в CS результат сложения BYTE и BYTE получается BYTE (в стандарте, к слову, так же). Мне бы больше по душе было получать WORD (т.е. чтобы не терять данные). А уж если нужно в конце концов в BYTE получить, то явное преобразование.

Мне б тоже хотелось анонимные функторы типа IF TON#(IN := x, PT := y).Q THEN ..., но это уже совсем другой язык получается.

Вроде, тот же самый язык. Но, конечно, тут семантически тонко будет в операциях вида IF TON#(...).Q OR TON#(...). "до второй части выполнение может не дойти и т.п."
Т.е. легко ошибиться, что, конечно, нехорошо.

А чего мелочиться? Прикрутить сюда кодогенерацию через тот же LLVM, а там и до отладчиков недалеко.

Воообще, я пока не пойму каким образом идёт обмен данными с контроллером.
Делать runtime с нуля немного странно.
Вот если можно в каком-то "стандартном" формате скармливать скомпилированный проект в контроллер (например, прикидываемся CoDeSys'ом, и кормим бинарник в овен), то, конечно, интересно.

И ещё: если сохранить похожесть на 61131, то есть простой и понятный переход со старых проектов на новые. Или постепенно заменять блоки.
А если целиком с нуля runtime делать, то, может, вообще проще взять mbeddr ide и фигачить на C? Но C это другая история.

[rapucha]

сложения BYTE и BYTE

Я наоборот, скорее не понимаю смысла такого сложения. BYTE явно пришел нам из железа, и ничего кроме битовых операций я бы к нему не применял. Даже если это АЦП, в нашей реалии на него надо навернуть калибровку датчика и получить real.
А если надо, то сперва явно кастовал бы BYTE к нужному типу. Но то дело вкуса, во многом.

о второй части выполнение может не дойти и т.п.

эксепшенами пахнет?

а железо какое-нибудь найдётся

Фиг знает. Я в текущем проекте пишу на CoDeSys только потому, что нашелся у Овена сносный контроллер -- пром. исполнения, умеренно безглючный, быстро покупаемый и с живым саппортом/форумом. Смог бы купить промышленного исполнения встраиваемую плату - все было бы иначе. Втолкаться в готовое железо мне казалось бы хорошей идеей.

Другое дело, что рантайм можно спросить у фирмы 3S, я бы на их месте обрадовался и отдал бы что-нибудь типа кодесис-ядра под линукс. Спросив сперва NDA возможно. Как проект это все было бы круто, интересно и молодежно, карма на хабре вверх и все дела))
Но в суровой промышленной жизни разнообразные RPi и проч. недорогие ардуины не выживут. Разве что сделать под них отдельный бокс с фильтрацией питаний, развязкой входов-выходов и так далее. Кстати, может быть это коммерческая ниша?..

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

Я наоборот, скорее не понимаю смысла такого сложения. BYTE явно пришел нам из железа, и ничего кроме битовых операций я бы к нему не применял

Какой смысл иметь два разных беззнаковых типа?
Чем USINT принципиально отличается от BYTE?
Честное слово, не понимаю.

Да и сами по себе беззнаковые типы не нужны. От них только проблемы: http://www.nayuki.io/page/unsigned-i...rmful-for-java
Т.е. знаковые типы + явные операции для того, чтобы работать "как будто с беззнаковыми" и всего делов.

эксепшенами пахнет?

Нет. Речь о том, что при вычислении FALSE AND ... вторую половину AND'а можно и не вычислять -- всё равно понятно что суммарно false будет.

[rapucha]

Какой смысл иметь два разных беззнаковых типа?
Чем USINT принципиально отличается от BYTE?
Честное слово, не понимаю.

семантика, извиняюсь, разная. byte это набор бит, отражающий состояние железа. делать над ним арифметику -- нет смысла.

Т.е. знаковые типы + явные операции для того, чтобы работать "как будто с беззнаковыми" и всего делов.

мне строгая типизация как-то больше по душе. Меньше шансов налажать, особенно при работе с чужим кодом/библиотеками.

прошу прощения, убегаю, буду рад продолжить вечером