Релиз Vala 0.9.1

> А вот зачем нужно Genie, я не понял. Зачем сочинять Питон ещё раз?

мало ли, может батарейки нинужны (tm).
Помимо Vala/Genie, есть ещё deelight (питон на D) http://delight.sourceforge.net/ , Nimrod (что-то среднее между Turbo Pascal + Python на C) http://force7.de/nimrod/

Языки с синтаксисом вроде питона, но транслируемые в си(или Ди) с минимумом зависимостей.

Genie, я так понимаю, выделяется интеграцией с GObject

> Боюсь, что Лисп-машина - это система, оптимизированная под выполнение какого-то внутреннего кода, но не Лисп-программы с листа :)

именно исполнение с листа. Основной лисп транслировался в мини-лисп с RPLCAD и т.п. примитивами, а они были реализованы на микрокоде. Сборщик мусора был реализован на этом мини-лиспе, выделение памяти, прерывания — то есть, полностью, ядро ОС.
Про сборщик мусора есть описание от Henry Baker.

Так что всё равно происходит компиляция Lisp-программы во что-то внутреннее и уже исполнение этого внутреннего в том или ином виде

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

В форт-машинах тоже нет внутреннего представления.

язык — да. А реализации могут быть разные, например, сравни tcc и Ch.

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

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

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

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

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

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

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

это если мы про время компиляции, статику. А в динамике — она живёт в рантайме, в libc, в libgcc и ld.so

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

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

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

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

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

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

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

это если мы про время компиляции, статику.

Вопрос: где в gcc виртуальная машина?

Ответ: статику.

Какая прелесть.

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

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

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

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

Назови его.

В gcc виртуальная машина — это машина, исполняющая GIMPLE/GENERIC код на фазе трансляции, и RTL код распределения по регистрам (зависимый от аппаратной архитектуры) на фазе оптимизации/кодогенерации.
У этой машины есть статическая семантика, есть и динамическая. Эта машина во время исполнения, динамической семантикой, генерирует исполнителя Си-кода, который тоже не является самостоятельным, а является кодом абстрактной си-машины (например, соглашения cdecl или в регистрах о передаче параметров функций — это одно из свойств этой си-машины. malloc и вообще C runtime library — другое свойство этой си-машины. Ограничения модели исполнения, например, aliasing problem — это третье свойство этой си-машины)
Исполнение этой си-машины размазано по многим частям, stages: загрузчик бинарника (ld.so) в ядре, линкер в toolchainе компилятора, C runtime library в динамических библиотеках, libgcc в runtime зависимостях самого gcc.

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

> Назови его.

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.

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

Если они будут пилить Glib в сторону непрямого использования, а для компилятора с удобных языков, то это тоже хорошая идея.

>В форт-машинах тоже нет внутреннего представления.

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

>POC

Да, да именно этого поца я и имел в виду.

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

хм. Ну да. Компилятор — это 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

>>В форт-машинах тоже нет внутреннего представления.

Как это не было? Классический Форт - это или прямой, или шитый косвенный код

В том смысле, что кроме шитого кода никакого особого представления AST не было. А шитый код гомоморфен AST, как и S-выражения — поэтому можно считать, что сразу «программируем в AST» без никакого промежуточного представления для оптимизации (вроде SSA/IR/RTL для C-программ в компиляторе).

Кстати, создание frame pointer в C-функциях можно считать тоже таким свойством «абстрактной си-машины».

В общем, вопрос про разницу между трансляторами, компиляторами/интерпретаторами и виртуальными машинами сводится к тому, есть ли исполнитель непосредственно (ВМ, интерпретатор) или он отложен на 1 действие (компилятор) или более чем на 1 действие (транслятор, например, M4 в ходе работы autotools).

Я бы, правда, назвал отложенный транслятор тоже компилятором — оттранслированное ведь как-то исполнится, попадёт на след. стадию.

Интерпретатор := Транслятор (Исполнитель(Программа))
Компилятор := Исполнитель(Транслятор(Программа))
ВМ := ??? ; Исполнитель(Программа) ??

Ох лол, сколько лет на ЛОР не заходил, а терминосрач про компиляторы всё ещё идёт, с теми же действующими лицами. Бог в помощь, робя.

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

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

>Интерпретатор := Транслятор (Исполнитель(Программа))

Компилятор := Исполнитель(Транслятор(Программа))

ВМ := ??? ; Исполнитель(Программа) ??

отсюда: Транслятор(ВМ)=Интерпретатор, Транслятор(ВМ^-1)=компилятор,

компилятор делается из интерпретатора через metacirricular evaluator

Кстати, в компилятое Factor, емнип, используется SSA представление. Значит ли это, что макс. возможные оптимизации в Factor по определению лучше макс. возможных оптимизаций в классическом форте?