Язык Cowgol и компилятор для 6502, 8080, Z80, 8086, 80386, PDP-11, ARM(thumb2) и в Си

[aviator]

Ну так автор Cowgol'а уверяет, что Cowgol основан именно на Ada. Остаётся только радоваться?

Он "Ada-inspired", то есть вдохновлённый Адой, но со своим велосипедным синтаксисом.

Надо брать нечто, где будет явная восьмибитная арифметика. Можно искусственно в Си, Паскале и Обероне сделать int/integer 8-битным. Можно сделать основание арифметики 8-битной, оставив в покое int/integer. Но это будет уже ИМХО не то. Нужен язык, который сразу определит традицию такой арифметики. Нужен PL/M, но с более элегантным синтаксисом. Нужен Cowgol, но с более качественной генерацией кода. Нужен ассемблер с хорошим уровнем макросов. Всё это нужно обязательно мультитаргетное и переносимое. Бог его знает, чего ещё нужно.

Integer делали 16-битным для удобства вычислений. Делать размером в байт просто неудобно. А 2 байта - это хороший баланс между удобством и производительностью. Да, сложение/вычитание транслируется в 2 команды, но пересылка и загрузка транслируется в операцию с регистровой парой. Вот Модула или Оберон имеют очень компактный синтаксис, следовательно компилятор тоже вписывается в ограниченные ресурсы 8-битной машины. Я считаю, что это лучший выбор для языка высокого уровня. И методы оптимизации сводятся к оптимизации по количеству инструкций и пересылок с памятью. У нас нет ни выравнивания в памяти, ни кеша, ни конвейера, ни предсказаний переходов.

C то есть везде, его не обсуждаю, не пинал только ленивый. На BDS C и Си-80 делал самодельный интерпретатор G-Code и управление ЧПУ (давным-давно спасли из металлолома ЧПУ, но станция управления была уничтожена золотоискателями). И проблем с быстродействием не было вообще.

aviator, Вы видите, что в русскоязычном ретро-сообществе никакого ажиотажа вокруг LLVM для Z80 и 6502, в общем-то не наблюдается. Людям это не нужно. Ну пусть пишут на асме, чо.

LLVM большой и жирный. Это разве что для кросс-компиляции пригодно. А цель, как я понимаю, разработка и компилирование на нативной платформе? Или нет?

- - - Добавлено - - -

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

Не сказал бы, что уровень падает. Просто требования предъявляются другие. Например, при реализации чего-либо из вычислительной математики мне сейчас важнее не минимальное количество операций, а чтобы было как можно меньше промахов кеша и адаптация алгоритма к SIMD инструкциям. А ассемблер использовать нет смысла.
Да и в других случаях. Раньше, при реализации DALI, использовали бы ассемблер, а сейчас - минимум кода и вся работа на плечах встроенной периферии - PRS, DMA, ACMP, SPI и аппаратный таймер. Естественно, что бороться за оптимизацию оставшегося кода на Си, который настраивает эту периферию - нет смысла. Этот код по времени выполняется менее 1% от всего цикла "фрейм команды-фрейм ответа".