Релиз Vala 0.9.1

> Скажи мне, где именно в gcc живет виртуальная Си-машина?

в GIMPLE и GENERIC представлении. Например, можно работать с этой машиной через MELT, и тогда у нас будет лисп-машина, исполняющая си-машину. Можно работать напрямую, и тогда будет API вызова си-машины. Можно запустить си-машину отработать саму, и тогда у нас на выходе будет асм-исходник и итоговый исполняемый бинарник. Можно её соптимизировать, то есть, одна машина-оптимизатор будет исполнять другую си-машину.

Ты сказал, что компилятор - это виртуальная машина, исполняющая Си-код

не исполняет непосредственно. Генерирует исполнителя для си-машины.

> компилятор - это виртуальная машина, исполняющая Си-код

компилятор — это multi-staged виртуальная машина, исполняющая си-код.
stage1: препроцессор
stage2: построение AST
stage3: оптимизация
stage4: кодогенерация
stage5: линковка
stage6: загрузка и исполнение

>> Ты сказал, что компилятор - это виртуальная машина, исполняющая Си-код

не исполняет непосредственно

Не знаю, ты или другой анонимус, но сказано было ясно: «„виртуальная машина“, исполняющая си код есть — это си компилятор»

Ты сказал, что компилятор - это виртуальная машина, исполняющая Си-код

не исполняет непосредственно. Генерирует исполнителя для си-машины.

Ты знаешь много умных слов, респект.

а компилятор С++ — это виртуальная машина, исполняющая подмножество языка С++ (раскрытие шаблонов), для генерации С++-кода без шаблонов.
С этим не будешь спорить? Без полного раскрытия шаблонов С++ код сгенерировать/исполнить невозможно. Значит, нужен исполнитель.
В С++ это подмножество чуть больше, чем в Си. Но в Си оно тоже есть.

> а компилятор С++ — это виртуальная машина, исполняющая подмножество языка С++ (раскрытие шаблонов), для генерации С++-кода без шаблонов. С этим не будешь спорить?

Я скажу, что компилятор Си++ - это виртуальная машина языка шаблонов.

В С++ это подмножество чуть больше, чем в Си. Но в Си оно тоже есть.

Назови его.

> Назови его.

C runtime library, как он есть. Обработка NaN по IEEE в float числах и операциях (частично libc, частично libgcc). Препроцессор. ld.so, gold/ld.

> В gcc виртуальная машина — это машина, исполняющая GIMPLE/GENERIC код на фазе трансляции, и RTL код распределения по регистрам (зависимый от аппаратной архитектуры) на фазе оптимизации/кодогенерации.

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

Так понятнее?

Много терминов и никакого смысла. После фразы «Генерирует исполнителя для си-машины» ничего говорить уже не надо, потому что понятно, что даже ты считаешь (реализацией) виртуальной Си-машины аппаратный процессор (и вот с этим никто спорить не станет).

C runtime library, как он есть.

Не является частью компилятора. Даже непонятно, является ли она частью языка, потому что:

«A conforming freestanding implementation shall accept any strictly conforming program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>»

Обработка NaN по IEEE в float числах и операциях (частично libc, частично libgcc).

Ну и где здесь исполняемое подмножество языка?

Препроцессор

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

ld.so, gold/ld.

Не являются частью компилятора.

> Не является частью компилятора.

хм. Ну да. Компилятор — это stage1..stage4, остальное — снаружи компилятора.
Тут тезис основной такой: почему многостадийные компиляторы — это всё равно компиляторы, а многостадийно оттранслированный код, такая абстрактная «многостадийная» виртуальная машина, где пред. стадия генерирует код для исполнения след. стадией — это уже не VM?
Где она кончается, эта VM и почему? И что значит «эффективная VM» ?

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

Любая программа является реализацией некоторой виртуальной машины. Если уж не опускаться до машины Тьюринга :-) , весь вопрос только в том, насколько эта VM ярко выражена.
Если VM содержит исполняющую часть, то вот он — исполнительный блок VM, а «виртуальные» инструкции/регистры/стек — исполняемая VM программа.
Если не содержит исполняющей части, в общепринятом смысле это не VM. Но если мы потом добавим внешнего исполнителя, такую расширенную систему можно понимать как VM. И в этом смысле, любая программа — VM какой-то абстрактной машины, с разными исполнителями: для си-машины — статический линкер в компиляторе, динамический линкер + загрузчик в ядре; или, запускаемые через ./configure проверки вида * Checking for kitchen sync ... found toiled-bide-3.62b! — тоже код компилируется и запускается, чем autotools не VM для С компилятора?
линкер, учитывая ldd security bug — это тоже исполнитель для такой «VM».
(или просто бинарно пропатчить объектник, чтобы линкер при коррекции для перемещаемого кода сделал выполнение нужного нам кода)
срыв стека в бажной программе, если получится — тоже исполнитель.

Обработка NaN по IEEE в float числах и операциях (частично libc, частично libgcc).

Ну и где здесь исполняемое подмножество языка?

Это будет уже какая-то специальная олимпиада в духе Obfuscated C contest, но общая идея такая: эксплуатация багов вроде срыва стека внутри libgcc (исполнение нужного кода через gcc) или внутри ld.so через ldd arbitary code execution bug

> даже ты считаешь (реализацией) виртуальной Си-машины аппаратный процессор

более того. Все вложенные друг в друга ВМ, на которых может исполняться Си-код, я считаю частью некоторой многостадийной глобальной си-машины. Например, пусть компилятор у нас под .NET, он генерирует исходник на ассемблере, который собирается ассемблером, и выполняется под симулятором процессора, работающем на машине Тьюринга. У нас получается семейство вложенных ВМ: Си-машина,.NET, ассемблер конкретного процессора, эмулятор, машина Тьюринга, симулятор машины Тьюринга (ну или аппаратный Difference Engine Бэббиджа :))
Все эти мафынки мы используем как Си-машину. То есть, это идея *одной* некоторой абстрактной си-машины, несмотря на то, что много разных фаз, и реализации разные на разных фазах.