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

[Andrew771]

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

[Advertiser]

[aviator]

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

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

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

Ещё как оптимизируют. Только методы и цели оптимизации несколько другие. Сейчас в кровавом энтерпрайзе развели столько уровней абстракций, что мощщи реально не хватает.

[Oleg N. Cher]

на MACRO-11 делали макросы для генерации кода под 6502

Хз. Но нашёл вот такое:

Большая часть кода на языке ассемблера, который я вижу на форуме или на веб-страницах, полностью лишена какой-либо видимой структуры, и следить за ним довольно сложно. Однако язык ассемблера не обязательно должен быть таким. Макросы в помощь, в том числе для создания структур управления потоком программ, подобных HLL. Об этом моя статья на http://wilsonminesco.com/StructureMacros/ . (Здесь ветераны видели это раньше.) На последних 40% страницы, посвященной многозадачности, по адресу http://wilsonminesco.com/multitask/ есть несколько более расширенных примеров , показывающих вложенные IF...ELSE.. .END_IF, BEGIN...UNTIL, CASE и т. д. В большинстве случаев макросы будут собирать точно то же самое, что и вручную, то есть не будет никаких потерь в скорости выполнения или расходе памяти; просто теперь вам не нужно каждый раз смотреть на некрасивые внутренние детали, и ваш код становится гораздо более читабельным, поддерживаемым и безошибочным, а программист становится гораздо более продуктивным. Более подробное описание того, как макросы определяют, куда следует переходить и как им не путать различные цели, можно найти в соответствующей главе трактата о стеках 6502 по адресу http://wilsonminesco.com/stacks/pgmstruc.html . Ближе к концу страницы вы можете навести указатель мыши на различные слова в примере кода структуры CASE, и появится окно, сообщающее, что там делает макрос и что в этот момент находится в собственном стеке ассемблера (а не в стеке целевого 6502), который не участвует).

• http://forum.6502.org/viewtopic.php?f=2&t=6450&start=60

А чего было бы не взять подмножество Ada...

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

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

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

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

[Hunta]

Но нашёл вот такое:

Судя по тому что увидел - у MACRO-11 более мощные возможности макросов и макросы для структурного программирования получились более элегантными. То есть если запилить кросс-ассемблер на макросах - можно достичь большего. Но поскольку 6502 и другие процессора (по крайне мере на текущий момент) не в области моих интересов...

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

В целом же - у PDP-11 настолько удобный набор команд, что С (с его возможностями) остаётся за бортом. Да и не нравится мне его некоторые извраты в синтаксисе. C# более удобен в этом плане (хотя и в нём бы некоторые синтаксические конструкции переделал) но его портировать на PDP-11 - пока задача не для меня.

[Oleg N. Cher]

Какой-то один избранный процессор (хоть PDP-11, хоть Z80) также не является моей областью интересов. Мне нравится программировать под всё. Ну и, сам понимаешь, MACRO 11 весьма хорош в своей нише. Но советовать разрабатывать на нём под 6502 или Z80 - такое себе.

И... я не видел реализованных на ассемблере проектов с применением структурных макросов а-ля ЯВУ. Почему-то так не пишут. Даже если такие проекты и есть, их точно совсем немного.

За последние годы мы увидели большие успехи в разработке компиляторов, и нам действительно следует переосмыслить некоторые идеи - особенно старое представление о том, что 6502 не является хорошей целью для компилируемых языков, таких как C. Я помню, как использовал Aztec C. на Apple II - в то время меня не особо волновало, что код был не самым эффективным - он был достаточно хорош, и хотя мне нравится (и до сих пор в некоторой степени тоскуют) идея компилятора, работающего на аппаратном обеспечении, я знайте, что с чем-то вроде современного компилятора C (даже cc65) этого просто не произойдет.

Так что «достаточно хорошо» для меня достаточно хорошо (в случае с cc65 на сегодняшний день). Меня очень впечатлило то, что я смог скомпилировать и запустить свой редактор почти без изменений по сравнению с проектами, частью которых он является (нано-подобный экранный редактор) на моих платах Ruby 6502, который содержит около 1600 строк C и компилируется примерно в 15 КБ кода с cc65. Так кто знает, во что оно скомпилируется с помощью LLVM...

И сравнить... Написал бы я это на ассемблере 6502? Нет. Это не шанс. Конечно, он был бы меньше, быстрее и т. д., но написание, отладка и тестирование заняло бы у меня слишком много времени. То же самое касается моей многозадачной ОС ( http://forum.6502.org/viewtopic.php?f=1&t=6736 ), которая работает под управлением '816, хотя она написана на BCPL - написать ее на ассемблере '816? Нет, спасибо, но на языке высокого уровня, который я могу редактировать и компилировать непосредственно в целевой системе - я доволен!

Языки высокого уровня имеют огромную ценность — особенно если вы можете использовать небольшие фрагменты ассемблера в сверхкритических местах, но в наши дни — ну, достаточно хорошего часто более чем достаточно — вероятно, по той же причине, по которой мы сейчас разгоняем 6502/816 на 16, 20, 30 и больше? Мгц... Является ли тактовая частота заменой эффективности кода? Похоже, что так оно и есть...

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

http://forum.6502.org/viewtopic.php?f=2&t=6450&start=75

[Hunta]

я не видел реализованных на ассемблере проектов с применением структурных макросов а-ля ЯВУ

Некоторое количество исходников программ от самой DEC - были замечены в RSX-11M (где, собственно, на этот пакет я и наткнулся) и, если судить по листингам - то какой-то вариант набора структурных макросов (более ранний?) применялся при написании тестов и среды выполнения комплексных тестов (DEC/X11) в XXDP

И я давно начал их применять - из выложенных в открытй доступ исходников - мой вариант программы SPEED. Сейчас всё написанное, дизассемблированное и изменённые мной чужие исходники (типа исходника монитора XXDP от Ian Hammond) - использует этот пакет.

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

[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% от всего цикла "фрейм команды-фрейм ответа".

[Hunta]

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

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

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

Вообще-то, я немножко про другое. И да -

в массе - уровень программистов падаёт

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

[aviator]

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

Ну просто порог вхождения снизился. Чем занята основная масса - веб-макаки. Я уже устал с ними бороться. Криво, косо, без должной обработки ошибок... Буду возиться со своими железками, а с макаками пусть начальство разбирается. Этим "веб-программистам" я не авторитет, а какой-то непонятный старпёр.

[Hunta]

Конкретные примеры (без имён).

Человек пишет игрушку. Под один из вариантов PDP-11, с его специфическим железом. Какие знания нужны? Знание языка ассмеблера, знания железа (вывод графики, если конкретней, плюс работа в реальном времени - что бы игрушка не тормозила) и до некоторой степени - знание вызовов ОС. Ну может что-то ещё.

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

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

Ну просто порог вхождения снизился.

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

пусть начальство разбирается.