Сообщество

О некоторых деталях используемой в компиляторе технологии можно прочитать тут http://multiclet.com/community/projects/mcc-lime/repository/revisions/lime-0.dev/entry/txt/spec.txt

Небольшой анонс: http://multiclet.com/community/news/1

Почему бы вам не использовать GCC как компилятор? Это действительно портативные, почти все новые производители CPU использовать его для своих процессоров. Когда вы портом GCC и Glibc, вы в принципе нужно только немного больше работы, чтобы переносу ядра Linux.

Потому что, насколько мы понимаем, портировать GCC (и LLVM) лего только лишь на число регистровые машины, которой мультиклеточный процессор не является в полной мере. Проблема в том, что GCC (и LLVM) не понятно, как объяснить концепцию ссылки на результат вычисления. Модель backend-ов, которая предлагается в GCC (и LLVM) такова, что инструкции должны оперировать с регистрами. И алгоритмы генерации кода активно этим пользуются, работая в предположении, что после записи в некий регистр X, следующие обращения к нему вернут именно записанное значение. В мультиклеточных процессорах основным средством передачи данных между инструкциями является коммутатор, на значения в котором нельзя ссылаться из разных инструкциях по одному и тому же имени, чего GCC (и LLVM) не понимает, а регистры меняются не сразу же после исполнения соответсвующей инструкции.

Мы могли бы использовать GCC и LLVM, но пришлось бы очень многое переписывать в базовых алгоритмах этих систем, и нам пришлось бы разбираться в деталях их работы, что потребовало бы гигантских объёмов времени с негарантированным результатам. Поэтому и было принято решение писать свой компилятор. Благо, достаточно хорошо известно, как это делать.

I may rewrite the text in English if you prefer.

Не нужно писать по английский, я понял всё. Спасибо для ответ.

Жал что ГЦЦ не будет портирован на Мультиклет, в скорее время. Но когда Мультиклет будет великая архитектура на рынке, я думаю что кто-нибуд будет рад портировать GCC.

Как продвигается компилятор? Обещан был в марте, а уж пол мая прошло. :-)

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

Ура, ура. А билд компилятора не выложите? Не у всех есть желание самим билдить))))

overclocker

Ура, ура. А билд компилятора не выложите? Не у всех есть желание самим билдить))))

Пока не выложим. Смысл публикации исходников в том, чтобы продемонстрировать скептикам, что работа идёт полным ходом, и предложить желающим поучаствовать (у нас код под свободной лицензией). Но состояние alpha-версии пока не достигнуто.

Зайдя сюда: http://multiclet.com/community/projects/mcc-lime/repository не могу найти адреса для клонирования git-репо.

Наш компилятор пока находится в разработке. Он не является законченным пакетом. Поэтому мы пока не видели необходимости в том, чтобы выкладывать исходники в виде хранилищ. То, что Вы видите на Redmine, в основном, предназначено для нас самих. Но если Вам нужны такие незаконченные исходники, то мы выложим их в виде отдельного git-хранилища.

Я бы глянул. Воять скриптик, для хождения по http, забирающего raw-файлы не хочется:)

Будут ли модификаторы для функций-обработчиков прерываний? Вида:

interrupt void TMR0_handler() {
   …
   // Clear flags
}

jmp #IRETADDR
setl #PSW, 1

Вместо обычных:

rdl #SP
jmp @1

Правильно ли я понимаю, что как таковой таблицы векторов прерываний нет? Есть только один общий адрес hook-функции, принимающей самостоятельное решение о дальнейших действиях.

1. Исходные тексты можно забрать такими командами (${MCC} означает директорию, куда Вы хотите скопировать исходные тексты):
   

   git clone git://0xfb.imm.uran.ru/L/mcc.git ${MCC}
   cd ${MCC}
   git submodule init
   git submodule update

   Пожалуйста, обратите внимание на лицензии и цифровые подписи
2. Пока мы нацелены сделать транслятор для стандартного C99, но технология должна позволить потом быстро добавить различные расширения. Кроме модификатора interrupt нам нужен ещё и inline-ассемблер для удобного переноса операционных систем. Если нужны ещё какие-то специальные возможности, сообщайте, попробуем сделать в расширенной версии языка
3. В текущей версии это так, аппаратно вектор прерываний не поддерживается.

inline-ассемблер можно в стиле GCC по работе с входными/выходными данными.
В репозитории mcc.git нет файлов toolchain.mk и general.mk, которые нужны всем Makefile'ам подпроектов.

ln -s ${PWD}/mkenv/gnu/general.mk
ln -s ${PWD}/mkenv/gnu/tcn/arch-gcc.mk toolchain.mk

mouse

inline-ассемблер можно в стиле GCC по работе с входными/выходными данными.
В репозитории mcc.git нет файлов toolchain.mk и general.mk, которые нужны всем Makefile'ам подпроектов.

Уточню про сборку. Чтобы собрался весь проект, необходимо в директории ${MCC} запустить make, которой надо указать директорию, где осуществлять сборку. Допустим, это директория ${BLD}. Директория должна быть создана до начала сборки:

mkdir ${BLD}
(cd ${MCC} && make BDIR=${BLD})

Для сборки make нужны описания общих правил сборки и команд конкретного инструментария. Они должны быть доступны по именам general.mk и toolchain.mk в директории, где находится makefile. Как их туда добавить, Алексей Ефимов уже написал.

В директории ${MCC}/mkenv/gnu/tcn есть несколько различных вариантов настроек инструментария. То, что начинается с arch - настройки для ArchLinux, в котором используются самые свежие (и бажные) версии GCC и Clang, и в этих настройках могут быть опции, не поддерживаемые компиляторами, которые используете Вы. Самые консервативные и общие настройки находятся в файлах с префиксом cygwin. С ними получается компилировать во множестве POSIX-сред: Cygwin, FreeBSD, разнообразные GNU/Linux

Если Вы захотите собрать какой-нибудь модуль отдельно, то спросите нас, как это сделать. Для некоторых нужны дополнительные параметры

linux 3.5.0 x86_64
make 3.81
gcc 4.7.2
libc 2.15

1. встроенный в интерпретатор echo не всегда имеет ключ "-e", поэтому надёжнее использовать /bin/echo или вообще "printf"
2. в gnu.mk до создания dep-файлов вместо директивкы include лучше использовать -include, чтобы лишние ошибки не сыпались.
3. с _XOPEN_SOURCE=700 код не собирается — падает на неопределённом типе siginfo_t.
4. при сборке с -Werror всякие мелкие предупреждения становятся фатальны, в коде bin/drv/main.c есть неинициализированные переменные и вызов pipe(), где-то определённый с warn_unused_result. В двух местах пришлось extern'ом объявить open_memstream().
5. конфликт типов Binding в lcc/c.h и lime/construct.h. В первом заголовке просто объявлен тип и extern-переменная, которая нигде больше не встречается.
6. в lime/loaddag.c переопределяется функция isascii, которая в ctype.h определена как макрос.

Где можно найти lime-knl?

Спасибо за информацию об ошибках. Что-то мы точно исправляли, но, видимо, потерялось в новых редакциях. По пунктам

1. Про printf-то я и не подумал! Спасибо. Переделаю под этот вариант. Но проблему можно решить и без этого. В toolchain можно определить переменную echo она и будет использоваться для печати сообщений. Можно написать echo = echo, если ключ -e не поддерживается.
2. На моей версии make никакой разницы при смене include на -include не видно. Видимо, что-то делаю не так.
3. Про open_memstream относится к этому же пункту. _XOPEN_SOURCE >= 700 необходимо именно для объявления этой функции. Будем разбираться
4. -Werror указана именно для этого. Не хочется из-за какой-нибудь мелочи, вроде не инициализированной переменной, тратить часы на отладку. С pipe()-ом, вроде, ошибку исправляли. Сейчас пойду побеседую с кое-кем на тему аккуратности в работе.
5. Это исправлено. Вечером будет на сервере.
6. Это мне надо самому себе настучать за неаккуратность. Куда-то потерялся окружающий функцию #ifndef. Функцию понадобилось написать, потому что на некоторых вариантах платформ isascii не определена.

lime-knl пока в разработке. Должен появится в ближайшее время. У нас пока есть очень такая сырая и экспериментальная версия... Надо выложить?

2. На моей версии make никакой разницы при смене include на -include не видно. Видимо, что-то делаю не так.

Я запускаю make BDIR=$PWD/build, если директория пустая, то вылезает ругань такого содержания:

$ make BDIR=$PWD/build2
lime/lib/lime/gnu.mk:41: /home/mouse/Documents/HW/MultiClet/mcc/build2/B/lime/lib/lime/rune.d: No such file or directory
[…]

4. -Werror указана именно для этого. […]

К самому -Werror претензий нет :) Он как раз полезен, просто не собиралось без фиксов.

6. Функцию понадобилось написать, потому что на некоторых вариантах платформ isascii не определена.

Может её тоже стоит определить как макрос?

Без lime-knl не получается перейти от кода, полученного lime-cfe к lime-gen. Там ещё у lime-gen захардкожен путь к in.txt (/cygdrive/c/in.txt), что приводит к падению в корку из-за отсутствия проверки на возвращаемое значение.

make и должен себя так вести, насколько я понимаю. Он не находит файл, а потом по правилам для .d его создаёт. Это нам позволяет не делать отдельно обработку зависимостей, а оставить всё на совести make. Про fixы да, надо поднимать уровень дисциплины.

Может её тоже стоит определить как макрос?

С функцией как-то спокойнее. Компилятор сам следит за типами и преобразованиями. На производительности это сказываться не должно, мы используем -flto для GCC и Clang, поэтому реализация функции подставляется inline.

Без lime-knl не получается перейти от кода, полученного lime-cfe к lime-gen. Там ещё у lime-gen захардкожен путь к in.txt (/cygdrive/c/in.txt), что приводит к падению в корку из-за отсутствия проверки на возвращаемое значение.

Мы их активно пишем как раз, поэтому они вот в таком вот состоянии. Почему мы захардкодили такой путь? Вроде, причина в том, что Eclipse, в котором отлаживается lime-gen как-то плохо работает с stdin.

make и должен себя так вести, насколько я понимаю. Он не находит файл, а потом по правилам для .d его создаёт.

Makefile обрабатывается несколько раз. До создания d-файлов make пытается их подключить, но их ещё нет. Использование "-include" никак не влияет на создание d-файлов, а только убирает ошибки make.

С функцией как-то спокойнее. […]

Я минут пять тупил, пытаясь понять, что не нравится gcc:

lime/lib/lime/loaddag.c:90:17: error: expected identifier or ‘(’ before ‘const’
lime/lib/lime/loaddag.c:90:17: error: expected ‘)’ before ‘&’ token
lime/lib/lime/loaddag.c:90:17: error: expected ‘)’ before ‘==’ token

mouse

%)

Это да :) Мы обновили версию на сервере git. Сейчас компилируется чище, хотя там ещё остаётся с tempnam разобраться. Про make я осознал (менял не в том месте include-ы, поэтому и эффекта не было), благодарю за этот совет. Навтыкаю минусов к началу следующей недели.

Здравствуйте.

Извините, что возможно повторяюсь. Вверху я видел вопрос и соответствующий ответ про GCC и в скобках был указан LLVM, я так понял, что проблема в этих компиляторах в том, что они работают с регистрами, но понял не до конца.
Поэтому я хотел бы задать вопрос про LLVM, вы же наверно знаете, что там всё разбито на стадии:
1) Компиляция из языка в промежуточный байткод.
2) Оптимизация промежуточного байткода
3) Компиляция из промежуточного байткода в машинный код архитектуры, если не ошибаюсь - это называется там генераторами машинного кода.

Сам баткод там -- это вымешленная RISC машина с бесконечным количеством регистров, т.е. можно на неё взглянуть, как на язык ассемблер с простыми переменными вместо регистров.
Преимущества LLVM понятны, например для всех языков общий архитектурно-независимый оптимизатор и архитектурно-зависимый оптимизатор, который присутствует в генераторах машинного кода.

А вот теперь в чём заключается мой вопрос:
Могли бы вы написать для LLVM генератор машинного кода под Мультиклет по их правилам(по правилам создания генераторов машинного кода) или, если есть проблемы, то свой отдельный компилятор ихнего промежуточного байткода(или ассемблера LLVM) в машинный код Мультиклета ? (конечно, если это вам выгодно...)

Я задаю такой вопрос, потому что:
1) Если такое сделать, то под Мультиклет станет доступно сразу огромное количество разных языков программирования, которые доступны под LLVM и не надо для их всех писать свои компиляторы.(это может увеличить приток разработчиков и облегчить им жизнь)
2) Будут доступны одни из важных языков -- это С/С++, причём самого последнего стандарта и разработчикам Мультиклета не надо будет следить и поддерживать стандарты этих языка в актуальном состоянии(тоже самое касается и всех остальных LLVM языков), за этим будут следить разработчики clang.
3) Не надо будет писать архитектурно-независимый оптимизатор, данной оптимизацией будет заниматься LLVM, а развивать его будут его разработчики. Но если понадобится, то вполне можно дописать необходимые фазы оптимизации.
4) Я думаю, что легче разработать компилятор, который будет компилировать байткод LLVM в машинный код, чем разрабатывать компилятор таких языков, как С/С++, т.к. Ассемблер LLVM намного проще и не поддерживает столько парадигм программирования. И он разработан именно для того, чтобы его в последующем компилировать в машинный код разных архитектур.
5) Стандарт байткода LLVM скорее всего уже не будет сильно меняться и поддержка и расходы на поддержку сведутся к минимуму. Все же другие языки постоянно развиваются и их компиляторы надо постоянно усовершенствовать.
6) Мультиклет выглядит перспективно и одно из возможных применений может быть в мобильных устройствах, таких как смартфоны и планшеты. При такой производительности и соответствующем уровне энергопотребления(как пишут в новостях про данные параметры) он мог бы составить огромную конкуренцию, а самая популярная ОС в данной технике - это Андроид. Так вот Андроид 5 имеет АОТ-компиляцию, т.е. компиляцию своего байткода в машинный код перед выполнением, т.е. при первом запуске приложения. Но насколько я знаю данная компиляция реализована в Андроиде, через LLVM. Поэтому если на базе мультиклета делать соответствующую технику с ОС Андроид, то LLVM там понадобится(но тут надо уточнять, я могу ошибаться).

Я думаю, что LLVM очень перспективна. Так же я в одном подкасте слышал от разработчика компиляторов под Эльбрус, что они обратили своё внимание на LLVM.

Поэтому мне интересно ваше мнение по этому поводу.

Здравствуйте, Yasis.

Извините, что возможно повторяюсь. Вверху я видел вопрос и соответствующий ответ про GCC и в скобках был указан LLVM, я так понял, что проблема в этих компиляторах в том, что они работают с регистрами, но понял не до конца.
Поэтому я хотел бы задать вопрос про LLVM, вы же наверно знаете, что там всё разбито на стадии:
1) Компиляция из языка в промежуточный байткод.
2) Оптимизация промежуточного байткода
3) Компиляция из промежуточного байткода в машинный код архитектуры, если не ошибаюсь - это называется там генераторами машинного кода.

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

Сам баткод там -- это вымешленная RISC машина с бесконечным количеством регистров, т.е. можно на неё взглянуть, как на язык ассемблер с простыми переменными вместо регистров.
Преимущества LLVM понятны, например для всех языков общий архитектурно-независимый оптимизатор и архитектурно-зависимый оптимизатор, который присутствует в генераторах машинного кода.

1. Полученный код получается весьма не-оптимальным (нам, фактически, приходится эмулировать SA-регистры LLVM через полноценные переменные, потому что SA-регистры переживают ветвления).
2. Совершенно не ясно, как эффективно транслировать так называемые phi-узлы (для обычной регистровой машины - это просто линейный блок с несколькими точками входа в него, но для Мультиклета такая конструкция противоестественна).

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

Конечно же, если бы кто-нибудь взялся бы за эту задачу, было бы шикарно. Больше компиляторов хороших и разных!

А вот теперь в чём заключается мой вопрос:
Могли бы вы написать для LLVM генератор машинного кода под Мультиклет по их правилам(по правилам создания генераторов машинного кода) или, если есть проблемы, то свой отдельный компилятор ихнего промежуточного байткода(или ассемблера LLVM) в машинный код Мультиклета ? (конечно, если это вам выгодно...)

Здесь тоже кроются подводные камни. LLVM заточен под классические регистровые архитектуры процессоров (имеется в виду такие архитектуры, в которых обмен данными между инструкциями идёт через регистровый файл). Соответственно, под них же заточены и алгоритмы оптимизации, и штатные интерфейсы для описания генераторов кода. И совершенно не понятно, как через эти штатные интерфейсы объяснить LLVM, что ссылка на коммутатор вида @1 меняется от инструкции к инструкции. А лезть внутрь LLVM, в его core-библиотеки, в одиночку, без особой заинтересованности самой команды LLVM, сами понимаете, не реально.

Повторю свой любимый лозунг: Конечно же, если бы кто-нибудь взялся бы за эту задачу, было бы шикарно. Больше компиляторов хороших и разных!

Я задаю такой вопрос, потому что:
1) Если такое сделать, то под Мультиклет станет доступно сразу огромное количество разных языков программирования, которые доступны под LLVM и не надо для их всех писать свои компиляторы.(это может увеличить приток разработчиков и облегчить им жизнь)
2) Будут доступны одни из важных языков -- это С/С++, причём самого последнего стандарта и разработчикам Мультиклета не надо будет следить и поддерживать стандарты этих языка в актуальном состоянии(тоже самое касается и всех остальных LLVM языков), за этим будут следить разработчики clang.
3) Не надо будет писать архитектурно-независимый оптимизатор, данной оптимизацией будет заниматься LLVM, а развивать его будут его разработчики. Но если понадобится, то вполне можно дописать необходимые фазы оптимизации.
4) Я думаю, что легче разработать компилятор, который будет компилировать байткод LLVM в машинный код, чем разрабатывать компилятор таких языков, как С/С++, т.к. Ассемблер LLVM намного проще и не поддерживает столько парадигм программирования. И он разработан именно для того, чтобы его в последующем компилировать в машинный код разных архитектур.

Да, Вы в большинстве пунктов правы. Но вот с оптимизацией возникают вопросы. В LLVM нет некоторых методов оптимизации, которые нам нужны для генерации оптимального кода для Мультиклета. И LLVM не поддерживает некоторые особенности Мультиклета, которые позволяют нашим процессорам более эффективно исполнять программы на динамических и функциональных ЯП. Когда Мультиклет займёт бОльшую долю рынка, то ребята из LLVM, конечно же, обратят на нас внимание и внесут соответствующие правки в свои системы (если это возможно, конечно). Но пока на это просто нет ресурсов, к сожалению. Хотя... Ну, Вы поняли :) Больше компиляторов хороших и разных.

5) Стандарт байткода LLVM скорее всего уже не будет сильно меняться и поддержка и расходы на поддержку сведутся к минимуму. Все же другие языки постоянно развиваются и их компиляторы надо постоянно усовершенствовать.

Мы тоже делаем систему так, чтобы в ней было промежуточное представление, явно доступное снаружи системы, с которым могут работать разработчики других языков программирования, не только Си/Си++. То есть, сторонние разработчики вполне могут взять наши библиотеки и поверх них построить свои языки, которые будут выдавать байт-код для нашей системы трансляции, которая будет дальше отвечать за его оптимизацию и трансляцию в ассемблер Мультиклета.

Мы, кстати, рассчитываем, что наша система несколько проще LLVM будет в использовании. Да и в поддержке тоже. Кода меньше, он проще, внутренне представление программ более традиционное и т.д. и т.п.

6) Мультиклет выглядит перспективно и одно из возможных применений может быть в мобильных устройствах, таких как смартфоны и планшеты. При такой производительности и соответствующем уровне энергопотребления(как пишут в новостях про данные параметры) он мог бы составить огромную конкуренцию, а самая популярная ОС в данной технике - это Андроид. Так вот Андроид 5 имеет АОТ-компиляцию, т.е. компиляцию своего байткода в машинный код перед выполнением, т.е. при первом запуске приложения. Но насколько я знаю данная компиляция реализована в Андроиде, через LLVM. Поэтому если на базе мультиклета делать соответствующую технику с ОС Андроид, то LLVM там понадобится(но тут надо уточнять, я могу ошибаться).

Что же до Android... Та система компиляции, над которой мы трудимся, в принципе, позволит реализовать AOT поверх неё. Потренировавшись на кошечках (на Си-99) мы сможем придумать frontend нашей системы и для байткода LLVM, и для байткода JVM. На вскидку, нам выгоднее работать именно с JVM, потому что j-код для стековой машины гораздо проще превратить в удобное для Мультиклета дерево выражений.

Я думаю, что LLVM очень перспективна. Так же я в одном подкасте слышал от разработчика компиляторов под Эльбрус, что они обратили своё внимание на LLVM.

Эльбрусовцам должно быть проще работать с LLVM, так как у них обмен между инструкциями происходит в соответствии с базовой парадигмой LLVM -- через регистровые файлы. Поэтому, для них естественно работать с этой системой. И она действительно перспективнее GCC (по моему опыту тоже). Да и хотя бы тем уже перспективней, что зоопарк языков и backend-ов для неё гораздо больше, чем в коллекции компиляторов GNU.

Но кто знает? Может, в одном из следующих подкастов они скажут, что им удобнее работать с нашей системой трансляции? :)

Поэтому мне интересно ваше мнение по этому поводу.

Вот такое вот мнение. Хотелось бы услышать и Ваше мнение по поводу нашего мнения. Всего знать в нашем обширном мире невозможно и конструктивная критика весьма полезна.

Я вас понимаю, сейчас отвечу ещё на некоторые фразы:

"Да, Вы в большинстве пунктов правы. Но вот с оптимизацией возникают вопросы. В LLVM нет некоторых методов оптимизации, которые нам нужны для генерации оптимального кода для Мультиклета."

Я думаю, что оптимизатор, который обрабатывает байткод, он архитектурно-независим, а вы тут сказали об архитектурно-зависимом для Мультиклета, а такая стадия оптимизации должна быть прописана в генераторе кода(предполагаю).

"И совершенно не понятно, как через эти штатные интерфейсы объяснить LLVM, что ссылка на коммутатор вида @1 меняется от инструкции к инструкции."

Я предполагал, что возникнет такая трудность, именно поэтому я и упомянул способ написания не стандартного генератора кода, а просто самостоятельно анализировать байткод LLVM, но вижу, что и так трудности возникают.

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

"Мы тоже делаем систему так, чтобы в ней было промежуточное представление, явно доступное снаружи системы, с которым могут работать разработчики других языков программирования, не только Си/Си++. То есть, сторонние разработчики вполне могут взять наши библиотеки и поверх них построить свои языки, которые будут выдавать байт-код для нашей системы трансляции, которая будет дальше отвечать за его оптимизацию и трансляцию в ассемблер Мультиклета."

Вы делаете правильно.

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

И вот у меня сейчас возникла другая идея, если сложно сделать компиляцию байткода LLVM в архитектуру Мультиклета, то может будет проще залезть в исходиники clang и переделать компиляцию с байткода LLVM на компиляцию в ваш байткод ? Тогда хотя бы С/С++ будет полностью поддерживаться и это облегчит вам работу по написанию компилятора самого языка. Я конечно туда не заглядывал и не знаю удачна ли моя идея...

И по этому поводу возникла ещё идея: В LLVM есть специальный API для создания языков, языки вызывают этот API, а он генерирует байткод LLVM, можно попробовать подменить его своим API, который будет генерировать ваш байткод. Надо только узнать не будет ли с этим таких же проблем, как и те, что были описаны вами выше. И если такой способ подойдёт, то коль самый приоритетный язык программирования - это Си, то надо посмотреть пользуется ли clang этим API, ведь второй способ - это генерировать байткод самостоятельно, без использования API LLVM, но я думаю, что большинство(или все) используют этот API, а не генерируют байткод самостоятельно.

Если бы такой способ удался, то потом реализация языков тоже сильно облегчится, т.к. надо будет просто взять их исходники и подключения API LLVM заменить на подключение своего API, после чего скомпилировать, а дальше компилятор языка начнёт генерировать ваш байткод, потом к нему будете применять свой оптимизатор и генератор кода.