Форк SDCC для процессора 8080

[Oleg N. Cher]

Компьютеров на проце К580 было много, но пишу сюда, уже перенесите, где будет более уместно. Спасибо.

Узнал про существование форка SDCC для процессора 8080, проект живой и развивается.

https://hackaday.io/project/166827-targeting-sdcc-to-the-8080https://github.com/kenyapcomau/sdcc-8080
Дальше текст от машинного перевода, сорри.

Таргетинг SDCC на 8080
Написание генератора кода для микропроцессора 8080 для компилятора Small Device C (SDCC)

Кен Яп
Следить за проектом

SDCC официальный репозиторий Subversion
Моя вилка SDCC для 8080

Этот проект был создан 30.07.2009 и последний раз обновлялся 8 дней назад.

ОПИСАНИЕ:
Я пытаюсь написать бэкэнд генератора кода для SDCC для микропроцессора 8080, набор команд которого является подмножеством Z80.
ПОДРОБНОСТИ

Кастинг вокруг существующих свободных компиляторов привел к нескольким кандидатам. Для CP/M или DOS есть Dunfield C, а также Hitech C. Но они требуют старых сред разработки (хотя можно использовать виртуальную машину), а также поддерживают только старые стандарты C. Возможны и другие недостатки, обусловленные ограничениями среды размещения. Поскольку они являются собственностью, их нельзя развивать дальше.

Amsterdam Compiler Kit (ACK) в настоящее время поддерживается David Given и работает. Программное обеспечение довольно неудобно устанавливать, поскольку оно имеет много компонентов. Процесс сборки ужасен, хотя становится лучше благодаря усилиям разработчиков. Кроме того, он принимает более старый стандарт для C, хотя есть усилия, чтобы обновить его. Он использован портами 8080/8085 FUZIX Аланом Коксом. Одним из преимуществ ACK является то, что он также поддерживает несколько других языков, таких как Pascal, если это необходимо.

SDCC является самым современным из кандидатов. Он поддерживает последние стандарты для C и активно поддерживается. На самом деле это был пост Алана Кокса (я предполагаю, что также возглавляет FUZIX) в списке рассылки SDCC, который заставил меня задуматься о взломе SDCC для создания кода 8080. Если бы я мог это сделать, я мог бы развиваться на Linux.

Я бросил все это в своем уме в 2018 году. Все эти факторы пришли мне на ум:

Был ли я в здравом уме, чтобы сделать это? Модуль генератора кода Z80 gen. c составляет около 13 000 строк кода. Хотя мне не пришлось бы переписывать все это с нуля. На самом деле, поскольку 8080 имеет некоторое сходство с Gameboy Z80, я мог бы получить бесплатную поездку на некоторых из этого кода.
Будет ли от этого какая-нибудь польза? Очень немногие люди имеют только 8080 или 8085 в эти дни. Если они разрабатываются для ретро-процессоров, скорее всего, это будет Z80 или его более быстрые и более способные потомки, для которых SDCC отлично работает. Мало кто заботится о 8080 больше. В худшем случае, только я.
Какие шаги я должен предпринять?
Как оказалось, некоторые шаги я делал довольно быстро, а для других у меня были длинные паузы. Он еще не используется, и есть вероятность, что его никогда не будет. Я мучился, если я должен опубликовать это как проект. В конце концов я решил представить все как есть. Оно:

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

[svofski]

Я настроен пессимистично, но все равно спасибо ;)

[Oleg N. Cher]

А я настроен оптимистично и всячески призываю заинтересованных энтузиастов поучаствовать. Попробуйте хотя бы собрать и погонять. Я сделал пост в надежде, что может ещё кто-то заинтересуется. Люди не любят продолжать чьи-то проекты, лучше с нуля что-то запилят. Это ошибка, я считаю. В какой-то мере даже гордыня.

Тут есть остов — просто надо научиться его собирать. Там вряд ли это сложно. Потом смотреть чего он умеет. И уже лезть править, когда понял как. С автором списаться, наверняка ему не помешает моральная поддержка. Он увидит, что его работа интересна ещё кому-то.

Так что вместо ковыряния старых компилей я бы посоветовал все силы бросить на этот форк SDCC для 8080. Это очень важно, что его можно развивать. Тем более, какая-то работа уже проделана.

Мы с Какосом, в любом случае, будем посмотреть.

[L Juriy]

Попробовал собрать и облом. Не хватает какой-то графики ???? Пока отложил.

[Oleg N. Cher]

Я пока не пробовал. Может не хватает каких-то файлов из официальных исходников SDCC?

В самом крайнем случае попинаем автора Ken Yap.

Кстати, он живой, мне сегодня ответил на гитхабе:

https://github.com/kenyapcomau/sdcc-8080/commit/78b05ff8200e68493d30274c141e0759dfabcd60

[svofski]

Иметь настоящий компилятор настоящего современного Си для 8080 было бы очень круто. Но зачем? Ценность Си в переносимости. Но любой настоящий из жизни сишный код, 100% которого писано под машины с настоящим процессором и настоящей памятью, а не тем, что у нас тут за это держат, будет собираться в жуткую рыхлятину. Чтобы хотя бы только скомпилировать, приходится весь этот код как-то адаптировать, переделывать, переписывать. Это делает всю работу полностью ручной и сводит на нет главное преимущество Си. Руками переписывать лучше на что-то, что является для 8080 более родным. Увы, таких языков как бы и нет. Вот эту нишу было бы заполнить более целесообразно.

Но я все равно желаю удачи авторам, по возможности буду рад помочь, а при случае обязательно чего-нибудь скомпилю SDCC-8080 для Вектора.

[Oleg N. Cher]

Есть язык, очень хорошо адаптированный для 8080. Это PL/M, о котором была статья Какоса Ноноса. Действительно древний, ещё писанный на Фортране, компилер генерит код, намного более оптимальный, чем практически любой компилер Си для 8080. Но - за счёт того, что там нет рекурсии, вычислений со знаком и т.п.

Си же для 8080 нам интересен, как и сам проц 8080, вследствие какой-то привязки нас к этому ретро. :-)

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

А Sphinx C-- для 8080, как и для Z80 никто адаптировать не торопится. А это было бы ещё круче, чем PL/M.

[svofski]

А сохранилась правильная версия PL/M, пригодная для сборки CP/M? Я помню, что что-то там не сохранилось, но признаюсь, за темой внимательно не слежу.

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

[L Juriy]

svofski,
Вот для СР/М и непонятки. Я ПОКА не нашел модуля работающего под СР/М. Есть от СМ1800 но он под СР/М плохо работает.
Самый нормальный оказался под ISIS II, работает без проблем.
Для кросс компиляции можно использовать портированный на С модуль из ISIS II. Его можно найти в intel80tools (https://github.com/ogdenpm/intel80tools).
Там же находятся исходники на PL/M почти на весь ISIS II, в том числе и PLM80 версии 4.0.
Наверное можно собрать и под СР/М, я не пробовал.
Кстати где-то видел исходник СР/М на PL/M , а не на asm.

[svofski]

L Juriy, я не имел ввиду для запуска из-под, а для сборки CP/M. Просто любопытно иметь полный комплект компилятор + сорцы CP/M, как sanity checking device и как справочник. Откуда и чем запускать сам компилятор мне не так важно. Но если там прямо вот есть на си переписанный компилятор, это круто.

[L Juriy]

svofski,
Там самая интересная папка это C-port.

[Oleg N. Cher]

А сохранилась правильная версия PL/M, пригодная для сборки CP/M?Я не в курсе. Я больше про компилер на Фортране, который Какос смог адаптировать для Windows через транслятор Фортрана в Си. Вот то - хороший компилер PL/M. Но можно ли собрать с его помощью CP/M - не знаю. Пробуйте. В любом случае, компилер в исходниках, можно подправить.


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

[L Juriy]

Ну вроде собрал компилятор, нужно попробовать что-то скомпилить.
Первое попавшее выдает много ошибок. Попробую подсунуть, что проглотил Dunfild C.

[andrews]

Выложите бинарник на обозрение, пожалуйста, а то все исходники в Digital Mars C/C++ перелопачивать пока нет решимости.

[Oleg N. Cher]

Зачем в Digital Mars C/C++? Он изначально собирается, насколько я понимаю, в GCC и MinGW.

Есть ли желающие общаться на темы PL/M и компов на проце 8080 в Телеграм-группе? (опрос: есть ли смысл в ней?)

[L Juriy]

Я собираю под Debiab 8, и работаю в основном под ней.
Из Форточек строит WinXP, но пользуюсь редко.
Тем более что пошли программы скомпилированные под VS2017, а они уже не работают под WinXP,
так как скомпилированы без ключа совместимости с ХР. Новая версию minGW уже не запускается.
Вопрос к модераторам, может пора создать в "Отечественных компьтерах" раздел "Программирование".

[andrews]

Зачем в Digital Mars C/C++? Он изначально собирается, насколько я понимаю, в GCC и MinGW.

Есть ли желающие общаться на темы PL/M и компов на проце 8080 в Телеграм-группе? (опрос: есть ли смысл в ней?) так сложилось(сначала в телефонной компании, где я работал в 2002-м это был основной компилятор, так как сама цифровая станция была на 3086EX и рабочий проект был на DMC+MASM), что я все сишные проекты туда перетягиваю. А сейчас вот мне плату на 8085 подогнали, хотелось бы под него допилить. Да, в идеале и с PL/M, и c RMX, и с дебагером для многозадачной среды. На всех работах более 12, где довелось быть, Linux использовали только однажды,на Светлане МЭ. Дома держал раздел на диске одно время, но сейчас времени на все не хватает( в семье младенец появился). GCC и MinGW конечно стоят на компе.

[Oleg N. Cher]

Тем более что пошли программы скомпилированные под VS2017, а они уже не работают под WinXP,
так как скомпилированы без ключа совместимости с ХР.Да. Даже у z88dk была подобная проблема, но исправили.


так сложилосьНу, надо просто прикинуть, стоит ли SDCC-8080 того, чтобы делать кропотливую и сложную работу по его адаптации к Digital Mars C. Другое дело - сконвертированный из Фортрана исходник компилятора PL/M припилить, это полегче.

P.S. Ну так что - нет желающих общаться в Телеграме? Я могу конечно пригласить в группу по ZXDev, но мы там больше про Спектрум.

[andrews]

Да. Даже у z88dk была подобная проблема, но исправили.

Ну, надо просто прикинуть, стоит ли SDCC-8080 того, чтобы делать кропотливую и сложную работу по его адаптации к Digital Mars C. Другое дело - сконвертированный из Фортрана исходник компилятора PL/M припилить, это полегче.
ну а если принять, что DMC данность и весь проект будет на нем? Какие еще есть исходники С?
SMALL C это 70-е если не ошибаюсь. Ассемблер там не помню какой. По поводу исходников PL/M на Fortran-e пытался ковыряться, мрак! А конвертер Fortran to C, то опять какой? GCC?

[Oleg N. Cher]

ну а если принять, что DMC данность и весь проект будет на нем?Ну хорошо. А кто будет вести проект SDCC-8080 на DMC? Если Вы, тогда конечно. А если Ken Yap, то вряд ли он захочет использовать DMC.


По поводу исходников PL/M на Fortran-e пытался ковыряться, мрак! А конвертер Fortran to C, то опять какой? GCC?Не GCC. Там юзается AT&T Fortran-to-C converter.

Я сегодня нашёл компилятор PL/M версии 4.1, сконвертированный в Си. А тот, который на Фортране - это PL/M версии 2.


plm80/*.* this is an old port of plm80 v4.1 to C++. It was written
before I had completed the decompilation of plm80. Also I use
a number of kludges to map address variables, some of which I
would do differently in a future version.
Note it currently maps isis drives differently from the other
tools. Note the 10-Dec-2017 comment above.

plm80c/*.* this is a newer port of plm80 v4.1 to C. This is the one I am
adding commentary to as I understand the compiler internals.

https://github.com/ogdenpm/intel80tools
https://github.com/ogdenpm/intel80tools/tree/master/c-ports/plm80

Это свежак, кстати

В 2018 году Марк Огден декомпилировал ISIS и инструменты PL/M на PL/M и преобразовал в программы на Си. - Херб Джонсон
http://retrotechnology.net/dri/dri_plm.html


В июне 2018 года я спросил Марка Огдена о работе PLM 1800. Он сказал, что знаком с недавно восстановленным программным обеспечением и обнаружил много общего между PLM 1800 и PL / M 8080. Марк проделал большую работу по воссозданию 8-битной и 16-битной операционной системы и кода ассемблера. Вот ссылка на его сайт github о некоторых его работах. В частности, он декомпилировал ISIS (Intel 8080 OS) и его компилятор plm80 в исходники C. - Херб Джонсон
http://retrotechnology.net/dri/plm1800_review.html


Самым старым PLM является кросс-компилятор, написанный на FORTRAN, который работает в 2 прохода (PLM81 и PLM82), создавая шестнадцатеричный вывод. Качество кода довольно хорошее. Я увеличил размеры буфера и перевел код на C. Он отлично работает.

Затем существуют (как минимум) 2 версии собственного компилятора (PLM80), 3.3 и 4.0, которые работают под управлением ISIS, операционной системы Intel MDS. Марк Огден перевел двоичный файл на C.

У меня был некоторый успех с использованием препроцессора C с обоими вышеупомянутыми компиляторами PLM с преимуществом расширения языка с помощью MACRO, условной компиляции, включаемых файлов. В частности, я могу сделать один и тот же исходный код компилировать со всеми из них. :)

Есть также компиляторы PLM для 8051, 8096, 8086, 80186, 80386.

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

PLM не такой мощный язык, как C. Тем не менее, сгенерированный код часто намного эффективнее, потому что C не очень хорошо компилируется в архитектуру, в которой отсутствует 16-битная индексированная адресация (для локальных переменных и аргументов функций). Я переписал CCP в PLM, добавив множество новых команд и все еще оставаясь в пределах 2 КБ, наложенных исходной архитектурой.

Да, когда я был молодым (помните Kernighan & Ritchie?), Я читал бесчисленные статьи, объясняющие, насколько ужасным был код, сгенерированный компиляторами C, особенно на Z-80. Удивительно (но логично) видеть, насколько привязаны к данному оборудованию некоторые системные языки (например, C). Но, конечно, новички, знающие только C, не могут этого понять, поскольку у них нет опыта.

C - отличный язык, но он просто не подходит для некоторых видов оборудования, например, для старых 8-битных процессоров. Есть 2 основные проблемы. Во-первых, выражения C переводятся в размер слова / указателя, который на 8080 равен 16 битам. Очевидно, это не очень эффективно. Во-вторых, как я уже говорил, локальные переменные динамически размещаются в стеке, но нет инструкций, обеспечивающих поддержку размера слова для такого доступа. Предположим, вы хотите передать адрес локального буфера в подпрограмму C на Z80. Самый маленький код (8 байт), который вы можете сделать: -
PUSH IX; Базовый указатель
POP HL
LD BC, буфер
ADD HL, BC; HL: = IX + буфер
PUSH HL

В отличие от более современного EZ80 допускается: -
PEA (IX + буфер)

P.S. Видимо, заниматься PL/M будет всё-таки больше Какос, а я только в роли консультанта. Хватит с меня и Оберона.

[andrews]

Я имел опыт программирования на PL/M80, но когда пытался делать проекты на PL/M51, то качество его генерации кода было настолько отвратительным, что пришлось согласится с коллегами и перейти на ассемблер. C очень сложно заставить оптимально использовать регистры какой-либо архитектуры, впрочем как и PL/M. Вероятнее всего такой язык и/или компилятор до сих пор не созданы. Так как при генерации кода он должен быть не двухпроходным, а многопроходным. Уровни оптимизации у PL/M задаются, но они не наглядны. Для 8080, не говоря уже о z80 есть множество трюков по оптимизации кода при "ручном программировании" на ассемблере, которые недоступны неинтеллектуальным С и PL/M. В годы их создания это могло быть обосновано ограничениями ресурсов инструментальных систем, на которых они выполнялись. Ныне же, когда они работают на мощнейших процессорах с огромной доступной памятью такая неинтеллектуальность ничем не оправдана. Требования "переносимости кода" тоже не совсем актуальны. Когда для 8 битного ретрокомпьютера меняются параметры "процессор" и "машина исполнения", то гораздо более интересна автоматизация по подмене библиотек и выдача предупреждении об отсутствии нужных ресурсов, то есть мощные внутренние библиотеки компилятора, поддерживающие различное "железо". С учетом расширения таких возможностей это интересное занятие.

[Oleg N. Cher]

Совершенно справедливо, andrews. Я именно с подобным прицелом создавал ZXDev для программирования под Спектрум, чтобы наработать машинные библиотеки, а ЯВУ там в качестве клея. С учётом развивающейся в SDCC оптимизации проект выглядит весьма в этом духе, что Вы описали. Кстати, “старослужащие” программисты ZXDev особо не заинтересовались, но мой опыт показал, что идея была правильная — юные спектрумисты осваивают его очень легко и выходят на инструментарий уровня получше ZX-Бейсика без кропотливого изучения асма.

При некоторой сноровке и наличии библиотек на PL/M (для 8080) писать быстрее, чем на асме, да и код нагляднее. Для этого он и был придуман. В то же время, язык не настолько оторван от архитектуры проца 8080, как Си. Кстати про библиотеки тоже есть открытые вопросы. Вроде бы там умная линковка не предусмотрена, только механизм типа инклюдов. То есть, с библиотеками не поработаешь. А это плохо (Какос, опровергни, если я не прав?)

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

Что же касаемо PL/M (plmx версии 2, который на Фортране). Какос сравнивал скорость работы алгоритма, вычисляющего простые числа до 255 на BDS C и этом PL/M.

BDS C = ~ 15 сек (на эмуляторе компьютера Апогей БК-01)
PL/M = ~ 10 сек (на эмуляторе компьютера Апогей БК-01)

Оберон в ZXDev (через SDCC, на эмуляторе Спектрума) = ~ 3 сек

Разумеется, Какос смотрел и в код, сказал, что PL/M его генерит намного оптимальнее, чем BDS C. Дополню от себя: чем любой из имеющихся компиляторов Си для 8080, что под CP/M, что кросс). Я не оптимист в плане появления новых высокооптимизированных компиляторов для проца 8080 в наше время, так что остаётся пользоваться тем, что есть. И в этом свете конечно появление форка SDCC-8080 интересный феномен. А PL/M 4.1 может иметь даже более серьёзную оптимизацию, чем PL/M 2. Нужно вникнуть и разобраться.

[Oleg N. Cher]

Получил сегодня ответ от Кена Япа:


Мне жаль, если у вас сложилось впечатление, что бэкэнд работает. Он даже не собирается полностью. Есть три области, которые должны быть закончены, прежде чем что-либо может быть выпущено.

1.

Генератор кода должен быть изменен для вызова процедур сдвига вправо.
2.

Много кода Z80 в библиотеке времени выполнения должны быть преобразованы в код 8080.
3.

Сборка должна пройти обширный набор тестов.

Это может занять у меня месяцы или больше, чтобы сделать. Вы можете следить за журналами по адресу hackaday.io за прогресс.

С уважением

https://github.com/kenyapcomau/sdcc-8080/issues/1

[L Juriy]

Хотел написать свои заметки, но прочитав данное сообщение все понял.
У меня собрался. но библиотеки времени выполнения нету.
ЕЕ нужно все переписывать, так как в z80 используются регистры IX и IY и просто так тот код не подсунещь.
Самый быстрый способ ее перелопатить, использовать другой компилятор С для кода 8080 и исходные программы на Си полученый код использовать.
У кого есть нормальная программа преобразования исходного кода z80 - I80? Давно ищу.

[andrews]

Хотел написать свои заметки, но прочитав данное сообщение все понял.
У меня собрался. но библиотеки времени выполнения нету.
ЕЕ нужно все переписывать, так как в z80 используются регистры IX и IY и просто так тот код не подсунещь.
Самый быстрый способ ее перелопатить, использовать другой компилятор С для кода 8080 и исходные программы на Си полученый код использовать.
У кого есть нормальная программа преобразования исходного кода z80 - I80? Давно ищу.вряд ли такая программа будет ВСЕМ нравится. i8080 to z80 это пожалуйста, а так режим с автоматизацией лучше не пускать и симулятор z80 на 8080 не делать. Максимум, что возможно это предлагать пользователю перед началом работы определить память для отображения расширенных по отношению к 8080 регистров z80 и определить процедуры для выполнения отсутствующих в инструкциях 8080 инструкций z80. В том числе, если в исходнике для z80 или hex(obj) коде есть недокументированные инструкции, и для них тоже определить.

[Oleg N. Cher]

Мы с Какосом основали группу Язык PL/M и старые компы на К580/i8080 (https://t.me/plm8080) для обсуждения этого направления разработки. Прошу желающих присоединяться.

Что нам удалось: собрать при помощи MinGW утилиты - компилятор PL/M 4.0, ассемблер, линкер. Планируем выложить эти наработки в репозиторий. Собрать им "Hello World" для Апогея БК-01.


MY:
DO;
PUTCH: PROCEDURE(A) EXTERNAL;
DECLARE A BYTE;
END;

DECLARE S ADDRESS;
DECLARE (C BASED S) BYTE;
S=.('HELLO PLM',0,0);
DO WHILE C<>0;
CALL PUTCH(C);
S=S+1;
END;
DO WHILE 1=1;
END;
END;

PUBLIC PUTCH
CSEG
PUTCH:
JMP 0F809H

END

70051

[L Juriy]

Oleg N. Cher,
Ссылка не рабочая Problem loading page.

[Kakos_nonos]

Да, разрабатывем pl/m систему, для программирования под компьютеры ч процессрор i8080. Качество кода вполне себе "на уровне", в отличии от BDS C, я уже делал подобную систему и игру на ней, это будет вторая версия, более удобная.

[Oleg N. Cher]

Ссылка не рабочая Problem loading page.Эээ... Какая именно? На группу в телеграме?
А у svofski зайти получилось.

[L Juriy]

Oleg N. Cher,
Язык PLM и старые компы.

[Oleg N. Cher]

Туда нужно заходить при помощи Telegram, который должен быть установлен и, как я понимаю, ассоциирован на подобные ссылки. Группа называется @plm8080

В самом крайнем случае пробуйте поиском. Или напишите мне в ЛС свой идент в телеграме, я добавлю.

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

Вот здесь будут наши наработки. Пока там есть все собранные утилиты и HelloWorld для Спектрума.

https://github.com/Oleg-N-Cher/PLM-80

http://i.piccy_.info/i9/9e58fbefc480e879f3988404154c7421/1569302192/64505/1320134/PLM80.jpg


Скажу честно, я разочарован качеством кодогенерации этого PL/M даже на HelloWorld'е. Ожидал большего.

[svofski]

Скажу честно, я разочарован качеством кодогенерации этого PL/M даже на HelloWorld'е. Ожидал большего.
Интересно бы было взглянуть на пример кода. Может листинги в gist, или pastebin?

Кстати, для Вектора еще есть ЛС-Паскаль (http://sensi.org/scalar/ware/97/). Кассетный.

[s_kosorev]

Туда нужно заходить при помощи Telegram, который должен быть установлен и, как я понимаю, ассоциирован на подобные ссылки. Группа называется @plm8080
У них блокируют Telegram

[Error404]

Предлагаю все что относится к Pl/M отцепить в отдельную тему.

[ivagor]

Извините за оффтоп.

Кстати, для Вектора еще есть ЛС-Паскаль. Кассетный.
Tim0xA даже умудрился написать на нем коммерческую (по векторовским меркам) игру (http://www.sensi.org/scalar/ware/414/).

[L Juriy]

Error404,
А может тему Программирование а в ней разделы если нужно.

[Kakos_nonos]

Вот исходник на plm/


MY:
DO;
PUTCH: PROCEDURE(A) EXTERNAL;
DECLARE A BYTE;
END;

DECLARE (S,F) ADDRESS;
DECLARE (C BASED S) byte;
S=.('HELLO PLM',0,0);
DO WHILE C<>0;
CALL PUTCH(C);
S=S+1;
END;
DO WHILE 1=1;
END;
END;


А вот выходной асм



org 00000H
.text HELLO PLM
.db 0,0
lxi sp,X00A1
lxi h,00000H
shld X00A1
L0014:
lhld X00A1
mov a,m
cpi 000H
jz L002E
lhld X00A1
mov c,m
call L003A
lhld X00A1
inx h
shld X00A1
jmp L0014
;
L002E:
mvi a,001H
cpi 001H
jnz L0038
jmp L002E
;
L0038:
ei
hlt
L003A:
jmp LF809

[KTSerg]

Вот исходник на plm/
...
А вот выходной асм
...
А где в самом начале JMP для перепыгивания через текст "HELLO PLM" ???
Или эти символы представляют из себя скрытый код который должен исполняться перед началом программы?

[ivagor]

Можно предположить, что точка входа в программу не с 0000 а с команды lxi sp,X00A1

[Kakos_nonos]

Это баг, который мы уже решили, да в этом случее проц проходится по HELLO PLM.

[KTSerg]

Можно предположить, что точка входа в программу не с 0000 а с команды lxi sp,X00A1
Не, не катит. Стек определяется без отдельной метки, сразу после db 0,0.

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


Это баг, который мы уже решили, да в этом случее проц проходится по HELLO PLM.
Ясно.
В средине 90-ых, были маленькие антивирусные программы которые затачивались под конкретный вирус. Один из таких "антивирусов" делал вид, что "лечил зараженные файлы" вырезая из них текст "MS DOS" (это я потом понял, когда решил сравнить файл до и после "лечения").
По идее текст тоже может содержать код.

[ivagor]

Не, не катит. Стек определяется без отдельной метки, сразу после db 0,0.
С одной стороны да, с другой - исходник не полный, т.к. там нет определений для X00A1, LF809 и в дополнительных определениях может быть что угодно, например точка входа как L0014-9 (тем более процедура запуска тоже может быть какой-угодно). Но признаю, что версия с некорректной компиляцией была самая простая, а я про нее не подумал.

[Kakos_nonos]

X00A1 это за концом программы, пустое место дя стека, а lf809 это команда монитора рк86 для вывода символа

[svofski]

По-моему что написали, то он и скомпилировал. А что вы ждали, какой код не разочаровал бы?

Чисто эмоционально я вот не могу сказать, что хотел бы каждый день смотреть на PL/M. То есть если цель обрести сборку сорцов CP/M + способный их собрать SDK — это большая польза, потому что можно вносить какие-то изменения в CP/M. А если просто получить ЯВУ для программирования Векторов, Апогеев и Океанов, то че-то не хоцца. На всякий раз уточно, что это я не пытаюсь критиковать благородные усилия Kakos_nonos и Oleg N. Cher. Просто мое сугубо личное мнение об этом языке.

[Kakos_nonos]

По началу тоже он мне не нравился, но спусля некоторое время кодинга вполне себе привык. Конечно, было бы удобнее программировать на паскале или си, но вариантов, сравнимых с качеством генерации кода как у pl/m я не нашел. Если что знаете, то буду рад попробовать.

[ivagor]

Если нацеливаться не на портирование исходников откуда-то на 8080, а больше на написание новых программ, то с8080 (https://github.com/alemorf/retro/tree/master/c8080) alemorfa/vinxru выглядит интересным вариантом. Признаюсь, что я пробовал не вариант из githubа, а более ранний, но мне и тот вариант уже казался довольно неплохим.

[Kakos_nonos]

Да, этот вариант был бы лучшие, но, он, к сожалению еще не дописан, многие функции еще не реализованы, смотрел его.

[Oleg N. Cher]

По-моему что написали, то он и скомпилировал. А что вы ждали, какой код не разочаровал бы?Ну, во-первых, не понравилось, что он не понял в compile-time, что 1=1 всегда TRUE, а проверяет это в runtime. Нехорошо. Во-вторых, сравнение с нулём через cpi 0, а не ora. В третьих, можно было не читать из переменной, раз там уже нужное значение.


Просто мое сугубо личное мнение об этом языке.Я присоединяюсь.

[Oleg N. Cher]

с8080 (https://github.com/alemorf/retro/tree/master/c8080) alemorfa/vinxru выглядит интересным вариантом.При всём моём большом уважении к Алексею Морозову - программировать при помощи недоделанного компилятора без исходников - ещё та засада. Можно запросто упереться в нерешаемую проблему. Лучше уж PL/M.

Кстати, если изменить WHILE 1=1 на WHILE 1, он делает джамп, зацикленный сам на себя. Просто нету свёртки констант. Приспособиться наверно можно, а можно и кодогенерацию подшаманить, особенно если это буду делать не я. ;-)

[andrews]

При всём моём большом уважении к Алексею Морозову - программировать при помощи недоделанного компилятора без исходников - ещё та засада. Можно запросто упереться в нерешаемую проблему. Лучше уж PL/M.

Кстати, если изменить WHILE 1=1 на WHILE 1, он делает джамп, зацикленный сам на себя. Просто нету свёртки констант. Приспособиться наверно можно, а можно и кодогенерацию подшаманить, особенно если это буду делать не я. ;-)

а также для организации бесконечных циклов, в том числе задач в многозадачных системах WHILE 1 c DO; ...END; с помощью LITERALLY можно переопределить DO на {, а END на } Вообще, если его немного доработать по типам данных и макро, вполне себе юзабельный язык, особенно для кросс-компиляторов. А вот исходники PL/M-86 у кого-то есть? Здесь только доки (http://www.bitsavers.org/pdf/intel/ISIS_II/) и образы дисков