Просмотр полной версии : Язык Cowgol и компилятор для 6502, 8080, Z80, 8086, 80386, PDP-11, ARM(thumb2) и в Си
Oleg N. Cher
08.12.2023, 17:38
Позвольте поделиться находкой. Я, в принципе, давно знал о нём, но не так давно узнал, что появилась поддержка проца PDP-11. Таким образом, теперь он поддерживает все интересующие меня архитектуры.
https://cowlark.com/cowgol
Собирается под Linux при помощи make (надо доустановить один пакет ручками). У меня под WSL собрался с ошибками. Под винду нативно его никто не собирал, насколько я понимаю. Также сам компилятор и утилиты могут работать на ретро-платформах под CP/M. Процесс компиляции разбит на обработку фронт-эндом (cowfe), потом бэк-эндом (cowbe) с генерацией промежуточный файлов. Обычный подход для старых компиляторов, работающих на машинах с маленьким объёмом памяти.
Пара слов о языке Cowgol. Специально адаптированный под ретро-платформы язык. Нет фрейма стека (и рекурсии). Есть 8-, 16- и 32-битная арифметика со знаком и без. Все приведения типов только явные. Синтаксис немного непривычный, но уж точно получше, чем в PL/M.
Сам язык выглядит намного более платформенно-независимым, чем PL/M.
Компилятор Cowgol написан на нём самом. Как производилась раскрутка - неизвестно.
Кодогенераторы относительно простые. Качество кода - терпимое. До идеала - надо дорабатывать ;)
PDP-11
https://github.com/davidgiven/cowgol/blob/master/src/cowbe/archpdp11.cow.ng
8080
https://github.com/davidgiven/cowgol/blob/master/src/cowbe/arch8080.cow.ng
8086
https://github.com/davidgiven/cowgol/blob/master/src/cowbe/arch8086.cow.ng
Z80
https://github.com/davidgiven/cowgol/blob/master/src/cowbe/archz80.cow.ng
6502
https://github.com/davidgiven/cowgol/blob/master/src/cowbe/arch6502.cow.ng
Автор сего языка жив и сейчас занимается портированием CP/M под 6502.
Я намерен поковырять Cowgol. Если хотите присоединиться, давайте создадим группу в telegram.
- - - Добавлено - - -
Да, забыл добавить: бэк-энд генерирует текст на асме, а не машкод. Так что чистым пуристам не понравится.
Олежка, бро, так держать!
Ярило наше всё ( :) ) и может быть все твои концепты неясные-непонятные станут тем что нужно для дальнейшего!
Всё это напоминает Ли Цысинь "Задача трех тел" - прочти, друже, не пожалеешь!
(по случаю приношу извинения что не общались долго - уж очень меня жизнь подкосила, выкарабкиваюсь)
Oleg N. Cher
11.01.2024, 17:43
Пара видосов по Cowgol:
https://www.youtube.com/watch?v=cAoP91QDLy4 (для цели ZX Spectrum)https://www.youtube.com/watch?v=epTQPSi3IyQ (нативно на BBC Master)
Oleg N. Cher
11.01.2024, 20:27
https://www.youtube.com/watch?v=-jJJ3eRjhas
Восьмичасовый стрим написания бэк-энда Cowgol для 8080:
https://www.youtube.com/watch?v=iUarU8Fhvug
- - - Добавлено - - -
https://www.youtube.com/watch?v=epTQPSi3IyQ
https://www.youtube.com/watch?v=cAoP91QDLy4
(для цели ZX Spectrum)
здесь можно включить субтитры на английском
- - - Добавлено - - -
Восьмичасовый стрим написания бэк-энда Cowgol для 8080:
https://www.youtube.com/watch?v=iUarU8Fhvug
а здесь, к сожалению, нет.
А вообще теперь авторы видосов могут разрешить подключать AI на звуковую дорожку и переводить на любой язык голос. Правда не знаю, бесплатно или нет.
С неродного языка многоминутный "перевод влет на слух" утомляет и вырубает мозг. Титры здорово мозг разгружают.
Oleg N. Cher
12.01.2024, 02:40
СРЕДА РАЗРАБОТКИ COWGOL ДОСТУПНА НА Z80 И CP/M
Cowgol на Z80 под управлением CP/M объединяет все необходимое для предоставления среды разработки Cowgol (включая Си и ассемблер) на Z80 под управлением операционной системы CP/M, что упрощает начало работы с языком Cowgol, небольшим, самораскручиваемым и современным.
Cowgol — экспериментальный современный язык для (очень) маленьких систем.
Zilog Z80 представляет собой 8-битный микропроцессор, распространенный во встроенных системах 1970-х и 1980-х годов, а CP/M — той же эпохи операционную систему для массового рынка. Что касается Cowgol, это набор инструментов, язык программирования, основанный на Ada, и компилятор предназначенный для очень маленьких систем, таких как Z80.
Отличием Cowgol является то, что он предназначен для самостоятельного размещения на этих небольших системах; Cowgol написан сам по себе и способен компилироваться сам. После того как компилятор скомпилирован для конкретной целевой архитектуры (например, Z80), его можно затем использовать в целевой системе для компиляции и запуска программ самостоятельно.
К счастью, нет необходимости начинать с нуля. Репозиторий Cowgol на Z80, работающий под управлением CP/M (см. первую ссылку этого поста), содержит предварительно скомпилированные двоичные файлы и руководство по их использованию.
Cowgol все еще находится в стадии разработки, но он работает. Это современный язык, хорошо подходящий для (очень) небольших систем, и благодаря этому проекту его запуск и запуск на Z80 под управлением CP/M стал настолько простым, насколько это возможно.
Спасибо [feinfinger] за подсказку!
https://hackaday.com/tag/programming-language/
(обновлено 7 декабря 2023 г.)
Cowgol — это язык программирования для очень маленьких систем, включая компьютеры Z80 (см. https://github.com/davidgiven/cowgol ).
Здесь вы найдете полную среду разработки Cowgol для CP/M с процессором Z80.
Чтобы скомпилировать исходные файлы Cowgol (и, необязательно, файлы Си и ассемблера) или создать исполняемый файл на основе исходных файлов Cowgol (и, необязательно, файлов Си и ассемблера), используется следующая команда:
COWGOL [-C] [-Mmapfile] [-Lfile] source1.cow [ source2.cow | источник.c | источник.as ] ...
Можно указать более одного исходного файла (с расширениями: .cow = исходный файл Cowgol, .c = исходный файл C, .as = исходный файл ассемблера)
Первый файл должен быть исходным файлом Cowgol (он содержит «основной»).
Подпрограммы Си и ассемблера можно вызывать из исходных файлов Cowgol.
Если вы хотите просто скомпилировать/собрать файлы, необходимо использовать опцию -C.
Если опция -C не указана, файлы сначала будут скомпилированы/ассемблированы, а затем скомпонованы в исполняемый файл CP/M (названный в честь первого файла в списке).
Опция -M создает карту памяти для исполняемого файла.
Опция -Lfile добавляет файл «libfile.lib» в список ссылок.
HiTech LINK используется для связи объектных файлов.
Необходимы следующие исполняемые файлы:
$EXEC.COM, «пакетный процессор» из компилятора C HiTech.COWGOL.COM, компонент, который запускает все остальные исполняемые файлы (модифицированный вариант C.COM от HiTech).COWFE.COM, часть компилятора Cowgol (модифицированный вариант оригинального COWFE, написанный Дэвидом Гивеном)COWBE.COM, часть компилятора Cowgol (модифицированный вариант оригинального COWBE, написанный Дэвидом Гивеном)COWLINK.COM, часть компилятора Cowgol (модифицированный вариант оригинального COWLINK, написанный Дэвидом Гивеном)COWFIX.COM, интерфейс к Z80AS (преобразует выходные данные COWLINK в синтаксис, принятый Z80AS)Z80AS.COM, ассемблер (см. https://github.com/Laci1953/Z80AS )LINK.COM, компоновщик HiTechCPP.COM, препроцессор C HiTech.P1.COM, компилятор C HiTech, этап 1.CGEN.COM, компилятор C HiTech, этап 2OPTIM.COM, оптимизатор компилятора C от HiTech.
Также должен присутствовать файл библиотеки «cowgol.coo».
Папка EXE содержит исполняемые файлы.
Среда выполнения имеет стек размером 512 байт, что больше исходного стека размером 128 байт.
См. «Dynamic_allocation_in_Cowgol.txt» для получения подробной информации об использовании функций динамического распределения из Cowgol.
Папка INCLUDE содержит включаемые файлы и файл библиотеки cowgol.coo.
В папке «Примеры» содержатся примеры сеансов компиляции.
https://github.com/Laci1953/Cowgol_on_CP_M/tree/main
Oleg N. Cher
12.01.2024, 15:14
Дэвид Гивен говорит:
11 декабря 2023 г., 6:37
Я сделал Ковгол! Это всё еще грубовато, но достаточно мощно, чтобы написать на нем компилятор. Очевидно. С точки зрения самостоятельного хостинга самая большая недостающая функция заключается в том, что компилятор основан на генераторе парсера Lemon, который написан на Си, поэтому для изменения парсера всегда требуется кросс-компиляция с ПК. Мне нужно подумать о замене этого рукописным парсером. Если я смогу уменьшить размер кода, это тоже будет хорошо, так как в настоящее время внешний интерфейс компилятора занимает 35 КБ на Z80 (и 36 КБ на 8080, 43 КБ на 6502 и 33 КБ на 6303).
https://hackaday.com/2023/12/10/cowgol-development-environment-comes-to-z80-and-cp-m/#comments
- - - Добавлено - - -
Ладислав Силагьи говорит:
12 декабря 2023 г., 5:59
@JRD:
Cowgol — очень привлекательный язык для всех, кто работает на компьютерах на базе Z80. Однако для компьютеров Z80 в оригинальной версии Дэвида Гивена на GitHub не было достойной «среды разработки». То есть не было возможности скомпилировать программы Cowgol с помощью простой команды, как в случае с программами, написанными на Си, где вы используете команду:
>C source.c
, чтобы скомпилировать source.c и создать исполняемый файл source.com. построен.
Это именно то, что я сделал, предоставив платформу для использования одной команды, например:
>cowgol source.cow
,чтобы скомпилировать source.cow, скомпоновать его и построить исполняемый файл source.com.
Более того, вы можете смешивать Cowgol, Си и ассемблер:
>cowgol main.cow подпрограммуа.c подпрограмма2.as
, чтобы получить скомпилированные файлы source.cow и подпрограммы подпрограммы1.c, сборку подпрограммы2.as, связанные объектные файлы и сборку файла main.com. .
Платформа использует компоненты HiTech (компилятор и компоновщик C), специальный синтаксический анализатор и исполнитель командной строки Cowgol.com (адаптированный из оригинального C.COM) и мой собственный ассемблер Z80AS.
Примеры см. на https://github.com/Laci1953/Cowgol_on_CP_M .
Сейчас я работаю над улучшенным компилятором Cowgol, способным компилировать исходные файлы большего размера на системах Z80 с 128 или 512 КБ ОЗУ.
Он будет полностью использовать доступное пространство оперативной памяти для размещения объектов, позволяя обрабатывать очень большие файлы Cowgol (надеюсь, он сможет скомпилировать себя сам…)
Небольшой тест уже работает с частью компилятора (cowfe.com); тест выполняется на компьютере Z80 с оперативной памятью 512 КБ:
D>cowfe t.cow test
COWFE: 18 КБ свободной основной памяти
448 КБ свободной расширенной памяти
> T.COW
выполнено: 17 КБ свободной основной памяти
442 КБ свободной расширенной памяти
D>
Конечно, до завершения всех испытаний еще далеко…
Ладислав
Oleg N. Cher
17.01.2024, 01:39
Из личной переписки с Дэвидом, автором Cowgol.
Здравствуйте --- спасибо за добрые слова!
Я знаю об Oberon, хотя никогда им не пользовался. (Я живу в Цюрихе, где находится ETH, так что я вроде как должен знать о нём! Я даже видел некоторые из его машин Lilith в местном VCF). Однако я никогда не был особенно увлечён этой ветвью виртовских языков, поэтому Cowgol в значительной степени основан на Ada, с некоторыми изменениями, чтобы сделать его более привлекательным для современных программистов (таких как я). Одним из них была замена Ada <> на C-подобный !=, просто потому что это намного привычнее. Я не хочу использовать # по той же причине - он просто выглядит странно. Аналогично и с символом комментария. Так что многие из ваших замечаний о том, что он не похож на Оберон, являются намеренными!
(На самом деле Ада использовала -- для введения комментария, но я не хотел этого делать, потому что это усложняет лексер).
Я знаю Фабрицио Карузо; одним из моих других проектов является сопровождение Amsterdam Compiler Kit, и я общался с ним по поводу программирования на 8080.
Уважаемый Дэвид,
Если вы вдумаетесь в графическое начертание символа "#", вы начнете верить, что это самый подходящий символ для обозначения "не равно". Это "=", перечеркнутый дважды. И в этом смысле я не за то, чтобы снимать шляпу перед дурными привычками программистов на Си, а за то, чтобы формировать полезные привычки. Преимущество "#" в том, что он также находится в таблице ASCII и доступен для всех ретро-компьютеров.
Oberon - уникальный язык. Последняя редакция Oberon-07 кажется мне слишком минималистичной, но Oberon-2 и особенно Component Pascal очень хороши. По моему мнению (и по мнению Вирта), это по-прежнему лучший выбор для изучения программирования.
Я бы не сказал, что Cowgol сильно похож на Ada. Это своего рода смесь Algol 60/68 и Си с небольшими добавлениями.
Кстати, о комментариях. Oberon принимает только один тип комментариев (* comment *), но они могут быть вложенными. Такие комментарии очень удобно использовать для временного комментирования большого блока кода. Я ничего не имею против однострочных комментариев, но я бы не хотел отказываться от возможности быстро закомментировать блок кода.
Я из того же русскоязычного сообщества, что и shattered, и меня интересует не Unix v7, а RT-11, и я хотел бы отметить, что я так и не понял, как использовать ваш ассемблер для PDP-11. Я получаю только это:
zorko@User-PC:~/9/BK/obj$ ../bin/cowasm Devyatka.mac
PDP-11 Assembler (C) 2020 David Given; 4096kB free
Pass 1
error at line 1: expected an identifier
Я не знаю, что с этим делать. Я также не знаю, может ли ваш ассемблер в конечном итоге генерировать .sav-файлы для RT-11.
Еще о вашем бэкэнде для pdp-11. Сейчас он генерирует числа следующим образом:
mov #8911h, -(sp)
macro-11, который использовал shattered, не понимает суффикс h для 16-ричных чисел. Нехорошо, что вы нарушили совместимость с самым функциональным ассемблером в мире pdp11.
Что касается генерации кода в z80. Я использую cowgol для генерации кода для Sinclair ZX Spectrum, и именно в этом месте org 100h и настройки стека очень сильно мешают:
org 100h
lxi sp, TOP+128
call f29___main
rst 0
Этот rst 0 в конце вызывает перезагрузку ZX Spectrum. Спектрум также имеет ПЗУ по адресу 100h. Поэтому начальный адрес для него должен быть от 6000h
Вы же понимаете, что я не могу использовать Cowgol в его нынешнем виде, и мне все равно придётся вносить свои правки. Я прошу вас о понимании. Меня не интересует ни сама CP/M, ни работа Cowgol в CP/M. Но то, что компиляция HelloWorld занимает 17 минут, когда у вас на столе стоит компьютер с частотой 3 ГГц, - это как-то странно.
Вместо этого я бы предпочёл больше заниматься оптимизацией, хотя это очень трудная работа. Если я и буду как-то подправлять свой форк Cowgol, то точно в сторону большего упрощения, а не потакания плохим сишным привычкам. Вместо сложного end loop / end if я бы предпочел обычный end. Это приведёт к меньшему засорению кода.
Вы не будете возражать, если я начну разрабатывать форк Cowgol по-своему? Но имейте в виду, что у меня нет и доли ваших способностей к низкоуровневому машинному коду и усердия. Так что в итоге может получиться что-то, что вам совсем не понравится.
P.S. Я хотел бы собрать cowgol для Win32, но не могу запустить все утилиты из /bootstrap - результирующий файл показывает 0 свободных байт и не открывает файлы. В итоге, я бы (опять же, если бы это был я) просто сосредоточился на создании набора утилит для целевых Linux/AMD64 и Win32/i386. Это покроет желания 99% тех, кто будет разрабатывать на Cowgol. Никто не будет делать это на CP/M или DOS.
Тем не менее, это самый удивительный проект, который я видел за последнее время.
Уважаемый Дэвид,
Возможно, вы об этом не слышали. Ретро-язык, очень похожий на Cowgol.
Millfork для Atari, Apple II, ZX Spectrum, MSX, CP/M, NES, Game Boy, MS-DOS и т.д
Поддерживает генерацию в z80 и 6502. Компилятор написан на Scala. Он поставляется с игрой в Pong для NES (включена в некоторые руководства по NES и переписана из Asm).
https://karols.github.io/millfork
https://karols.github.io/millfork/various/faq.html
https://github.com/KarolS/millfork
https://www.libhunt.com/compare-millfork-vs-cowgol
Я не утверждаю, что это лучше, чем Cowgol. Cowgol обладает неоспоримыми преимуществами в простоте и компактности. Но всё равно стоит посмотреть.
Не обижайтесь на меня, но я бы хотел больше внимания уделять созданию полезных инструментов для создания ретро-игр для целого ряда ретро-платформ, а не делать акцент на CP/M и набортной работе компилятора и инструментов.
Особенно, если вы хотите помочь распространению Cowgol, проще всего сделать это на волне ностальгии по старым компьютерам и играм. CP/M - отличная система для 8080, но она не была слишком распространена в бывшем СССР. У нас были клоны Sinclair ZX Spectrum, Агаты (клоны Apple), БК/ДВК и УКНЦ (на базе pdp11), а позже - MS-DOS.
В то время у нас также были машинки на базе 8080, но на кассетах. И в ПЗУ обычно был монитор объёмом 2 Кбайт. И не было CP/M, и не могло быть. Потому что когда началась эра гибких дисков быстро стали доступны более мощные компьютеры.
Так что у нас мало ностальгии по CP/M, но у нас много ностальгии по ретро-играм, включая их разработку. За последние годы наше сообщество разработало множество отличных игр для целого ряда ретро-платформ, популярных в бывшем СССР.
Я, конечно, хочу иметь возможность просто скачать готовый релиз Cowgol и начать разработку. Потому что вам легко набрать "make" и все пересобрать. Но для людей, которые пришли посмотреть на это, всё далеко не очевидно. Особенно, если они будут собирать его под WSL и столкнутся с теми же проблемами, что и я.
Русскоязычное сообщество обладает большим потенциалом для освоения Cowgol, но им нужно предоставить рабочий инструмент. Они не будут разбираться с компиляцией Cowgol и ошибками сборки, как я пытаюсь это сделать с помощью вас, shattered и других людей.
Поэтому мне кажется, что вам следует позиционировать Cowgol как инструмент для более кроссплатформенной разработки, чем Си. Что отличает его от языка ассемблера, так это переносимость (нет необходимости иметь несколько кодовых баз для разработки сразу для нескольких платформ). А от Си - повышение эффективности благодаря полезным функциям Cowgol. Это большая задача, но, безусловно, достойная.
Также. Людей определённо будет трудно убедить в том, что Cowgol подойдёт им лучше, чем Си или ассемблер. Дело в том, что наше сообщество состоит из заядлых ретро-программистов, которые хотят заставить аппаратное обеспечение работать на 150%, а это можно сделать только на языке ассемблера. Этих людей может удивить только чрезвычайно высокое качество генерации кода, превосходящее SDCC, ZSDCC (от z88dk), а также Hitech C и коммерческий IAR C.
Что же касается меня, то я помню завет Вирта, который звучит так: "вы не преуспеете в программировании, если не сосредоточитесь на переносимости ваших программ между платформами". Я вижу в этом смысле огромный потенциал у Cowgol. Только рано почивать на лаврах, это нужно развивать. В последнее время я видел, что вы делали большой упор на портирование CP/M для 6502. Как вы оцениваете полезность такой разработки для сообщества 6502? Возможно, было бы лучше потратить время не на это портирование, а на Cowgol? В любом случае, я собираюсь разработать игру чтобы посмотреть на Cowgol в действии, как только пойму как собрать на этом HelloWorld для интересующих меня платформ.
Oleg N. Cher
17.01.2024, 22:06
Что касается языкового стиля: могу только повторить, что Cowgol не основан на Oberon, и я не хочу вносить в него серьёзные изменения на данном этапе.
Что касается ассемблера: да, он не совместим с macro11. На самом деле он использует тот же движок ассемблера, что и классический ASM из 8080 CP/M, потому что это то, что было у меня под рукой в то время. Если вы хотите собрать что-то с помощью macro11, вам нужно будет изменить генерируемый синтаксис, отредактировав серверную часть PDP-11. Вы можете найти сгенерированные ассемблерные файлы в каталоге .obj после сборки - например, .obj/bin/cowbe-pdp11.unixv7.asm. Это создаст двоичные файлы для Unix версии 7. Поддержка RT11 только начинается, но для неё нет библиотеки времени исполнения. (Если вы хотите внести свой вклад, я бы с удовольствием добавил поддержку.)
Re the Spectrum: да, вы, очевидно, не можете запускать двоичные файлы CP/M в Spectrum! Вам нужно будет написать библиотеку времени исполнения и модуль компоновщика специально для Spectrum. Скопируйте rt/cpmz в rt/spectrum и отредактируйте его --- вы захотите отключить модули argv и file, а cowgol.cos можно оставить как есть, поскольку он просто содержит вспомогательные процедуры компилятора. Для компоновщика скопируйте src/cowlink/arch8080.coh в src/cowlink/archspectrum.coh и отредактируйте его. Также есть несколько довольно грубых сборочных скриптов, которые нуждаются в обновлении; toolchains.lua определяет все цепочки инструментов, которые будут созданы. Вы можете закомментировать некоторые, если они вам не интересны.
Я не пробовал собирать это для win32. Вероятно, это было бы довольно болезненно.
Делайте форк: вам не нужно спрашивать! Лицензия либеральная и позволяет вам делать с ней всё, что вы хотите. Но имейте в виду, что если вы слишком существенно что-то измените, я не смогу принимать от вас пулл реквесты...
> Не обижайтесь на меня, но я бы хотел больше внимания уделять созданию полезных инструментов для создания ретро-игр для целого ряда ретро-платформ, а не делать акцент на CP/M и набортной работе компилятора и инструментов.
Это прекрасно, но... Я не хочу этого делать. Для меня это упражнение в попытке создать компилятор для современного языка, который будет работать в этих сверхограниченных системах. Как вы уже выяснили, если вас интересует кросс-компиляция, есть другие, лучшие языки. Например, LLVM сейчас создает довольно хороший машинный код для 6502 и Z80. Для меня основной целью является создание компилятора, который будет работать в этих системах, а не создание компилятора для этих систем (хотя я также нацелен на кросс-компиляцию, потому что на самом деле пытаться что-либо сделать на 4 МГц Z80 невероятно неприятно).
> Я, конечно, хочу иметь возможность просто скачать готовый релиз Cowgol и начать разработку. Потому что вам легко набрать "make" и все пересобрать. Но для людей, которые пришли посмотреть на это, всё далеко не очевидно. Особенно, если они будут собирать его под WSL и столкнутся с теми же проблемами, что и я.
Да, я понимаю ваше разочарование - создавать его сложно. Есть несколько доступных двоичных файлов, но они действительно старые. Оказывается, распространять двоичные файлы сложнее, чем кажется. В какой-то момент я хочу настроить autobuilder, но он сможет создавать только двоичные файлы для Linux i386. (Которые могут запускаться на WSL?)
Что касается ваших проблем со сборкой: не могли бы вы прикрепить журнал сборки, пожалуйста?
Кроме того, прямо сейчас он на самом деле не настроен для автономной работы. Все программы, с которыми я работал, были интегрированы в систему сборки, которая действительно сложна. Это то, над чем нужно поработать.
> В последнее время я видел, что вы делали большой упор на портирование CP/M для 6502. Как вы оцениваете полезность такой разработки для сообщества 6502? Возможно, было бы лучше потратить время не на это портирование, а на Cowgol? В любом случае, я собираюсь разработать игру чтобы посмотреть на Cowgol в действии, как только пойму как собрать на этом HelloWorld для интересующих меня платформ.
Дайте мне знать, если у вас возникнут какие-либо проблемы!
(IIRC, я действительно запустил предыдущую версию на Spectrum, но это было сложно, потому что нет ничего похожего на стандартный API операционной системы. IIRC есть rst, который напечатает символ, и все. Все остальное должно быть сделано путем вызова в Basic ПЗУ.)
Я всё же замечу мимоходом, что есть привычки, которые даже не рациональны. Они просто более привычны. Людям труднее всего пересматривать их и размышлять о них. Оберон - моя зрелая любовь, а не детский отпечаток, как ностальгия по ZX Spectrum.
Вы, вероятно, не согласны с моими наполеоновскими планами, тем более, что я вообще не понимаю, как собирать Cowgol. Я не очень хорошо владею Lua и плохо разбираюсь в Python. Мне гораздо проще модифицировать серверную часть для CP/M, чем копировать её для Spectrum отдельно - потому что я просто не пойму, куда её добавлять.
Я не эксперт по RT-11, и сейчас хочу сначала попробовать просто сгенерировать файл .bin с адреса 200h (как для нашей ретро-платформы БК-0010). (у меня есть утилита sav2bin). Да, это не самый простой способ получить .bin для платформы на базе pdp11, так что подскажите мне способ получше...
Для win32 все не так болезненно, есть просто баги (на самом деле различия логики работы под UNIX и Windows). Для win32 всё собирается отлично даже без предупреждений. Нужны только вызовы pread и pwrite, которые лично я взял из plzip-1.5-rc2.w32-w64.zip, так как в MinGW их нет.
Но проблема в том, что даже для Linux файлы из папки /bootstrap в текущем состоянии вашего репозитория выдают ошибочные нерабочие исполняемые файлы, которые показывают 0 байт свободной памяти. Попробуйте сами...
Если вы хотите создать .exe для Windows под Linux, то, конечно, возникнут трудности. Но под Windows, я уверен, вам подойдет любой компилятор. Я использовал MinGW.
Ну всё, про хорошую кодогенерацию в Cowgol можно забыть. Делать её просто некому. Хинт от Дэвида: юзайте LLVM. Я, кстати, не знал, что LLVM столь хорош для 6502.
Увы, у каждого из нас мозг вывихнут по-своему. Дэвиду интересно чтобы компилятор работал на CP/M.
- - - Добавлено - - -
Ну что, есть желающие заняться низкоуровневой кодогенерацией? То, что по сути советовали мне сделать. ;)
Cowgol база отличная, для 8 бит подходит гораздо лучше Оберона.
Andrew771
17.01.2024, 23:41
Ну что, есть желающие заняться низкоуровневой кодогенерацией? То, что по сути советовали мне сделать.
Cowgol база отличная, для 8 бит подходит гораздо лучше Оберона.
Делай сам, не жди никого :)
И сразу игру на нем напиши какую-нить для популяризации
Oleg N. Cher
18.01.2024, 01:26
Да я уже готов лапки складывать. Нет у меня талантов таких неимоверных.
Кто сможет это развивать лучше автора. А ему не надо.
- - - Добавлено - - -
Ну и, кроме того, у меня есть ZSDCC для Спека и GCC для БК/УКНЦ (https://zx-pk.ru/threads/33870-oberon-gcc-dlya-uknts-bk.html) (спасибо yu.zxpk (https://zx-pk.ru/members/8845-yu-zxpk.html)). На сём мою ностальгию по ретро можно считать примерно утолённой.
Вот хотел побольше контента напихать в игру для бэкашки, но сейчас не уверен, что теперешний Cowgol переплюнет GCC по качеству кода. Хотя потенциал у него огромезный. Жаль, народ не понимает, ковыряют маленькое своё, кто PL/M, кто ZX Like Pascal... ;)
И даже тебе, Андрей, есть чему поучиться у Cowgol. Например, полной линейке целых типов 8-, 16- и 32 бита со знаком и без.
Oleg N. Cher
18.01.2024, 05:25
>
Уважаемый Дэвид,
Если Вас так сильно интересует работа утилит непосредственно на ретро-устройствах, то посмотрите, что сделал очень хитрый парень Чарльз Мур. Он объединил в одно целое компилятор и интерпретатор, редактор, операционную систему, утилиты, язык, библиотеки и встроенные процедуры. И всё это в самом минимальном объёме кода. Я конечно же имею в виду его язык Форт. Более того, есть очень маленькие по объёму исходники Форт-Бейсика, Форт-ассемблеров и даже Форт-Паскаля. Вам стоит развивать Форт, это чрезвычайно компактный и очень расширяемый язык. Но это требует изменения мышления, а это обычно самое трудное для людей. Cowgol предлагает более традиционные подходы - компилятор, компоновщик, утилиты в виде программ для запуска, которые обмениваются между собой данными через файлы. Форт же переворачивает всё с ног на голову. Только Форт поможет вам обеспечить на порядок более эффективное использование памяти вашими утилитами, чем это делает сейчас Cowgol.
Не надо придумывать оправданий, вы знаете, что я прав. Но писать на Форте лично мне некомфортно. Я сделал свою реализацию Форта ещё в 1997-м для ZX Spectrum (это называлось QuickForth и потерялась на старых кассетах). И после этого пробовал писать на Форте ещё на ПК (AstroForth, GP-Forth, 4th), но полностью разочаровался в возможностях Форта по созданию надежного программного обеспечения. Однако для своей ниши (работы в маленьком объёме памяти) он подходит идеально. Но лично я предпочитаю комфортную разработку, и в инфраструктуре Cowgol вижу хорошую основу для получения аналога инструментария GCC или LLVM, только в гораздо меньшем по объёму исполнении, подходящем для 8-битных платформ. Но вы объяснили ваши цели, и Cowgol стал мне гораздо менее интересен. Судите сами, у меня есть игра, которую я разрабатываю для компьютера БК-0010 (16К рабочего ОЗУ + 16К экранной памяти). Сейчас игра уже занимает 15 Кб. Я хотел бы поместить туда больше игрового контента, но очень не хочется переписывать её на ассемблер. Cowgol не сгенерирует для меня код лучше, чем GCC для PDP-11. Cowgol не будет развиваться вами в направлении улучшения качества кода, или будет, но очень незначительно. Я упомянул Форт не потому, что надеюсь, что вы услышите мои аргументы. Но как я могу работать над проектом, если у меня нет способностей и влияния на автора, который делает это просто для собственного удовольствия, а не для того, чтобы облегчить мне жизнь? ;)
Поэтому Cowgol остаётся для меня просто прикольной вещью в себе. Но не для использования.
Эффективная генерация кода - это именно та высшая ценность, которая могла бы привлечь меня на светлую сторону силы Cowgol, Но в том виде, в котором он существует сейчас, с очень причудливым, даже вычурным, попахивающим архаикой синтаксисом, который я не могу запомнить, предназначенный для набортной работы и генерации посредственного кода (качеством ниже среднего компилятора Си) это уже далеко не столь интересно. Сильно не рассчитывайте на мою помощь. Меня не интересует работа Cowgol ни на Спектруме, ни под RT-11. Я смогу вам помочь только если у нас совпадут хотя бы краткосрочные цели, но пока я не вижу точек пересечения. Вы посмотрите, что даже к Спектруму мы с вами подходим по-разному. Вы хотите, чтобы Cowgol работал на самом Спектруме, а я хочу чтобы он работал ДЛЯ Спектрума.
Также хочу показать Вам компилятор PL/M который работал на основанных на 8080 ретро-компьютерах (под CP/M), но потом был реверсирован и транслирован на Си. Человек, который занимался освоением данного компилятора, утверждает, что несмотря на архаичный синтаксис, этот компилятор порождает для 8080 код прекрасного качества. Вероятно, это лучшее по качеству кода средство разработки для 8080, которое мы имеем на данный момент для языка высокого уровня.
https://github.com/MrDemonid/PL-M-80-Tools
Одному человеку другие говорят - что надо делать и как. В ответ этот человек других посылает.
Затем этот первый человек говорит другому - что надо делать и как. В ответ этого человека посылают. Первый человек удивляется - а меня то за что??
Ню ню.
- - - Добавлено - - -
у меня нет способностей и влияния на автора, который делает это просто для собственного удовольствия, а не для того, чтобы облегчить мне жизнь?
Да да, остальные должны делать только то, что облегчит жизнь ТС. Долго ему придётся ждать.
- - - Добавлено - - -
Ещё мысль на тему - кто, что и как должен делать. Как говорили в DEC
"Let's be different"!!
Oleg N. Cher
18.01.2024, 16:29
Так а я о чём, Hunta. Главным быть хочу. Готов на себя взять тяжёлое бремя принимать ключевые решения.
Требуются чернорабочие, которые будут быстро-быстро писать оптмальные кодогенераторы.
А ты лучше поблагодари, что я слегонца ковырнул Cowgol, из нашего гадюшника этим заниматься некому. Пожалуй, кроме shattered'а.
Главным быть хочу.
Вот тебя с твоей хотелкой
чернорабочие
и посылают
этим заниматься некому.
Этим чем? Твоими хотелками? Да - некому. Потому что у всех свои хотелки.
Oleg N. Cher
18.01.2024, 21:31
Ну вот. Поэтому всем, кто жаждет писать на асме - я буду советовать писать быстро-быстро.
Всем, кому не нравится трансляция через Си - буду советовать сделать без Си.
А всем, кто не приемлет качества кода от языков высокого уровня - буду советовать вплотную заняться генерацией эффективного кода.
А сам буду помаленьку XDev совершенствовать. Чего ещё от меня вы ждали, крутые советчики и ковырятели в носу?
Andrew771, ты подумай как можно сделать задачи по оптимизации качества кода маленькими и законченными подзадачами. Если каждый напишет своё золотое правило - вот и получится классная кодогенерация. Я понимаю насколько это сложно. Ну так может хватит просто передирать у Вирта, а вместо этого сделать лучше, чем Вирт? Пусть это будет скриптовый мини-язык оптимизаций или щелевой (peephole) оптимизатор. Ты просто пойми барьер тех, кто не хочет влезать в весь твой код, кому не нравится Паскаль, кому не нравится Z80. А хотя да, пустое пишу.
Кряшка яростно лайкает всё, что меня шпыняет)))
лайкает
Так а смысл тебе писать что то, если ты не читаешь. Размазывать только и способен
Oleg N. Cher
18.01.2024, 22:57
Ну, лайкай лайкай авось тебе полегчает.
А ты заметил, Кряшечка, что я с Hunta разговариваю иначе, чем с тобой? А всё потому, что Hunta не тролль стопицотого уровня, а честный труженик, хоть и на своей волне.
Вот видишь. Я даже не разговаривал с тобой а ты размазал. О чем я собственно и говорю. Вообще одичал и потерял способность общаться.
Oleg N. Cher
18.01.2024, 23:22
Да, спасибо. Очень приятно услышать конструктивную критику от тролля в свой собственный адрес)
Кстати, ты знал как делают науку? Собираются умные дядьки, разговаривают, думают, спорят, пьют кофе, завтракают и обедают в кафе. В муках рождают творческие идеи. То, что ты бы назвал "размазывать", хотя по сути это то, чем ты занимаешься здесь, не делая абсолютно ничего другого. Но ты размазываешь из пустого в порожнее, а я сею семена, которые несомненно дадут свои ростки и плоды.
Я знаю Форт - я даже написал Форт. Но мне очень не нравится его использовать. Он достигает своей радикальной простоты за счет отказа почти от всех функций, необходимых для реальной разработки программного обеспечения: переносимости, модульности, абстракции... Это фактически сильно типизированный язык без проверки типов, и единственный способ сообщить об ошибке (например, использовать FDROP вместо DROP) - это тонко отравить стек, что впоследствии приведет к сбою. Кроме того, он медленный - быстро для интерпретируемого языка, но все же намного медленнее, чем родной машинный код.
Тогда я бы посоветовал Вам не использовать Cowgol. Он явно не соответствует вашим требованиям.
Уважаемый Дэвид,
Если позволите, я скажу пару слов в защиту Форта. Вы, как всегда, слишком обобщили. Форт является медленным, поскольку использует прямой шитый или свёрнутый шитый код. Вы можете не использовать шитый код вообще - генерируйте сразу машинный код. Будет очень быстрый Форт, со скоростью получше, чем в Cowgol.
По поводу переносимости - Форт очень переносимый в перспективе язык. Вам просто надо реализовать одинаковый набор слов для всех интересующих вас архитектур. И поддерживать его одинаковым. Нивелируйте различия между разрядностью платформ, как вы делаете это сейчас. Слова, которые будут специфичны для платформы, не должны быть в общем наборе.
По поводу отравления стека - ну так сделайте опциональную проверку на то, чтобы DROP выдавал ошибку, если стек пуст. Это делает даже простой Forth для ZX Spectrum.
По поводу же модульности и абстракции я вынужден с Вами согласиться...
Да, спасибо. Очень приятно услышать конструктивную критику от тролля в свой собственный адрес)
Вот смотри, я 2 или 3 сообщения написал тебе, нормально написал, еще несколько не тебе, но ты вылез из своего чулана и начал меня оскорблять, по всей видимости пытаясь спровоцировать и накидать жалоб.
И о какой критике речь? Ты просто решил еще раз меня оскорбить, даже там где от меня не было сообщений. Ты просто жалок. Тебя даже обероновцы с своего форума выпхали, ты их и там достал своим постоянным нытьем.
Можешь дальше размазывать, мне побоку на тебя.
Oleg N. Cher
19.01.2024, 01:58
Крякушенька,
ты не можешь нормально писать, ты для этого не подходишь. Ты можешь только пить кровь из тех, кто с тобой соприкасается.
Ты человек абсолютно иных от моих ценностей, и не можешь сказать мне ничего полезного. Уж за 45 лет я научился разбираться в людях. От таких как ты исходит только тлен и хаос.
Я не вижу, чтобы ты делал хоть что-то полезное даже здесь на форуме. Ты не кодишь, не конструируешь. Ты даже не рисуешь карты к играм. Ты не пытаешься что-то предложить вместо асма, как хотя бы пытаюсь делать это я. Ты именно ноешь и ноешь, и от этого уже всем тошно.
И да, никто меня ниоткуда не выпихивал, это твои влажные фантазии. А на конкретно этом форуме было немного чище пока ты не прилез снова замусоривать темы.
Oleg N. Cher
19.01.2024, 04:42
Кстати, здесь на форуме каждый второй, если не первый, пост люди дискутируют и обозначают проблемы. Именно эти термины я употребляю вместо твоих "размазывают" и "ноют". А что, что ты обвиняешь в этом только меня, говорит о твоём врождённом лицемерии.
Поэтому всем, кто жаждет писать на асме
Язык ассемблера:
PROCEDURE MULBLK
BEGIN
LET R0 := BLKBEG
LET R2 := CAPTR
LET R3 := ACTCNT
THRU R3 ; blocks count
; INIT
LET R4 := (R2) ; block words count
IF RESULT IS NE THEN
LET R5 := 2(R2) ; first word command pointer
THRU R4
LET (R0)+ := (R5)+ ; copy next block
END
ELSE
LET (R0)+ := #NOP
END
IF APHASE NE #0 THEN ; if not init calculating
; ACTION
LET R4 := 4(R2)
IF RESULT IS NE THEN
LET R5 := 6(R2) ; first word command pointer
THRU R4
LET (R0)+ := (R5)+ ; copy next block
END
END
END
END
LET (R0)+ := (PC) ; and return at end
RETURN
END MULBLK
Bedazzle
19.01.2024, 09:43
Язык ассемблера
сурово :)
сурово
Да не особо. Просто ассемблер MACRO-11 поддерживает макросы, причём механизм настолько эффективен, что позволяет реализовать макросы для структурных операторов.
Исходно этот пакет макросов написал кто-то (EDWIN H. MARISON) в DEC (?), ну а когда мне он попался на глаза, я понял, что с его помошью можно решить некоторое количество проблем (в первую очередь - кучи одноразовых меток) и, скорее всего, сильно ускорить написание программ (да, на языках ассемблера программы пишутся медленней, зато работают и трятят ресурсов (при наличии опыта у писателя) меньше.
Исходный вариант я доработал (и дорабатываю), так что сейчас у меня есть MODULE, IMPORT, EXPORT, PROCEDURE, IF, ELSIF, ELSE, WHILE, REPEAT-UNTIL, FOR (но вот с ним я толком не разобрался), LOOP, THRU (цикл с определённым количеством повторений), CASE (такое впечатление, что недоделанная заготовка - не разбирался) ну и плюс умение (до определённой степени) парсить выражение, так что проходит что-то типа
LET R0 := R1 + R0 + R0 + R1 + #CMDPTR + #2 ; R0 := TCURR*8+TCURR*2 (Message, init(2), action(2), skip title
...
IF R2 EQ #0 AND R3 EQ #0 LEAVE LOOP
Dart Alver
19.01.2024, 10:37
Просто ассемблер MACRO-11 поддерживает макросы, причём механизм настолько эффективен, что позволяет реализовать макросы для структурных операторов.
Даже любопытно стало, можно ли чтото похожее сбацать в SjASMе, если поковырять макросы и Lua ?
можно ли чтото похожее сбацать
Вот тут ничего подсказать не могу, но учитывая, что на MACRO-11 делали макросы для генерации кода под 6502 (только, похоже, они утеряны - но нард на vcfed пытается найти) и, если мне не изменяет память, я видел и под 8080 (надо будет покопаться в своей файло-помойку) - что-то мне подсказывает, что подобный трюк можно будет провернуть на MACRO-11 :)
Andrew771
19.01.2024, 22:43
Andrew771, ты подумай как можно сделать задачи по оптимизации качества кода маленькими и законченными подзадачами. Если каждый напишет своё золотое правило - вот и получится классная кодогенерация. Я понимаю насколько это сложно. Ну так может хватит просто передирать у Вирта, а вместо этого сделать лучше, чем Вирт? Пусть это будет скриптовый мини-язык оптимизаций или щелевой (peephole) оптимизатор. Ты просто пойми барьер тех, кто не хочет влезать в весь твой код, кому не нравится Паскаль, кому не нравится Z80. А хотя да, пустое пишу.
Не пустое. Со времен своей статьи (http://dgmag.in/N15/DowngradeN15b.pdf) по генерации и оптимизации кода 2015 года (стр.52) я уже серьезно продвинулся дальше. Первые оптимизации действительно делал по книге Вирта "Построение компиляторов". В ней только общими словами на 2-3 страницы было описано. а я перевел в код асма Спектрума. А после делал свои оптимизации (не описаны в книге), последние летом 2023 года - нахождение одинаковых кусков кода и оформление их в процедуры. До этого оптимизировал индексы массивов и быстрое умножение. Подумывал уже про байт-код java, место сэкономлю еще, но производительность немного упадет. Думаю как опцию сделать. Нужно уже новую статью писать :)
Oleg N. Cher
20.01.2024, 02:49
Извини, что я обобщаю. На самом деле в плане оптимизации ты продвинулся даже несколько дальше Вирта. Вирт оптимизациями особо не заморачивался.
Andrew771
20.01.2024, 12:18
В современных компиляторах наверно до такой степени не оптимизируют - нет смысла, т.к. памяти и скорости хоть отбавляй, и можно еще добавлять. Только время и деньги потеряют на разработку. А у нас ситуация другая :)
А чего было бы не взять подмножество Ada... Нет, млин, обязательно придумывать велосипед с колёсами в форме ромбододекаэдра.
- - - Добавлено - - -
В современных компиляторах наверно до такой степени не оптимизируют - нет смысла, т.к. памяти и скорости хоть отбавляй, и можно еще добавлять. Только время и деньги потеряют на разработку. А у нас ситуация другая :)
Ещё как оптимизируют. Только методы и цели оптимизации несколько другие. Сейчас в кровавом энтерпрайзе развели столько уровней абстракций, что мощщи реально не хватает.
Oleg N. Cher
21.01.2024, 01:46
на 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, в общем-то не наблюдается. Людям это не нужно. Ну пусть пишут на асме, чо.
Но нашёл вот такое:
Судя по тому что увидел - у MACRO-11 более мощные возможности макросов и макросы для структурного программирования получились более элегантными. То есть если запилить кросс-ассемблер на макросах - можно достичь большего. Но поскольку 6502 и другие процессора (по крайне мере на текущий момент) не в области моих интересов...
- - - Добавлено - - -
В целом же - у PDP-11 настолько удобный набор команд, что С (с его возможностями) остаётся за бортом. Да и не нравится мне его некоторые извраты в синтаксисе. C# более удобен в этом плане (хотя и в нём бы некоторые синтаксические конструкции переделал) но его портировать на PDP-11 - пока задача не для меня.
Oleg N. Cher
21.01.2024, 02:22
Какой-то один избранный процессор (хоть 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
я не видел реализованных на ассемблере проектов с применением структурных макросов а-ля ЯВУ
Некоторое количество исходников программ от самой DEC - были замечены в RSX-11M (где, собственно, на этот пакет я и наткнулся) и, если судить по листингам - то какой-то вариант набора структурных макросов (более ранний?) применялся при написании тестов и среды выполнения комплексных тестов (DEC/X11) в XXDP
И я давно начал их применять - из выложенных в открытй доступ исходников - мой вариант программы SPEED. Сейчас всё написанное, дизассемблированное и изменённые мной чужие исходники (типа исходника монитора XXDP от Ian Hammond) - использует этот пакет.
В целом же - да, макросы (любые) при использовании ассемблеров используются достаточно редко. Ну так и, с моей точки зрения, в массе - уровень программистов падаёт, а макросы (особенно для структурнго подхода) ещё надо написать - народ же, опять же - в массе - привык - погуглил и использовал чьё-то. А тут чьего-то чужого как правило и нету.
Ну так автор 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% от всего цикла "фрейм команды-фрейм ответа".
Не сказал бы, что уровень падает. Просто требования предъявляются другие.
мне сейчас важнее не минимальное количество операций, а чтобы было как можно меньше промахов кеша и адаптация алгоритма к SIMD инструкциям.
Естественно, что бороться за оптимизацию оставшегося кода на Си, который настраивает эту периферию - нет смысла.
Вообще-то, я немножко про другое. И да -
в массе - уровень программистов падаёт
это не про то, что сейчас не встретить высококлассных программистов. Естественно, они есть и будут. Но если взять "среднюю температуру по больнице...".
Вообще-то, я немножко про другое. И да -
это не про то, что сейчас не встретить высококлассных программистов. Естественно, они есть и будут. Но если взять "среднюю температуру по больнице...".
Ну просто порог вхождения снизился. Чем занята основная масса - веб-макаки. Я уже устал с ними бороться. Криво, косо, без должной обработки ошибок... Буду возиться со своими железками, а с макаками пусть начальство разбирается. Этим "веб-программистам" я не авторитет, а какой-то непонятный старпёр.
Конкретные примеры (без имён).
Человек пишет игрушку. Под один из вариантов PDP-11, с его специфическим железом. Какие знания нужны? Знание языка ассмеблера, знания железа (вывод графики, если конкретней, плюс работа в реальном времени - что бы игрушка не тормозила) и до некоторой степени - знание вызовов ОС. Ну может что-то ещё.
Что получаем - непрерывные вопросы - а как это сделать, а как это работает, а вот кто мне сделает - а на предложение - ну почитый ты соответствующую документацию (благо сейчас она есть) - я попробовал, ни хрена не понял (а ещё и доки на английском) и поэтому не буду тратить на это время, мне это не интересно, я хочу игрушку написать. А на подсказки, что у других могут быть свои интересы, а времени свободного не мешок, если ты игрушку пишешь - всё таки придётся приложить свои усилия, в том числе и в областях, которые да, тебе могут быть неинтересны или сложно-разбираемы.. - чего только не пришлось про себя, любимого, услышать.
- - - Добавлено - - -
Ну просто порог вхождения снизился.
Согласен. И с остальным написанным. Вот поэтому и сказал - "в массе - уровень программистов падаёт".
И если по работе ещё как-то приходится с ними общаться (ТТТ, не на текущей, нас в команде сейчас три человека и двое оставшихся вполне на уровне), а вот на одной из предыдущих был как раз такой.. Из поколения с низким порогом вхождения... Ну и кончилось тем, что
пусть начальство разбирается. :)
А, ну это просто человек старается переложить свою работу на других. Чтобы сделали за него. Тут уровень программизма ни при чём.
Или нет?
конечно нет. Но и кросс-компилер должен обеспечить быстрый и комфортный старт и непроблемную загрузку выходного файла в доступный качественный эмулятор. Вчера поковырялся вечер по наводке TC с sdcc для ATARI и как всегда "ковровой дорожки" нет, нет и "висячего мостика на веревках". Каждый новый шаг к цели вызывает необходимости рыться в инете, а некоторые ресурсы в России, как вы понимаете, без VPN недоступны. Короче до эмулятора работающий код из примера у меня на Windows7 32 bit "не долетел".
Так и не нашел эмулятора ATARI, который умеет грузить на выполнение бинарь или hex-файлы, а sdcc не выдает файлов для загрузки.
- - - Добавлено - - -
человек старается переложить свою работу на других
а кому в наше время нужна работа без быстро достижимого результата?
- - - Добавлено - - -
Человек пишет игрушку
это вообще начинается без программирования, которое всё - просто способ реализации и ничего более! Хотя конечно если нет способов или умения реализовать задуманное - тоже результат нулевой.
а кому в наше время нужна работа без быстро достижимого результата?
Ну если ты так считаешь, это многое... Хотя о чём я - тут и так всё давно было понятно
это вообще
было написано про другое. Но в массе народ и читать разучился.
- - - Добавлено - - -
и как всегда "ковровой дорожки" нет, нет и "висячего мостика на веревках"
А самостоятельно мы решать проблемы разучились.
Нужно мне было собрать прошивку для Готека из известных исходников. Все скрипты под Питон. Ок, пару вечером повозился - собрал.
Нужно было мне один скрипт на Перле (создаёт XXDP образы) доделать под пару других дисковых устройств - и с Перлом разобрался и допилил код, написанный под что-то Маковское, в код для Windows. И никакх стонов про то, что Перл первый раз в глаза увидил или что-то там про x86 или x64 - личная заинтересованность - она творит чудеса. А не как вот здесь:
до эмулятора работающий код из примера у меня на Windows7 32 bit "не долетел"
Значит, не очень хотелось.
Значит, не очень хотелось
зато на Zonnon exe-ники получил в обход "кривого" Zethz.zonnon.builder-а. Исправить его, не имея исходников, скорее всего нереально.
Например, time.znn
(* ********* Zonnon online collection ***********
* Using system time from Zonnon
*
* This example is a part Introdunction into Zonnon for beginners
* www.zonnon.ethz.ch/usergroup
* (c) ETH Zurich
*)
module Main;
import System;
var
dt: System.DateTime;
begin
dt := System.DateTime.Now;
writeln(dt.Ticks);
end Main.
Вот так в батнике
zc /entry:Main time.znn
time
pause
Я не говорю, что Zonnon-а можно приспособить в качестве компилятора для 8-биток. Даже не представляю как.
А с atasm-ом ковыряться надо уметь делать образы дисков .xfd .atr. Это если брать с sdcc выходной файл ассемблера.
Чем их создавать? Подскажи, если такой эрудит. А вообще TC этим грешит в своих тредах. Я когда о чем-то пишу, стараюсь описывать "от и до" и очень подробно.
- - - Добавлено - - -
А самостоятельно мы решать проблемы разучились
приводил уже многократно примеры нерешаемых проблем из моей практики. У тебя наверное просто чутье и большая удача, что ты на подобные ситуации не нарывался.
Чем их создавать? Подскажи, если такой эрудит.
Понятия не имею - мне пока такое не требовалось.
У тебя наверное просто чутье
Аха, с генами я его получил - от родителей, которые только в последней трети своей жизни компьютеры увидели. У меня.
большая удача, что ты на подобные ситуации не нарывался
Да да да, давай - вали всё на удачу других и неудачу у себя.
Или может всё таки - начать прикладывать (свом!) усилия для достижения (своей!) цели? Не, не слышал о таком, тебе всё готовое надо. Даже сейчас этого
Подскажи
захотел.
- - - Добавлено - - -
нерешаемых проблем из моей практики
А других они как-то решались. Магия и чудеса, не иначе.
- - - Добавлено - - -
Но есть ещё вариант. Не твое это. Оставь его в покое ;)
Но есть ещё вариант. Не твое это
почему не мое? Когда я начинал в 80-е на 8080 все у меня отлично получалось.
Получается местами и сейчас... только "раньше были времена, а теперь мгновенья" Готовое если есть и доступно, то зачем "изобретать велосипед"?
зачем "изобретать велосипед"?
Вот поэтому и
Получается местами
но до тебя никак не дойдёт, почему это взаимосвязанно и вот поэтому теперь это не твоё.
Это никак не взаимосвязано. "Ищите - да обрящете! Хотите - и дастся вам!" У меня просто нет столько оставшегося времени как в 20 лет и в 30 лет, поэтому каждый свободный час стократ мне ценен!
В общем с sdcc применительно к Atari TC пусть сам разбирается, если захочет. Пусть хоть исходник правит, чтобы на выходе были исполняемые файлы, пригодные для загрузки.
Применительно же к моим интересам( Hello world для наибольшего разнообразия компьютеров и приставок) готовое решение-"велосипед" в интернет найдено.
https://lugod.org/presentations/cc65-20150921.pdf page 10
вот hello.c
#include <stdio.h>
#include <unistd.h>
int main(void) {
printf("hello world\n");
sleep(2);
return(0);
}
батник к нему
cl65 -t atari hello.c -o hello.xex
pause
hello.xex это исполняемый файл
В эмуляторе Altirra 2.40 грузим его через меню File ->Boot Image и наблюдаем результат.
cl65.exe часть пакета инструментального софта https://cc65.github.io
Я, конечно, sdcc щупал последний раз давно, но глючный он был...
Oleg N. Cher
23.01.2024, 04:42
Может SDCC и сейчас глючный, но:
1) есть стабильные старые версии. Одну из таких я юзаю.
2) разработчики активно реагируют на баг-репорты.
3) есть ZSDCC, который развивает команда z88dk. Он несколько отличается от SDCC (по оптимизации - в лучшую сторону)
4) нет ничего идеального. Я лучше возьму живой и развивающийся SDCC, чем мёртвый и застывший IAR C или Hitech C. Но это ИМХО.
Я не говорю, что Zonnon-а можно приспособить в качестве компилятора для 8-биток. Даже не представляю как.Эх, а Zonnon-то подзабросили...
И я не представляю как байт-код .NET транслировать для 8-биток. Пожалуй, с LLVM получится получше.
Он "Ada-inspired", то есть вдохновлённый Адой, но со своим велосипедным синтаксисом.Ну так-то да...
- - - Добавлено - - -
Что получаем - непрерывные вопросы - а как это сделать, а как это работает, а вот кто мне сделает - а на предложение - ну почитый ты соответствующую документацию (благо сейчас она есть) - я попробовал, ни хрена не понял (а ещё и доки на английском) и поэтому не буду тратить на это время, мне это не интересно, я хочу игрушку написать.Я понял на кого ты, Hunta, намекаешь. Но ты не учёл, что человек может не настолько фанатеть по платформам на одном из вариантов PDP-11, чтобы задрачиваться на такие тонкости, которые даже нигде не описаны. Этим можно было заморачиваться тогда, когда на твоём столе стояла только бэкашка и ничего кроме. Сегодня - подумал, оценил свои силы, взвесил и благополучно забил, переключившись на что-то более интересное. Ведь не только для себя взялся делать, а как бы для этого "сообщества".
- - - Добавлено - - -
Но я, кста, не забил окончательно, а продолжаю помаленьку пилить, хотя и остались кое-какие задротные специфические вопросы, которые надеюсь разрешить потом, если это будет нужно кому-то ещё, кроме меня. Спасает то, что на ЯВУ (проще кодить). Но заморочки, в основном, с масштабированием графики. Маски рисую, растягиваю спрайтики. Но из-за того же ЯВУ и контента в игру поместится несколько меньше, чем хотелось бы. А вести открытую разработку, как Зимин, у меня не получается. К тому же, советы, которые я получил, обычно чуть менее чем полезны.
Вот хотел на Cowgol'е выехать, но нет. А LLVM бэк-энда для PDP-11 нету. А на структурных макросах сами пишите.
Я понял на кого ты, Hunta, намекаешь.
Но я, кста, не забил окончательно
Ни хрена ты не понял
Oleg N. Cher
23.01.2024, 07:53
Тогда обозначай адресатов в свои наездах поконкретнее.
в свои наездах
Кто сказал, что это наезд? Был бы наезд, было бы имя.
А кто чего на свой счёт воспринял - ну молодец, чё, работай над собой.
Oleg N. Cher
23.01.2024, 10:21
А шо, это были абстрактные рассуждения как ты ждал светлой мечты, а пришла грубая реальность и опустила мордой в грязь? Ну поздравляю, ты наконец повзрослел.
как ты ждал светлой мечты, а пришла грубая реальность и опустила мордой в грязь?
И где я об этом писал? Тоже - воспринял на свой счёт. Так что давай, работай над собой.
Oleg N. Cher
23.01.2024, 10:26
Так по реакции же заметно. Так что давай, иди, иди. Тем более, по теме сказать тебе нечего.
Так по реакции же заметно.
Не стоит тебе додумывать за других - не твоё это.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot