Своя реализация G
-
- beginner
- Сообщения: 27
- Зарегистрирован: 20 окт 2014, 10:35
- Версия LabVIEW: 2010 linux
- Контактная информация:
Своя реализация G
Доброго всем дня.
Подумал над такой не сложной вещью, как написать свой компилятор своего языка, похожего на G, называть пока его как-то не берусь. Идея следующая, превращать графически представленную программу в код gnuc. Обойтись думаю без визуализации(формочек с кнопочками), кому она нужна, тот её подключит сам через ShellAPI или x11. С параллелизмом думаю тут нужно ещё подумать как-то. Теперь думаю над тем, как должен работать компилятор. Прошу обсуждений именно процесса компиляции. Я вижу этот процесс так.
1. Компилятор анализирует блок диаграмму и находит конечный элемент, который зависит от всех предыдущих. (если не рассматривать параллелизм, то он один)
2. К. строит код этого элемента в функции main (вызывается по умолчанию в c++ при запуске программы). Этот код имеет указатели на какие-то значения (аналог входных параметров SubVI)
3. Создаёт функции для субприборов, от которых зависит предыдущая функция, записывая их указатель в предыдущую.
4. Продолжать развертывать таким же образом, пока не будут обработаны все SubVI
5. Компилировать код GNU C компилятором.
Думаю тут самым сложным будет реализация структур: циклов, событий итд.
Подумал над такой не сложной вещью, как написать свой компилятор своего языка, похожего на G, называть пока его как-то не берусь. Идея следующая, превращать графически представленную программу в код gnuc. Обойтись думаю без визуализации(формочек с кнопочками), кому она нужна, тот её подключит сам через ShellAPI или x11. С параллелизмом думаю тут нужно ещё подумать как-то. Теперь думаю над тем, как должен работать компилятор. Прошу обсуждений именно процесса компиляции. Я вижу этот процесс так.
1. Компилятор анализирует блок диаграмму и находит конечный элемент, который зависит от всех предыдущих. (если не рассматривать параллелизм, то он один)
2. К. строит код этого элемента в функции main (вызывается по умолчанию в c++ при запуске программы). Этот код имеет указатели на какие-то значения (аналог входных параметров SubVI)
3. Создаёт функции для субприборов, от которых зависит предыдущая функция, записывая их указатель в предыдущую.
4. Продолжать развертывать таким же образом, пока не будут обработаны все SubVI
5. Компилировать код GNU C компилятором.
Думаю тут самым сложным будет реализация структур: циклов, событий итд.
-
Kosist
- expert
- Сообщения: 1236
- Зарегистрирован: 21 фев 2011, 23:44
- Награды: 2
- Версия LabVIEW: 2013-2020
- Благодарил (а): 23 раза
- Поблагодарили: 30 раз
- Контактная информация:
Re: Своя реализация G
Интерестная идея, ведь каждый программист мечтает создать свою операционную систему, верно? А целесообразно ли это? Ведь время и ресурсы для решения этой задачи можна потратить на изучение, глубокое изучение того же - ведь здесь нужно копать и копать, работы - не начатое поле...
Но - желаю удачи во всех начинаниях!
Но - желаю удачи во всех начинаниях!
Мы делили апельсин - много наших полегло...
-
- VIP
- Сообщения: 1337
- Зарегистрирован: 03 фев 2010, 00:42
- Награды: 6
- Версия LabVIEW: 6.1 - 2024
- Откуда: Германия
- Благодарил (а): 1 раз
- Поблагодарили: 44 раза
- Контактная информация:
Re: Своя реализация G
Думаю сначала нужно освоить курс "основы построения компиляторов". В интернете достаточно информации по этой теме. Тогда размышления типа "Думаю тут самым сложным будет реализация структур: циклов, событий итд." отпадут сами собой.
Альфред В. Ахо, Моника С. Лам, Рави Сети, Джеффри Д. Ульман. Компиляторы: принципы, технологии и инструментарий = Compilers: Principles, Techniques, and Tools. — 2-е изд. — М.: Вильямс, 2010. — 1184 с. — ISBN 978-5-8459-1349-4.
Робин Хантер. Основные концепции компиляторов = The Essence of Compilers. — М.: Вильямс, 2002. — 256 с. — ISBN 0-13-727835-7.
Хантер Р. Проектирование и конструирование компиляторов / Пер. с англ. С. М. Круговой. — М.: Финансы и статистика, 1984. — 232 с.
Д. Креншоу. Давайте создадим компилятор!
Серебряков В. А., Галочкин М. П. Основы конструирования компиляторов.
Во-вторых, удобнее будет не в Си это дело перегонять, а в псевдокод LLVM, ну и затем уже компилировать в бинарный код.
http://habrahabr.ru/post/47878/
http://habrahabr.ru/post/119850/
Собственно, LabVIEW точно так и поступает.
Альфред В. Ахо, Моника С. Лам, Рави Сети, Джеффри Д. Ульман. Компиляторы: принципы, технологии и инструментарий = Compilers: Principles, Techniques, and Tools. — 2-е изд. — М.: Вильямс, 2010. — 1184 с. — ISBN 978-5-8459-1349-4.
Робин Хантер. Основные концепции компиляторов = The Essence of Compilers. — М.: Вильямс, 2002. — 256 с. — ISBN 0-13-727835-7.
Хантер Р. Проектирование и конструирование компиляторов / Пер. с англ. С. М. Круговой. — М.: Финансы и статистика, 1984. — 232 с.
Д. Креншоу. Давайте создадим компилятор!
Серебряков В. А., Галочкин М. П. Основы конструирования компиляторов.
Во-вторых, удобнее будет не в Си это дело перегонять, а в псевдокод LLVM, ну и затем уже компилировать в бинарный код.
http://habrahabr.ru/post/47878/
http://habrahabr.ru/post/119850/
Собственно, LabVIEW точно так и поступает.
-
- beginner
- Сообщения: 27
- Зарегистрирован: 20 окт 2014, 10:35
- Версия LabVIEW: 2010 linux
- Контактная информация:
Re: Своя реализация G
Не понимаю, почему все хочется подчеркнуть чужую некомпетенцию в чём либо, оправданно или нет. Я предлагаю серьезную идею, которая не находится на грани фантастики, заключается она в том, что бы сделать транслятор графического представления функций в текстовый. Предлагаю обсуждать пути решения этой задачи.
Что касается компиляции с низкоуровневой стороны у меня вопросов нет, я пойду по пути GCC, то есть один код буду превращать в более низкоуровневый, более низкоуровневый ещё в более итд, не хочу изобретать велосипед. Решил я получать С код. Как работает GCC я то же отлично понимаю.
Под словом компиляция я имею виду трансляцию кода с более высокого уровня на более низкий, а не всё вместе с процессом перевода до ассемблера+трансляцией до кода приложения ОС. Так вот и сложности у меня со структурами именно в алгоритме перевода графического языка в C код.
Думаю, если реализовать минимальный набор функций в своём языке, я смогу написать остальные на высоком уровне своим же языком.
Я считаю, что LabVIEW освоил достаточно, что бы решать свои задачи, с решением новых задач освою те его части, которые ещё не освоил. Так же понимаю, что этот язык хорош для разработки алгоритмов, т.к. позволяет быстро удобно и наглядно его корректировать, а вот для получения конечной программы как-то мне он мне не по душе. Программа громоздкая, куча зависимостей (рантаймы итд). Делает непонятные для меня вещи во время запуска. (покопайтесь отладчиками, будете удивлены). Вот и родилась у меня идея создания графической среды программирования, которая способна создать нормальные исполняемые программы без интерпретатора, хоть внутреннего, хоть внешнего.Думаю сначала нужно освоить курс "основы построения компиляторов". В интернете достаточно информации по этой теме. Тогда размышления типа "Думаю тут самым сложным будет реализация структур: циклов, событий итд." отпадут сами собой.
Что касается компиляции с низкоуровневой стороны у меня вопросов нет, я пойду по пути GCC, то есть один код буду превращать в более низкоуровневый, более низкоуровневый ещё в более итд, не хочу изобретать велосипед. Решил я получать С код. Как работает GCC я то же отлично понимаю.
Под словом компиляция я имею виду трансляцию кода с более высокого уровня на более низкий, а не всё вместе с процессом перевода до ассемблера+трансляцией до кода приложения ОС. Так вот и сложности у меня со структурами именно в алгоритме перевода графического языка в C код.
Целесообразно, если в дальнейшем пользоваться этим языком для создания своих приложений. И это на так уж сложно, я вполне представляю, как это реализовать. Большей сложностью думаю будет написать "графический редактор" для всего этого дела.Интерестная идея, ведь каждый программист мечтает создать свою операционную систему, верно? А целесообразно ли это? Ведь время и ресурсы для решения этой задачи можна потратить на изучение, глубокое изучение того же - ведь здесь нужно копать и копать, работы - не начатое поле...
Но - желаю удачи во всех начинаниях!
Думаю, если реализовать минимальный набор функций в своём языке, я смогу написать остальные на высоком уровне своим же языком.
-
- doctor
- Сообщения: 2211
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 27 раз
Re: Своя реализация G
Делает непонятные для меня вещи во время запуска.
А что вы хотите? Предлагаю покопать, как запускается .Net - тоже много интересного узнаете. А , как система - очень сложная и развивается уже лет 20 (прикиньте сотни тысяч человеко-часов на ее разработку). Количество поддерживаемого оборудования огромное, так что чему удивляться? В свое время была поддержка компиляции под PDA (отдельный модуль). Там транслировался код в C++, чтобы микрософтовский компилятор мог сделать исполняемый файл под Windows CE. Хочется изобрести велосипед? Как только вам понадобится сделать компилятор, нормально поддерживающий хотя-бы минимум предложенного функционала, поймете - в одиночку эту работу делать бесполезно.
Кстати, хочу обратить ваше внимание на то, что базируется на идеологии потоков и многопоточности, в том числе использование параллельных вычислений во многоядерных системах, чего под сями так просто не сделать. Что касается оптимизации, то при грамотном программировании производительность будет не хуже, чем под C++.
Чтобы было понятнее, как транслировать графическое представление, надо понимать модель этого представления в Модель вообще-то простая - линии, соединяющие объекты - это локальные переменные. функция вызывается, когда все необходимые переменные становятся доступны. вам только надо построить дерево необходимых данных внутри потока.
Последний раз редактировалось Borjomy_1 21 окт 2014, 13:10, всего редактировалось 1 раз.
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Re: Своя реализация G
Интересно то, что лабвью изначально задумывался не как инструмент для
чистого программиста и только программиста, хорошо владеющего С и
другими текстовыми языками, но не достаточно понимающего всю технологию
инженерного обьекта,
а как инструмент некого инженера, который работает с графическим материалом
например електросхемами, принципиальными, монтажными, разводками
трубных проводок, распределительный сетей, и тому подобное, спектр
очень широк, хорошо знающего свой технологический обьект и знакомого
лишь с некоторыми основами текстязыкового программирования.
Я лично предпочел пойти другим путем
http://labviewportal.org/viewtopic.php? ... =45#p43928
чистого программиста и только программиста, хорошо владеющего С и
другими текстовыми языками, но не достаточно понимающего всю технологию
инженерного обьекта,
а как инструмент некого инженера, который работает с графическим материалом
например електросхемами, принципиальными, монтажными, разводками
трубных проводок, распределительный сетей, и тому подобное, спектр
очень широк, хорошо знающего свой технологический обьект и знакомого
лишь с некоторыми основами текстязыкового программирования.
Я лично предпочел пойти другим путем
http://labviewportal.org/viewtopic.php? ... =45#p43928
-
- beginner
- Сообщения: 27
- Зарегистрирован: 20 окт 2014, 10:35
- Версия LabVIEW: 2010 linux
- Контактная информация:
Re: Своя реализация G
Думаю, что параллелизм можно реализовать так, каждая параллель запускается в новом процессе (одна exeшка, но запускается в инной среде {arc,arv,envp}, примером будет chrome.exe), и уже именно ОС, а это её задача, а не интерпретатор, занимается задачей параллелизма, а связь между процессами реализовать хоть через tcp/ip, если в windows для этого не догадались внутренние сокеты сделать. Не потребуется адаптация к многопроцессорным системам, ведь это опять же задача ОС. А писать верхи, заново вряд-ли нужно, если есть исходник SubVI, его будет легко портировать. Можно и не потерять 20ти летний труд других людей, если он конечно opensource.
-
- beginner
- Сообщения: 27
- Зарегистрирован: 20 окт 2014, 10:35
- Версия LabVIEW: 2010 linux
- Контактная информация:
Re: Своя реализация G
Раз уж речь о велосипеде, а такой компилятор есть? И по поводу компилятора, а зачем ему уметь делать что-то на низком уровне, кроме элементарных функций при помощи которых можно будет реализовать остальные тем же языком?Хочется изобрести велосипед? Как только вам понадобится сделать компилятор, нормально поддерживающий хотя-бы минимум предложенного функционала, поймете - в одиночку эту работу делать бесполезно.
-
- doctor
- Сообщения: 2211
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 27 раз
Re: Своя реализация G
Это уже не смешно... Про обмен через TCP и комментировать не буду. Вот я делаю программку сейчас, не очень сложную. Уже сейчас, навскидку, более сотни потоков набегает. Каждый цикл в выполняется в отдельном потоке. У меня есть проект, в котором потоков еще больше и специально сделано распараллеливание даже элементарных задач. А про поддержку ядер - уже достаточно давно можно указывать, на каких ядрах будет выполняться поток. И это не задача ОС. Это задача самого ПО, определять, на каком ядре оно выполняется. Классический пример: 4-ядерный I5, на нем крутится Opera. Одна из вкладок на ней грузит проц. Так вот общая загрузка процессора не превышает 25%, а Opera буквально встает. И ОС не раскидывает ее нагрузку по другим ядрам.каждая параллель запускается в новом процессе
-
- beginner
- Сообщения: 27
- Зарегистрирован: 20 окт 2014, 10:35
- Версия LabVIEW: 2010 linux
- Контактная информация:
Re: Своя реализация G
Процессы можно принудительно привязывать к ядру и так же указывать многое другое. Не думаю, что тут есть что-то смешное. Про связь по TCP, что тут смешного? В LabVIEW потоки (Stream) работают через службы LabVIEW связанные с GPIB ни чёть не быстрее. А про параллелизм, который обеспечивается внутренним интерпретатором, он же ведь по сути делает то же самое, что и два процесса в ОС. В чём же по Вашему разница, кроме той, что он берёт часть обязательств ОС на себя? (задача многозадачности ОС)Borjomy_1 писал(а):Это уже не смешно... Про обмен через TCP и комментировать не буду. Вот я делаю программку сейчас, не очень сложную. Уже сейчас, навскидку, более сотни потоков набегает. Каждый цикл в выполняется в отдельном потоке. У меня есть проект, в котором потоков еще больше и специально сделано распараллеливание даже элементарных задач. А про поддержку ядер - уже достаточно давно можно указывать, на каких ядрах будет выполняться поток. И это не задача ОС. Это задача самого ПО, определять, на каком ядре оно выполняется. Классический пример: 4-ядерный I5, на нем крутится Opera. Одна из вкладок на ней грузит проц. Так вот общая загрузка процессора не превышает 25%, а Opera буквально встает. И ОС не раскидывает ее нагрузку по другим ядрам.каждая параллель запускается в новом процессе
Не очень компетентен в программирование под Windows в вопросе потоков, но думаю, что есть и другой способ связи двух процессов, по типу сокетов Unix. Как минимум, можно и stdin/out использовать, если кому tcp/ip не нравится, но связь по tcp позволяет с лёгкостью разделить сложную обработку на несколько машин.
Конечно в случае интерпретатора будет экономия ОЗУ (+), но потеря в производительности (-) на трансляцию кода в реальном времени.
Последний раз редактировалось Данил 21 окт 2014, 14:34, всего редактировалось 1 раз.
-
- doctor
- Сообщения: 2211
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 27 раз
Re: Своя реализация G
Разницу между процессом и потоком ощущаете? Под поток можно привязывать к ядру.
Не быстрее чего, С-шного кода? Откуда такая информация, на каких примерах? Да и вообще - то, что программа под работает сравнимо по быстродействию с Сишной реализацией, при на порядок более простом программировании - это, извините, нулевой довод.В LabVIEW потоки (Stream) работают через службы LabVIEW связанные с GPIB ни чёть не быстрее
-
- beginner
- Сообщения: 27
- Зарегистрирован: 20 окт 2014, 10:35
- Версия LabVIEW: 2010 linux
- Контактная информация:
Re: Своя реализация G
К примеру установите LabVIEW на свежую машину и не перезагружайтесь, откройте исходник с потоками и попробуйте запустить. Ошибка: не удалось подключиться к GPIB службе (вот что будет, если вы растолкуйте код ошибки любой операции с потоками). Под Wndows процесс так же можно привязать к конкретному ядру.Borjomy_1 писал(а):Разницу между процессом и потоком ощущаете? Под поток можно привязывать к ядру.
Не быстрее чего, С-шного кода? Откуда такая информация, на каких примерах? Да и вообще - то, что программа под работает сравнимо по быстродействию с Сишной реализацией, при на порядок более простом программировании - это, извините, нулевой довод.В LabVIEW потоки (Stream) работают через службы LabVIEW связанные с GPIB ни чёть не быстрее
Да и дело не в этом, тут вообще дискуссия не об этом, а о том, как реализовать компилятор, то что он для меня будет полезен я знаю, и для многих других уверен то же будет полезен.
- Super Star
- adviser
- Сообщения: 228
- Зарегистрирован: 07 фев 2013, 08:37
- Версия LabVIEW: 2011
Re: Своя реализация G
лучше реализовать "софт", который из VI будет делать блок-диаграмму в Visio
я люблю свою работу.... Я приду сюда в субботу ...
-
- doctor
- Сообщения: 2211
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 27 раз
Re: Своя реализация G
Хм... что-то я не припомню проблем с запуском VI после установки версии без перезапуска компа.
Что касается самого компилятора, то так как я заканчивал институт по этой части (теория компиляции), то ваши вопросы вызывают некоторое недоумение. Для начала предложил-бы вам начать с классики - компилятор Бейсика. В принципе, ничем особенным от него не отличается. Разве что лексическим представлением (т.е вместо символов графические элементы).
Что касается самого компилятора, то так как я заканчивал институт по этой части (теория компиляции), то ваши вопросы вызывают некоторое недоумение. Для начала предложил-бы вам начать с классики - компилятор Бейсика. В принципе, ничем особенным от него не отличается. Разве что лексическим представлением (т.е вместо символов графические элементы).
-
IvanLis
- guru
- Сообщения: 5467
- Зарегистрирован: 02 дек 2009, 17:44
- Награды: 7
- Версия LabVIEW: 2015, 2016
- Откуда: СССР
- Благодарил (а): 28 раз
- Поблагодарили: 87 раз
Re: Своя реализация G
Как говориться "Чем бы дитя не тешилось - лишь бы не руками"
В первую очередь определитесь, что Вы хотите. Транслятор или компилятор, судя по постам, именно транслятор мнемосхем в код С.
Посмотрите проект FLProg (http://flprog.ru/), там решается подобная задача (http://flprog.ru/FLProg/pid218088913/si ... i217633534).
Можете пообщаться с автором, может найдете общий язык.
Наличие свободного времени это хорошо, а еще лучше если Вы его будите расходовать с пользой
В первую очередь определитесь, что Вы хотите. Транслятор или компилятор, судя по постам, именно транслятор мнемосхем в код С.
Посмотрите проект FLProg (http://flprog.ru/), там решается подобная задача (http://flprog.ru/FLProg/pid218088913/si ... i217633534).
Можете пообщаться с автором, может найдете общий язык.
Наличие свободного времени это хорошо, а еще лучше если Вы его будите расходовать с пользой
Знание нескольких принципов освобождает от знания многих фактов!
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...