Мощная среда ZXDev для разработки НА ПЯТИ ЯЗЫКАХ для ZX готова к тестированию

[Shiny]

Было бы интересно взглянуть на plm80. Из доступных есть plmx, но он гонит код под 8080, исходники готовы.

[Oleg N. Cher]

Да много есть интересного. И пакет Tramplin для разработки для PC в мнемониках Z80. И язык Metal Владимира Кладова. И мой язык COLOSS. И многочисленные Forth'ы. И мини-Си от Raydac & Michailov [HVG]. И Mira Modula-2. Что до PL/M, то я ни одного не щупал, читал только доки. Должно быть интересно. PL/M видится как прокачанный некоторыми высокоуровневыми конструкциями асм, чем-то напоминающий и COLOSS, и Metal. Сделать бы продуманный синтез всех этих вещей. Но я пас. Буду доделывать свои порты игр на Обероне. Может когда-нить вам покажу.

Oleg N. Cher, а может сделаете порт игры digger на обероне?

Я уже делаю 3 порта, и они не закончены. В разной стадии готовности. Ещё два в задумках. Хочется сделать. Пожалуй, за Digger не возьмусь.

Да, с асмом Оберону не тягаться. В своей нише асм не подвинется никакому другому языку.

P.S. Если есть желающие писать статью в журнал Downgrade про ZXDev, советую сделать так. Написать на ZXDev небольшую игру, подробно со скринами и листингами описывая все шаги её разработки. Потом, возможно, перенести её на другую платформу. Можно и не переносить, просто заложить предпосылки для этого. Практически все игры, которые мне попадались для ZX, для портирования годятся слабо. То есть годятся, но чёртова уйма работы это. А интерес в том, чтобы облегчить этот процесс.

[dosikus]

Oleg N. Cher, упс а можно кинуть ссылкой?
Я предполагал что ты вменяемый. Но прибежище именно на форуме оберона этой своры, сильно озадачивало. Недавно , не без моего участия, их турнули и с изиэлектроникс.

[AlexG]

а можно популярно: за что их (я так понимаю "любителей" дракона) не "любят" или всё таки "любят"?

[Oleg N. Cher]

Oleg N. Cher, упс а можно кинуть ссылкой?

Ссылкой на что? :-) Раньше на OberonCore был раздел, посвящённый Drakon'у. Он к Оберону имел отношение постольку, поскольку есть генераторы Дракон-схем в Оберон. Или как-то так. Я не вникал. Но вроде как они выбрались на свой личный форум, размещённый на их сайте.

а можно популярно: за что их (я так понимаю "любителей" дракона) не "любят" или всё таки "любят"?

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

Впрочем, "секта" - это громко сказано. С тем же успехом и мы, спектрумисты и олд-геймеры, железячники и ретрокодеры, тоже секта ;-) Если о самом Драконе, это просто блок-схемы. Вы их много раз видели в старых книжках по алгоритмированию.

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

сразу будет понятно, насколько удобен и вообще хорошо этот язык. пока в общих чертах - си сильно рульнее оберона (это если откинуть чисто асм).

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

О преимуществах от переписывания Digger'а с Си на Оберон для Z80-based платформ(ы).

Оберон не даёт никаких преимуществ перед Си при использовании встроенного ассемблера.
В Обероне нет беззнаковых типов. В Си, Модуле-2 и Boriel ZX Basic'е они есть.
Битовые операции на Обероне записывать не так удобно, как на Си. Выглядят громоздче.
Краткосрочных перспектив нет. Посему команда разработки Digger'а в целом поступила верно, выбрав путь переписывания с Си на Си.

Если переписать Digger на Оберон, а потом оттранслировать его обратно в Си, то будет результат, пестрящий, как и Си-вариант, встроенным ассемблером, без беззнаковых типов и т.п. Где тут преимущества?

Идём дальше. Начинаем думать, были бы ли преимущества от того, если бы Digger был написан на Обероне с самого начала? А только потом его переписывали бы на Си. Или странслировали в Си или Java. Вероятно, да, преимущества бы были. И именно оттого, что Оберон диктует стиль чёткого разделения на системно-зависимые и независимые, опасные и безопасные вещи, тем проще обозревать большие объёмы кода. Если модуль X не использует модуль SYSTEM, а это видно в секции IMPORT в начале модуля, то это хорошие шансы предположить, что он никогда не вылетит в чёрный экран с неизвестной ошибкой.

Хидеры Си пишутся вручную. Интерфейсы Оберона генерируются автоматически. Конечно это слабое преимущество, но когда работаешь с Обероном, понимаешь, что так и должно быть. Это удобно.

О долговременных перспективах

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

В свете рождения, жизни и отмирания платформ (довольно быстрого, как мы видим) очень трудно предсказать какие же технологии (программные и аппаратные) возобладают, скажем, через 25 лет. В свете этого хочется иметь исходник Digger'а в таком виде, который бы максимально был готов к переменам. Оберон к таким переменам готов. Его легко переориентировать даже силами одного энтузиаста. Если понадобится. Ну просто чтобы потом не переписывать Digger на другой язык снова (вдруг там даже Си не будет?).

Из-за простоты Оберона, его чёткости и однозначности, эти черты странным образом перетекают в проекты, которые делаются на этом языке. Дело тут не только в "преимуществе := над =" или "WHILE над while()", просто чувствуется хорошая вылизанность, до блеска. Оберон блестит. Не буду говорить за всех, у меня тоже ночи потеряны бдениями в отладчике, но на Обероне почему-то необходимость в этом очень сильно ниже.

Возможно, будет продолжение.

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

Да, о преимуществах Оберона перед Паскалем. Если в плане наличия хороших мультитаргетных компиляторов и силищи библиотек, то преимуществ нет - Free Pascal на плечах Delphi вне конкуренции. Я видел, на нём даже для Android можно разрабатывать. Хотя конечно далеко не так удобно, как на Java.

[Alcoholics Anonymous]

вот если честно, sdcc сам по себе не плох. но меня, лично меня, просто выворачивает от того, что стоковая его libc собрана на 99% из кода на си. кода на асме там с гулькин нос. а у хайтеха хотя бы примерно 50на50 или больше в сторону асма. Посмотри на z88dk, там половина библиотеки его это копипасте из библиотеки хайтеха.

Z88DK ближе к GCC, чем к HITECH-C

Скрытый текст

Z88DK is closer to GCC than it is to HITECH-C

[свернуть]

Впрочем, Alcoholics Anonymous писал, что у z88dk библиотеки, напротив, чисто ассемблерные. И их можно использовать из zsdcc.

Да, более 1000 функций, написанных на языке ассемблера и с целью соблюдения большого подмножества C11. То есть в десять раз больше, чем HITECH. Она написана с нуля - это не копируется из любого места. HITECH-C и другие составители Z80 имеют слишком ограниченные библиотеки для правильной реализации стандарта C. Они только пытаются осуществить то, что называется unhosted часть стандарта, а затем добавить несколько битов здесь и там. HITECH-C добавляет файл ввода / вывода, обеспечивая тонкий интерфейс над BDOS в CP / M. Он не в состоянии делать файл ввода / вывода на общем компьютере Z80. Возможно, вы видели, ф / м заголовков, заимствованные из HITECH в классической библиотеке Z88DK, но это только для реализации CP / M интерфейс таким образом, который ожидается CP пользователей / M.

Вы можете посмотреть на исходный код и сравнить; Открыто.

Базовый каталог источник находится здесь:
https://github.com/z88dk/z88dk/tree/...c/_DEVELOPMENT

Файлы заголовков здесь:
https://github.com/z88dk/z88dk/tree/...VELOPMENT/sdcc

Например, чтобы посмотреть на реализацию string.h смотрите в каталог строку / Z80.

Sayman упоминается PRINTF. Реализация Z88DK составляет 100% ассемблере, но есть что-то особенное об этом. Вы можете отказаться от% преобразователей в индивидуальном порядке. Если вы решите, что вам нужно только% S, вы можете попросить только% s в вашей двоичной системе. Это может уменьшить размер реализации совсем немного для небольших программ. Другая вещь модель STDIO Z88DK представляет собой модель UNIX, которая позволяет любому устройству чтения или записи с PRINTF и Scanf (а функции POSIX read,write и т.д.). Это полная реализация в отличие от всех других компиляторов Z80 C и является портативным к любому компьютеру Z80.

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

Скрытый текст

Yes, more than 1000 functions written in assembly language and aiming to comply with a large subset of C11. That is ten times larger than HITECH. It is written from scratch -- it is not copied from anywhere. HITECH-C and other Z80 compilers have too limited libraries to properly implement the C standard. They only attempt to implement what is called the unhosted portion of the standard and then add a few bits here and there. HITECH-C adds file i/o by providing a thin interface over BDOS in CP/M. It is incapable of doing file i/o on a generic Z80 computer. It is possible you saw cp/m headers borrowed from HITECH in Z88DK's classic library but that is only to implement the CP/M interface in a way that is expected by CP/M users.

You are welcome to look at the source code and compare; it's open.

The base source directory is here:
https://github.com/z88dk/z88dk/tree/...c/_DEVELOPMENT

Header files are here:
https://github.com/z88dk/z88dk/tree/...VELOPMENT/sdcc

For example, to look at the string.h implementation look into the string/z80 directory.

Sayman mentioned PRINTF. Z88DK's implementation is 100% assembler but there is something special about it. You can opt out of % converters individually. If you decide you only need %s, you can ask for only %s in your binary. This can reduce the size of the implementation quite a bit for small programs. The other thing is Z88DK's STDIO model is a UNIX model that allows any device to be read or written with PRINTF and SCANF (and the POSIX functions read, write, etc). This is a complete implementation unlike all other Z80 C compilers and is portable to any Z80 computer.

It is incomplete however as we have not implemented the disk drivers in the new c library yet.

[свернуть]

[Oleg N. Cher]

Здорово было бы для привлечения внимания к разработке игр на ЯВУ (для ZX Spectrum, в первую очередь) организовать конкурс. Оригинальная или портированная игра на одном из языков:

• Boriel's ZX-Basic

• Forth (есть несколько реализаций, но, скорее всего, нужно делать свою, с возможностью смарт-линковки).

• PL/M

• ZX Like Pascal

• Oberon, Oberon-2 (ZXDev)

• C (SDCC, z88dk, Hi-Tech C, IAR C и т.д.)

• Jovial (только где и как достать компилятор? )

• ... что ещё упустил?

Есть интерес? Я, быть может, даже поучаствовал бы (если будут разрешены порты игр). Идеальнее всего конечно бы с призами, но, мы все понимаем, время сейчас непростое, спонсора найти трудно (разве что скинуться понемногу?).

[Shiny]

простите прагматизм, но вряд ли выгорит "Ни ноты без банкноты".
Зачем ЯВУ? без замудреной логики проще все же удобнее применить ассемблер.

[Oleg N. Cher]

Ассемблер уже много где применили))) Оттого и неинтересно.

А кому-то интереснее для Эвы с конфой, УК-НЦ, Апогея или CP/M, мне же - для Спектрума))

[Shiny]

Ассемблер уже много где применили))) Оттого и неинтересно

вот Вам пример: один из участников форума работает над портом аркадных игр. Вряд ли используются ЯВУ. В общем, без Jovial есть поле для простора.