Данил писал(а):
Прошу прощения, может имеют место какие-то недопонимания, но при чём тут язык на котором реализован компилятор? Очень уж сомневаюсь, что компиляция там происходит непосредственно из LV кода в Windows PE. У меня такое мнение сложилось, что компиляция там происходит в промежуточный код, который "заключают в ресурс" транслятору и гордо называют это программой. Думаю, такую задачу (сборку кода в exe) можно реализовать хоть на WSH+JavaScript если нужно будет.
Как бы так объяснить... Ну вот представьте себе - вам надо закрутить кучу шурупов, отвёртки под крест нет - только прямой шлиц. Вы, конечно, можете крутить их и так, но будет сильно неудобно. В конце концов вы просто начнёте забивать их молотком. Язык сам по себе, конечно, неважен - это всего лишь инструмент. Можно реализовать вашу задумку на ассемблере? Да не вопрос. Но времени на это уйдёт очень много (хотя работать будет быстро). Можете написать всё на уже упомянутом CVI, но там чистый Си - лишившись объектной ориентированности вам придётся наворачивать конструкции, которые на C++ реализовывались бы на порядок проще. И так далее. Для каждой задачи один инструмент подходит лучше, другой хуже, только и всего. Дело не только в используемом компиляторе, но и в существующих библиотеках, инфраструктуре, удобстве отладки, скорости кодогенерации и качества генерируемого кода, и т.д. и т.п.
Что касается процесса (алгоритма) компиляции, то вы невнимательно читали то, что я вам писал в другой ветке, а я ведь давал ссылки.
Ещё раз:
Внутри LabVIEW - как работает компилятор
http://www.ni.com/white-paper/5314/en/
Под капотом компилятора LabVIEW:
http://www.ni.com/white-paper/11472/en/
Была ещё третья ссылка, но NI её убрал, так что прилагаю pdf из архива - там показано, во что компилируется код LV.
При компиляции "промежуточный код", как вы его называете, используется (читайте внимательно по ссылке выше). Однако в скомпилированном приложении и сохранённых VI промежуточного кода нет. Бояться промежуточного представления не нужно - это может сильно облегчить жизнь с точки зрения архитектуры. Посмотрите - его используют куча компаний
http://llvm.org/Users.html. Технически компиляция производится "на лету", при редактировании, ну или когда вы щёлкаете по Run с зажатым контролом. В памяти на этапе разработки всегда присутствует полностью скомпилированная программа (не в промежуточном представлении, а именно скомпилированная). При сохранении VI скомпилированный код сохраняется в VI вместе с блок-диаграммой (в последних версиях LabVIEW его можно хранить отдельно - в основном это сделано из-за того, что системы контроля версий с ума сходят от таких исходников). При загрузке VI в память сразу грузится скомпилированный код, если это возможно (не всегда по некоторым причинам - в этом случае при открытии вы видите окно Compiling Vi...). При генерации приложения в исполняемый файл в начало пишется небольшой загрузчик и следом за ним llb, содержащая все SubVI без блок-диаграм, но со скомпилированным кодом. В последних версиях - используется упаковка SubVI в zip - это сделано, чтобы не было конфликта имён (если в двух классах или библиотеках присутствуют инструменты с одинаковыми именами). При старте приложения загрузчик всё это грузит в память, затем ищет, начиная со своей папки lvrt.dll, передаёт ей управление (в ней WinMain грубо говоря сидит), оттуда запускаются потоки, которые начинают выполнять загруженный код. Чтобы "генерить программы без компилятора" достаточно отрезать от одного из сгенерённых приложений загрузчик - это примерно килобайт пятьдесят и, грубо говоря, "приклеить" к нему другие VI - только и всего (там не так всё тривиально, но принцип такой).