[haker_fox 0]

4 minutes ago, AlexandrY said:

платформы представляется довольно абсурдным.

Возможно. Но что бы вы предложили с этой точки зрения, если имеетсы платформа на базе Cortex-M3 с ОЗУ 64 кБ?

Впрочем, я не считаю этот подход абсурдным, если отладить весь процесс компиляции, покрыть тестами и убедиться, что это всё работает.

[griabig 0]

3 hours ago, arhiv6 said:

А разве Beremiz поддерживает написание программ на Си и чём-нибудь Си-подобном? Для него же вроде только языки программирования ПЛК используются?

в Beremiz есть расширение, которое позволяет вставлять код на Си, а также поддерживается специальная прагма для Си вставок в МЭК-код.

[AlexandrY 0]

2 hours ago, haker_fox said:

Возможно. Но что бы вы предложили с этой точки зрения, если имеетсы платформа на базе Cortex-M3 с ОЗУ 64 кБ?

Впрочем, я не считаю этот подход абсурдным, если отладить весь процесс компиляции, покрыть тестами и убедиться, что это всё работает.

"Покрыть тестами" - звучит солидно, но не все так просто.
Набор исходников тестов как-то покрывающих некий движок парсера или среды выполнения будет по объему больше исходников самого исследуемого движка. 
Это настолько дорогое удовольствие, что я никогда в жизни не писал покрытия тестами. 

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

Портировал в свое время - http://pro-sign.de/icon-l.html  Мужики стругают свой движок лет 20. 
Технология PLC заключалась в сборке из графического представления программы пользователя в цепочки инструкций вызывающих готовые подпрограммы из среды исполнения на платформе. Т.е. никакой компиляции не было, была по сути трансляция графической декларации в текстовую, которая транслировалась в бинарную декларацию  состоящую из цепочки структур включающих аргументы и ссылки на функции. 
Они умудрялись свой движок засунуть в  3896 байт RAM. 

[haker_fox 0]

4 hours ago, AlexandrY said:

Поэтому мне про "Покрыть тестами",  извините, звучит как анекдот. 

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

4 hours ago, AlexandrY said:

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

Чтож, у крупных контор может быть. В нашем случае довольствуемся малым. В противном случае можно просто сложить лапки, и наблюдать за луной))) Насколько мне известно, тем не менее, даже у крупных контор есть ошибки в их ПЛК.

[mantech 0]

8 часов назад, haker_fox сказал:

Возможно. Но что бы вы предложили с этой точки зрения, если имеетсы платформа на базе Cortex-M3 с ОЗУ 64 кБ?

Впрочем, я не считаю этот подход абсурдным, если отладить весь процесс компиляции, покрыть тестами и убедиться, что это всё работает.

Тут вопрос некорректно задан, ибо клиенту должно быть до лампочки, какой там проц и сколь у него ОЗУ. Ему важно то, что он может сделать на вашей программе, вирт. машине или ОС, может ли он реализовать свои алгоритмы, на необходимом языке и останется-ли еще "пространство для маневров", если да - это и следует выбирать. На счет всяких беремисов и т.п. вы сначала попробуйте все это развернуть у себя, создать рабочий демо-проект, потом сделать для всего этого вменяемую инструкцию, желательно по шагам и с примерами, чтоб человеку не знакомому со всей этой кухней было понятно, тогда это будет хоть как-то доступно к пониманию, а если вы дадите ему вашу железку и скажите "вот там, на гитхабе скачай, установи... и будет тебе счастье, а не понимаешь - твои проблемы, у меня работает..." - то боюсь, больше вы этого клиента никогда не увидите...

[haker_fox 0]

18 minutes ago, mantech said:

то боюсь, больше вы этого клиента никогда не увидите...

Всё правильно говорите!

18 minutes ago, mantech said:

Тут вопрос некорректно задан, ибо клиенту должно быть до лампочки, какой там проц и сколь у него ОЗУ

Почему же некорректен? Корректен.

[demiurg_spb 0]

On 9/18/2019 at 4:54 PM, mantech said:

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

Забейте в гугле "beremiz руководство" и увидите доку на русском языке...

[Tarbal 0]

А почему не пойти стандартным путем. Написать кросс компилятор языка на Flex/Bison.

Все исходники можно взять для GCC.

Будет у вас версия GCC для вашей системы.

[haker_fox 0]

12 minutes ago, Tarbal said:

Будет у вас версия GCC для вашей системы.

Насколько я понял, тогда уж лучше llvm. С ним всё проще. Это из статей я такую информацию почерпнул. И я даже пробовал им получить машиннонезависимый байт-код. Но теперь мы идём другим путём - родной компилятор, родной код, но под контролем MPU и в пользовательском режиме. Т.е. аналог маленького ПК))

[AlexandrY 0]

2 hours ago, Tarbal said:

Будет у вас версия GCC для вашей системы.

А покрывать тестами кто будет? 

[Tarbal 0]

23 hours ago, haker_fox said:

Насколько я понял, тогда уж лучше llvm. С ним всё проще. Это из статей я такую информацию почерпнул. И я даже пробовал им получить машиннонезависимый байт-код. Но теперь мы идём другим путём - родной компилятор, родной код, но под контролем MPU и в пользовательском режиме. Т.е. аналог маленького ПК))

Вроде как одно другому не мешает.
https://gnuu.org/2009/09/18/writing-your-own-toy-compiler/
Flex и Bison -- это инструменты для написания компилятора для любого языка.

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

[haker_fox 0]

3 hours ago, Tarbal said:

Вроде как одно другому не мешает.

За статью спасибо, интересная! Но мы уже приняли решение делать нативным компилятором прогу. Это просто быстрее.

[AlexandrY 0]

3 hours ago, haker_fox said:

Но мы уже приняли решение делать нативным компилятором прогу. Это просто быстрее.

Я бы подумал о применении MATLAB-а для этих целей. Какую нибудь легковесную лицензию без навороченных тулбоксов. 
В Matlab  есть проработанная технология мапирования API платформы в блоки Simulink.
Скажем CMSIS там уже отмапировано. Есть уже готовые блоки драйверов периферии к чипам от ST, Infineon, NXP...

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

[jcxz 0]

1 час назад, AlexandrY сказал:

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

Ну да: сначала он будет кувыркаться с отладкой в Матлаб, а потом то же самое делать на железе. К тому же ему кроме си дополнительно придётся изучать Матлаб (не все специалисты его знают "из коробки") 

[Uuftc 0]

On 9/24/2019 at 7:20 AM, haker_fox said:

Но теперь мы идём другим путём - родной компилятор, родной код, но под контролем MPU и в пользовательском режиме.

Была аналогичная задача. После долгих проб различных вариантов делал именно через MPU. Остался доволен и производительностью и внезапной простотой и изяществом такого подхода.

Удачи.