LabVIEW Portal

Доброго всем дня.
Подумал над такой не сложной вещью, как написать свой компилятор своего языка, похожего на G, называть пока его как-то не берусь. Идея следующая, превращать графически представленную программу в код gnuc. Обойтись думаю без визуализации(формочек с кнопочками), кому она нужна, тот её подключит сам через ShellAPI или x11. С параллелизмом думаю тут нужно ещё подумать как-то. Теперь думаю над тем, как должен работать компилятор. Прошу обсуждений именно процесса компиляции. Я вижу этот процесс так.
1. Компилятор анализирует блок диаграмму и находит конечный элемент, который зависит от всех предыдущих. (если не рассматривать параллелизм, то он один)
2. К. строит код этого элемента в функции main (вызывается по умолчанию в c++ при запуске программы). Этот код имеет указатели на какие-то значения (аналог входных параметров SubVI)
3. Создаёт функции для субприборов, от которых зависит предыдущая функция, записывая их указатель в предыдущую.
4. Продолжать развертывать таким же образом, пока не будут обработаны все SubVI
5. Компилировать код GNU C компилятором.
Думаю тут самым сложным будет реализация структур: циклов, событий итд.

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

Думаю сначала нужно освоить курс "основы построения компиляторов". В интернете достаточно информации по этой теме. Тогда размышления типа "Думаю тут самым сложным будет реализация структур: циклов, событий итд." отпадут сами собой.

Альфред В. Ахо, Моника С. Лам, Рави Сети, Джеффри Д. Ульман. Компиляторы: принципы, технологии и инструментарий = 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 точно так и поступает.

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

Думаю сначала нужно освоить курс "основы построения компиляторов". В интернете достаточно информации по этой теме. Тогда размышления типа "Думаю тут самым сложным будет реализация структур: циклов, событий итд." отпадут сами собой.

Я считаю, что LabVIEW освоил достаточно, что бы решать свои задачи, с решением новых задач освою те его части, которые ещё не освоил. Так же понимаю, что этот язык хорош для разработки алгоритмов, т.к. позволяет быстро удобно и наглядно его корректировать, а вот для получения конечной программы как-то мне он мне не по душе. Программа громоздкая, куча зависимостей (рантаймы итд). Делает непонятные для меня вещи во время запуска. (покопайтесь отладчиками, будете удивлены). Вот и родилась у меня идея создания графической среды программирования, которая способна создать нормальные исполняемые программы без интерпретатора, хоть внутреннего, хоть внешнего.
Что касается компиляции с низкоуровневой стороны у меня вопросов нет, я пойду по пути GCC, то есть один код буду превращать в более низкоуровневый, более низкоуровневый ещё в более итд, не хочу изобретать велосипед. Решил я получать С код. Как работает GCC я то же отлично понимаю.
Под словом компиляция я имею виду трансляцию кода с более высокого уровня на более низкий, а не всё вместе с процессом перевода до ассемблера+трансляцией до кода приложения ОС. Так вот и сложности у меня со структурами именно в алгоритме перевода графического языка в C код.

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

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

Делает непонятные для меня вещи во время запуска.

А что вы хотите? Предлагаю покопать, как запускается .Net - тоже много интересного узнаете. А , как система - очень сложная и развивается уже лет 20 (прикиньте сотни тысяч человеко-часов на ее разработку). Количество поддерживаемого оборудования огромное, так что чему удивляться? В свое время была поддержка компиляции под PDA (отдельный модуль). Там транслировался код в C++, чтобы микрософтовский компилятор мог сделать исполняемый файл под Windows CE. Хочется изобрести велосипед? Как только вам понадобится сделать компилятор, нормально поддерживающий хотя-бы минимум предложенного функционала, поймете - в одиночку эту работу делать бесполезно.
Кстати, хочу обратить ваше внимание на то, что базируется на идеологии потоков и многопоточности, в том числе использование параллельных вычислений во многоядерных системах, чего под сями так просто не сделать. Что касается оптимизации, то при грамотном программировании производительность будет не хуже, чем под C++.

Чтобы было понятнее, как транслировать графическое представление, надо понимать модель этого представления в Модель вообще-то простая - линии, соединяющие объекты - это локальные переменные. функция вызывается, когда все необходимые переменные становятся доступны. вам только надо построить дерево необходимых данных внутри потока.

Интересно то, что лабвью изначально задумывался не как инструмент для
чистого программиста и только программиста, хорошо владеющего С и
другими текстовыми языками, но не достаточно понимающего всю технологию
инженерного обьекта,
а как инструмент некого инженера, который работает с графическим материалом
например електросхемами, принципиальными, монтажными, разводками
трубных проводок, распределительный сетей, и тому подобное, спектр
очень широк, хорошо знающего свой технологический обьект и знакомого
лишь с некоторыми основами текстязыкового программирования.
Я лично предпочел пойти другим путем
http://labviewportal.org/viewtopic.php? ... =45#p43928

Думаю, что параллелизм можно реализовать так, каждая параллель запускается в новом процессе (одна exeшка, но запускается в инной среде {arc,arv,envp}, примером будет chrome.exe), и уже именно ОС, а это её задача, а не интерпретатор, занимается задачей параллелизма, а связь между процессами реализовать хоть через tcp/ip, если в windows для этого не догадались внутренние сокеты сделать. Не потребуется адаптация к многопроцессорным системам, ведь это опять же задача ОС. А писать верхи, заново вряд-ли нужно, если есть исходник SubVI, его будет легко портировать. Можно и не потерять 20ти летний труд других людей, если он конечно opensource.

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

Раз уж речь о велосипеде, а такой компилятор есть? И по поводу компилятора, а зачем ему уметь делать что-то на низком уровне, кроме элементарных функций при помощи которых можно будет реализовать остальные тем же языком?

каждая параллель запускается в новом процессе

Это уже не смешно... Про обмен через TCP и комментировать не буду. Вот я делаю программку сейчас, не очень сложную. Уже сейчас, навскидку, более сотни потоков набегает. Каждый цикл в выполняется в отдельном потоке. У меня есть проект, в котором потоков еще больше и специально сделано распараллеливание даже элементарных задач. А про поддержку ядер - уже достаточно давно можно указывать, на каких ядрах будет выполняться поток. И это не задача ОС. Это задача самого ПО, определять, на каком ядре оно выполняется. Классический пример: 4-ядерный I5, на нем крутится Opera. Одна из вкладок на ней грузит проц. Так вот общая загрузка процессора не превышает 25%, а Opera буквально встает. И ОС не раскидывает ее нагрузку по другим ядрам.

Borjomy_1 писал(а):

каждая параллель запускается в новом процессе

Это уже не смешно... Про обмен через TCP и комментировать не буду. Вот я делаю программку сейчас, не очень сложную. Уже сейчас, навскидку, более сотни потоков набегает. Каждый цикл в выполняется в отдельном потоке. У меня есть проект, в котором потоков еще больше и специально сделано распараллеливание даже элементарных задач. А про поддержку ядер - уже достаточно давно можно указывать, на каких ядрах будет выполняться поток. И это не задача ОС. Это задача самого ПО, определять, на каком ядре оно выполняется. Классический пример: 4-ядерный I5, на нем крутится Opera. Одна из вкладок на ней грузит проц. Так вот общая загрузка процессора не превышает 25%, а Opera буквально встает. И ОС не раскидывает ее нагрузку по другим ядрам.

Процессы можно принудительно привязывать к ядру и так же указывать многое другое. Не думаю, что тут есть что-то смешное. Про связь по TCP, что тут смешного? В LabVIEW потоки (Stream) работают через службы LabVIEW связанные с GPIB ни чёть не быстрее. А про параллелизм, который обеспечивается внутренним интерпретатором, он же ведь по сути делает то же самое, что и два процесса в ОС. В чём же по Вашему разница, кроме той, что он берёт часть обязательств ОС на себя? (задача многозадачности ОС)
Не очень компетентен в программирование под Windows в вопросе потоков, но думаю, что есть и другой способ связи двух процессов, по типу сокетов Unix. Как минимум, можно и stdin/out использовать, если кому tcp/ip не нравится, но связь по tcp позволяет с лёгкостью разделить сложную обработку на несколько машин.
Конечно в случае интерпретатора будет экономия ОЗУ (+), но потеря в производительности (-) на трансляцию кода в реальном времени.

Разницу между процессом и потоком ощущаете? Под поток можно привязывать к ядру.

В LabVIEW потоки (Stream) работают через службы LabVIEW связанные с GPIB ни чёть не быстрее

Не быстрее чего, С-шного кода? Откуда такая информация, на каких примерах? Да и вообще - то, что программа под работает сравнимо по быстродействию с Сишной реализацией, при на порядок более простом программировании - это, извините, нулевой довод.

Borjomy_1 писал(а):Разницу между процессом и потоком ощущаете? Под поток можно привязывать к ядру.

В LabVIEW потоки (Stream) работают через службы LabVIEW связанные с GPIB ни чёть не быстрее

Не быстрее чего, С-шного кода? Откуда такая информация, на каких примерах? Да и вообще - то, что программа под работает сравнимо по быстродействию с Сишной реализацией, при на порядок более простом программировании - это, извините, нулевой довод.

К примеру установите LabVIEW на свежую машину и не перезагружайтесь, откройте исходник с потоками и попробуйте запустить. Ошибка: не удалось подключиться к GPIB службе (вот что будет, если вы растолкуйте код ошибки любой операции с потоками). Под Wndows процесс так же можно привязать к конкретному ядру.
Да и дело не в этом, тут вообще дискуссия не об этом, а о том, как реализовать компилятор, то что он для меня будет полезен я знаю, и для многих других уверен то же будет полезен.

лучше реализовать "софт", который из VI будет делать блок-диаграмму в Visio

Хм... что-то я не припомню проблем с запуском VI после установки версии без перезапуска компа.

Что касается самого компилятора, то так как я заканчивал институт по этой части (теория компиляции), то ваши вопросы вызывают некоторое недоумение. Для начала предложил-бы вам начать с классики - компилятор Бейсика. В принципе, ничем особенным от него не отличается. Разве что лексическим представлением (т.е вместо символов графические элементы).

Как говориться "Чем бы дитя не тешилось - лишь бы не руками"

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

Посмотрите проект FLProg (http://flprog.ru/), там решается подобная задача (http://flprog.ru/FLProg/pid218088913/si ... i217633534).
Можете пообщаться с автором, может найдете общий язык.

Наличие свободного времени это хорошо, а еще лучше если Вы его будите расходовать с пользой