Создание нового языка для микроконтроллеров

Так и появился си, вроде, не? :)

я не желаю создавать очередной си-подобный язык высокого уровня !

R0=5

Но согласитесь - очень похоже. :) Хотя бы на препроцессор Си.

Асм для dsp-процессоров Analog Devices выглядит примерно так. Хотя облегчает ли это программирование по сравнению с другими процессорами - черт его знает... Когда пришлось под это дело писать, его всё равно надо было плотно осваивать... Может Вы скорее о стандартизации мнемоник различных ассемблеров ???

Для меня вобщем-то примерно подобная задача сейчас тоже актуальна. Есть очень неплохой (на мой взгляд как автора разумеется) самопальный процессор, встраиваемый в FPGA (сейчас потихоньку готовлю серию публикаций о нём). Проблема - на чём его программировать. Усугубляется это в добавок тем, что он управляется микрокодом. Для того чтобы изменить под свою задачу систему команд (в разумных пределах конечно), не надо лезть в дебри верилога. Достаточно описать её на некоем простом языке(микроассемблере), получить микрокод и пересобрать проект(можно даже вообще без пересборки загрузить через аппаратный отладчик). Работы на час-полтора. А вот как менять средства разработки - черт его знает... Пока это у меня решается подробнейшим описанием на русском языке внутренностей ассемблера и симулятора. Чтобы пользователь без труда смог это переписать под свою систему команд. Но это уже ДНИ... Хотелось бы каких-то более фундаментальных решений.

P.S. На всякий случай утащил в закладки. Надеюсь в отличии от сотен и тысяч других, идея не мертворожденная.

P.P.S. Кстати можно подробнее о Вашем редакторе ??? Я сейчас тоже в качестве небольшого хобби и переключения задач пишу нечто, вдохновлённое вот этим https://github.com/rxi/lite , хотя и сильно по-своему.

История зациклилась как ей и предписано.

"С машиной поставлялся автокод АРМУ (Автокод Ряда Машин Урал), который был единым автокодом ряда ЭВМ типа “Урал”. Он был составлен с учетом особенностей этих машин и обеспечивал полную совместимость от меньшей машины к большей. Каждая ЭВМ “Урал” имела собственный транслятор с языка АРМУ на свой машинный язык. Таким образом, совместимость ЭВМ типа “Урал” была ограниченной и существовала только на уровне автокода АРМУ. "

https://computer-museum.ru/histussr/ural11.htm

p.s. первая программа, которой кто то кроме меня пользовался была написана 40 лет назад как раз для Урал-11

Советую обратить внимание на fasmg: https://flatassembler.net/docs.php?article=fasmg

Почитайте про PL/M и C-- – вроде оба достаточно близки к задаче, которую вы себе поставили, возможно, почерпнёте идеи.

Ну и, естественно, готовьтесь к тому, что проект вы создаёте в основном для себя и большая популярность ему не светит...

Как вам уже написали, делая кроссплатформенный ассемблер, вы приходите к языку высокого уровня.

Выглядит это примерно так: на одном процессоре есть какие-то инструкции, а на другом нет. Значит берём некое очень ограниченное подмножество инструкций, которые есть на всех рассматриваемых процессорах, а потом для каждого конкретного сворачиваем последовательность микрокодов в одну инструкцию с помощью хинтов (фактически - шаблонов), а там, где не свернулось, работает эта самая микропрограмма. пусть и не так эффективно (и даже может быть свёрнута в несколько операндов). Микрокоды, это некая стековая машина, PI код, или LLVM IR, поэтому, фактически, мы можем придти к тому. что сами микрокоды вообще не являются усечённым подмножеством любой из архитектур, а являются полностью виртуальными. На втором шаге, выделив типовые последовательности, микрокодов, для конкретных программ, даём им имена и получаем операторы ЯВУ и конкретный кроссплатформенный язык.

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

Я думаю в первую очередь мир нуждается в свободном симуляторе цифро-аналоговых цепей, таком как Proteus или может Simics. Потому что очень хочется сначала прототипировать, а потом паять.

Я задумывался над этим вопросом...
Суть проблемы в том что трудно в целом мысленно организовать подобную идею.

Во первых - Многие архитектуры довольно сильно отличаются, потому сделать такую банальную вещь как "относительный переход" довольно запарно. Везде это будет работать по разному. То есть call type_add[ptr] может тупо не собраться и требовать специфических ассемблерных вставок. То есть, уже базовые механизмы работы с потоками управления\данными могут сильно отличаться и требовать неявно вставлять код. (грубо говоря, как AVR не поддерживает float и плодит кучу кода чтоб сделать 1.0+1.0)

Во вторых - этот язык должен быть одновременно "не типизрованным" и уметь в "типизацию". Для большинства архитектур в целом не важно что есть байты в памяти, это может быть как адрес-указатель так и float. При этом нужно учитывать что A + B невалидная операция, ибо что вообще есть +? Это SIMD расширение, 4float или 2double?? Это что-то от FPU? Это число, знаковое число?

В третьих - Есть типовые задачи которые максимально по разному работают на разных процессорах. Такая базовая вещь как "установить бит в памяти" может работать у всех абсолютно по разному, а это значит надо продумывать "std" библиотеки. Без них ты не сможешь гарантировать "нормальную" кроссплатформенность.

В четвёртых - Это всё будет нормально работать вплоть до того как не появится второе ядро. Тогда придётся вводить кучу абстракций чтоб победить все эти "страшные многоядерные проблемы".

Ну и в пятых - Это не имеет смысла для процессоров с микрокодом. Потому-что архитектура таких процессоров может неявно обрабатывать какие-то последовательности команд тупо лучше. Как в х86 есть суперкороткая команда, в 2 байта, для for циклов, но она раз в 10 медленнее чем последовательность test+jne+inc+jmp, которая чуть ли не под 16 байт памяти съедает. (точно не помню, но суть в этом)

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

ЗЫ - помимо всего этого, должна быть явная поддержка чистого ассемблера со стороны компилятора + препроцессор (чем мудрёнее тем лучше). Чтоб можно было ручками более чётко прописать что ты хочешь от кода. (И моё ИМХО - не дёргать регистры руками. Этим умеет заниматься компилятор и более эффективно. Если надо то как-то отдельно помечать переменную явно как "регистровую")

Мое мнение, Вы пытаетесь изобрести ООП, и хотите сделать статический полиформиз для поддержки разных архитектур, дак уже всё придумано С++ и шаблоны. вот, например, конфигурация Pin хоть в что, на любой платформе.

Pin<Config>::Set();

хотите сделать конфигурацию пина в во вход на любой платформе:

using PinToInput = Pin<ConfigToInput>:
PinToInput::Set();

останется только определить Configи для разных платформ и реализации Set(), ну или Set() тоже может быть одинаковыми, но тогда реализация должна быть в Configах

Как то баловался таким.

https://habr.com/ru/post/473612/

https://disk.yandex.ru/i/ajCQtg1GEPPdRQ

Мне кажется надо несколько по иному решать эту проблему. Имея большой опыт разработки программ на Ассемблере (программировал на ассемблер IBM, DEC, Intel) могу сказать, что основная сложность при программировании на Ассемблере не в написании команд МОV, ADD и т.п., а в написании инструкций по управлению самой программы. Если программист занимается программированием МК, то вряд ли он программирует несколько разных МК одновременно. То есть он эти команды для конкретного МК запоминает в течении 2-3 недель. А вот отсутствие возможности иметь операторы if, while, do (простом цикл), until является основной трудностью. Мною в дипломной работе были реализованы эти инструками для ассемблера ЕС ЭВМ. Для чего использовал ся макрогенератор ассемблера. Программа получалась со сложной логикой управления гораздо меньше по размерам, намного читабельной и более надежной. Минусом было увеличение времени трансляции.

...потом появится желание обеспечить повторное использование программ для различных ядер, чтобы по два раза не переписывать

...для этого понадобится привести архитектуры к одному общему виду

...называется это Форт

Я осилил (надеюсь) только манипуляции с виртуальными регистрами. У меня 2 вопроса:
1) зачем введено такое понятие, почему нельзя иметь сквозную нумерацию регистров, а компилятор сам распределит где виртуальные, а где нет?
2) вы уверены, что итоговый код, когда значения виртуальных регистров будут летать туда-сюда в память (у нас ситуация что физических регистров меньше виртуальных, значит мы должны их хранить в кеше) будет оптимальней скомпилированного сишного кода, где компилятор оптимизирован под реальное количество регистров. Я когда-то смотрел скомпилированный код под MSP процессор и реально офигел, что он был довольно нетривиальным, т.е. не такой линейный как я ожидал

А решение будет сделано на chat gpt. Причем код никто не поймет, но он будет работать для нужного процессора )))

Плюс за старание и стремление к самосовершенству.

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

Основной фичей должна быть удобная работа с флагом переноса. Например, чтобы можно было сдвигать переменные по цепочке. Или складывать, используя дальше получившийся бит переноса для проверки условия.

Правда синтаксис ещё не доточил, потому что компилятор не готов пока что.

я не желаю создавать очередной си‑подобный язык высокого уровня!

А зря. Я в начале 90-х тоже предпочитал ассемблер языкам высокого уровня, поскольку между ними был существенный разрыв - стоило перейти хотя бы на C, чтобы потерять контроль над рядом аспектов размещения и выполнения кода/данных, которые могли быть важны для задачи. То, что большинство тогда писало на C, C++ и Pascal, я писал на ассемблере, и был вполне доволен. :)

А потом оказалось, что есть реализации и C, и даже Pascal, очень сильно приближенные к машинному уровню, где можно произвольно манипулировать размещением кода/данных в памяти, непосредственно использовать регистры в виде псевдопеременных, где ряд встроенных функций напрямую раскрывается в соответствующие команды процессора и т.п. Мне не приходилось писать для контроллеров ARM, но после перехода на VC++ в 90-х я совершенно потерял интерес к ассемблеру, поскольку практически все, что я привык контролировать на уровне команд и ячеек, можно было делать и в программе на C/C++, произвольно меняя уровень абстракции в любом месте. И это при том, что VC++ сильно уступал в этом тому же BC++.

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

Безумству смелых, поём мы песню. А я всё больше влезаю в HAL, хотя всё моё естество этому противится. Но так проще заработать, чем писать проги в машинных кодах, как в счастливые студенческие времена!

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

Так что спускаюсь на уровень команд процессора лишь в очень экзотических случаях.

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

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

Если хочется добавить поддержку периферии МК, то можно использовать LLVM API, чтобы написать свой front-end для LLVM.

Вот пример кода (HelloWorld, сложение a + b в с, а также дергание пином/реле):

; ModuleID = 'main'
source_filename = "main"
target triple = "thumbv7m-none-none-eabi"

@__str0__ = constant [14 x i8] c"Hello, World!\00"

declare void @RELAY_TOGGLE(i32 %0)
declare void @Println(i8* %0)

define i32 @main() {
entry:
  %a = alloca i32
  store i32 10, i32* %a

  %b = alloca i32
  store i32 5, i32* %b

  %a1 = load i32, i32* %a
  %b2 = load i32, i32* %b
  %add = add i32 %a1, %b2

  %c = alloca i32
  store i32 %add, i32* %c

  %c3 = load i32, i32* %c
  tail call void @RELAY_TOGGLE(i32 %c3)

  tail call void @Println(i8* getelementptr inbounds ([14 x i8], [14 x i8]* @__str6__, i32 0, i32 0))
  
  br label %end
end:                                              ; preds = %entry
  ret i32 0
}