Sphinx C-- для Z80 [Архив] - Speccy

Oleg N. Cher

16.04.2018, 15:49

Гм, оказывается, всплыли исходники Sphinx C-- от Peter Cellik/Michael Shecker. В своё время я очень интересовался этим языком и жалел, что нет версии, генерирующей машкод для Z80. Ведь это будет (для Z80) получше, чем самопальные Паскали, уж простите, если кого-то задел)

https://github.com/jossk/c--sphinx

Цитата из моей статьи в Радиомир. Ваш компьютер «Sphinx C-- — язык не для всех» (http://c--sphinx.narod.ru/doc.htm):

У некоторых “сетевых” людей промелькнула мысль “заточить” C-- для генерации кода Z80, используя парсинг C--: “Насколько это трудоемко? Помню, увидел его в первый раз, это была версия, не умевшая даже PM, но уже с большим набором библиотек, плюс приятный и ясный синтаксис. Первая мысль — так бы на Спектрум! Я не думаю, что перекраивать компилятор придется очень сильно — та же модель tiny очень подходит для Z80, и мнемоники в большей степени похожи. Сорцы брать старых версий, где защищенного режима и win32 нет. Необходимость в таком языке возникла давно — не все ж на ассемблере программировать!”

Но вот что М.Шекер думает по этому поводу: “Теоретически ничего невозможного нет, надо только желание и время. Умножение, деление и другие возможности языка можно эмулировать вызовом соответствующих inline-процедур. Но необходимости я в этом не вижу. Архитектура и возможности Z80 сильно отстали от интеловской линейки. Лучше заняться переписыванием софта Z80 на С-- (там встречаются неплохие идеи и их реализации, но и они могут скоро потерять свою актуальность)”.

Что ж, очень жаль. :-( Но, может, и среди спектрумистов найдется свой Шекер? :-)

Ссылка, откуда я об этом вообще узнал:

http://board.kolibrios.org/viewtopic.php?f=45&t=3237

AzAtom

17.04.2018, 09:36

А чем самопальный паскаль хуже самопального С--?

s_kosorev

17.04.2018, 10:31

Весь исходник пропитан x86, портирование на другую платформу, сопоставимо с создание с нуля

Oleg N. Cher

17.04.2018, 13:21

А чем самопальный паскаль хуже самопального С--?Если делать Паскаль, удобный для эффективной разработки именно для Z80, то нужно его сильно доработать, нарушив имеющиеся каноны и совместимость. Иначе он не будет столь эффективен. Параметры в стеке, локальные переменные в стеке (для реентерабельности и рекурсии) и т.д.

C-- же имеет модель передачи регистровых параметров, явное обращение к регистрам и очень много подобных вещей, и в целом ложится на архитектуру Z80/8080 намного лучше, чем обычный Си. На нём очень легко можно руками описывать разные хитрые оптимизации, приближая тем самым разработку на C-- к разработке на чистом асме.

А исходник мне и самому не понравился, это даже в принципе и не C++. Но кто из нас кодит иначе? ;-)

P.S. Любителям 8080. Если подзаточить для 8080, можно на этом Сфинксе писать для РК-86 и Апогея)

Vasil

17.04.2018, 14:55

Гм, оказывается, всплыли исходники Sphinx C-- от Peter Cellik/Michael Shecker.

Это такая шутка, да? Я еще в 2001-м компилил их, авторские (Peter Cellik).

У некоторых “сетевых” людей промелькнула мысль “заточить” C-- для генерации кода Z80, используя парсинг C--: “Насколько это трудоемко? ....

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

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

А чем самопальный паскаль хуже самопального С--?

Оптимизацией кода, которого в пасе нет (если не использовать одни асмовые вставки).

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

C-- же имеет модель передачи регистровых параметров, явное обращение к регистрам и очень много подобных вещей, и в целом ложится на архитектуру Z80/8080 намного лучше, чем обычный Си.

Да,.... святая наивность. Хочешь, предскажу твоё (у тебя в голове) будущее? Как только дело дойдёт до практических занятий по прикрутки "твоих нынешних восторгов" к z80, то твоя мечтательность рассеется как утренний туман.

P.S. Любителям 8080. Если подзаточить для 8080, можно на этом Сфинксе писать для РК-86 и Апогея)

:) Я бы пока подождал ставить телегу впереди лошади, мечтатели Вы наши :)

AzAtom

17.04.2018, 15:23

Оптимизацией кода, которого в пасе нет
Всегда думал, что оптимизация не в языке, а в компиляторе. Паскалю какая разница, что там накомпилирует компилятор?

Andrew771

17.04.2018, 16:19

Если делать Паскаль, удобный для эффективной разработки именно для Z80, то нужно его сильно доработать, нарушив имеющиеся каноны и совместимость. Иначе он не будет столь эффективен. Параметры в стеке, локальные переменные в стеке (для реентерабельности и рекурсии) и т.д.

C-- же имеет модель передачи регистровых параметров, явное обращение к регистрам и очень много подобных вещей, и в целом ложится на архитектуру Z80/8080 намного лучше, чем обычный Си. На нём очень легко можно руками описывать разные хитрые оптимизации, приближая тем самым разработку на C-- к разработке на чистом асме.

Регистровые оптимизации зависят от количества и возможностей регистров в проце, а не от ЯВУ. На Спеке с количеством регистров беда - полноценные только A и пара HL, с которыми можно что угодно делать, остальные ограниченные. Всё только вокруг них вертится.

Shiny

17.04.2018, 16:32

а чем С-- лучше Hitech C ?

Trol73

17.04.2018, 16:34

Тоже давно хотел иметь компилятор C-- подобного языка для Z80.
После долгих колебаний начал делать свой велосипед для AVR. Цель была не в том, чтобы поддержать весь синтаксис С--, а только те конструкции, которые хорошо ложатся на систему команд. Т.е., хотелось, чтобы при взгляде на код было сразу более-менее понятно, в какие инструкции он будет скомпилирован. И, если какую-то конструкцию не получается скомпилировать в простой компактный код, то она не поддерживается. Сейчас есть поддержка функций с аргументами, условий и циклов. Ну и простая арифметика с регистрами.
Работает это штука как препроцессор кода, создавая на выходе ассемблерный файл.
Проект написана на яве, исходники на гитхабе: https://github.com/trol73/avr-asm-ext
Некоторое незаконченное (и уже устаревшее) описание попытался изобразить: http://trolsoft.ru/soft/avr-asm-ext (там в конце ссылки на пару примеров проектов на языке).
Проект сыроват, но уже вполне рабочий. Писать код стало ощутимо проще (чем на ассемблере), читать - тем более. Скорость выполнения и размер, при этом, ничем не уступают чистому ассемблеру. Качество кода (если он не совсем тривиален) местами получается ощутимо более высоким, чем у GCC, не смотря на все его оптимизации.
Надеюсь довести проект до ума и потом делать форк для Z80.

Oleg N. Cher

17.04.2018, 20:30

Это такая шутка, да? Я еще в 2001-м компилил их, авторские (Peter Cellik).Речь идёт про исходники, доработанные Шекером.

Как только дело дойдёт до практических занятий по прикрутки "твоих нынешних восторгов" к z80, то твоя мечтательность рассеется как утренний туман.Я не собираюсь этим заниматься. Инфу пощу чтобы, может быть, кого-то вдохновить. То есть выполнить роль Инфоркома в далёких 80-х.

Всегда думал, что оптимизация не в языке, а в компиляторе. Паскалю какая разница, что там накомпилирует компилятор?Видишь ли, есть языки, в которых оптимизацию можно тонко описывать руками. Дубовый компилятор, изощрённый программист, хитрый и малопонятный код. К таким языкам я бы отнёс PL/M, ну и конечно C--

В противовес этому — умный и изощрённый компилятор, тупой программист, тупой "в лоб" код.

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

Регистровые оптимизации зависят от количества и возможностей регистров в проце, а не от ЯВУ.Именно от ЯВУ. На одном языке (Sphinx C--) ты можешь описать регистровые оптимизации средствами языка, на другом (Pascal без специальных низкоуровневых расширений) — не можешь. Всё.

а чем С-- лучше Hitech C ?C-- совсем другой язык, несовместимый с Си и более низкоуровневый. Типа PL/M, но на базе Си. Я бы сказал, что на нём можно легко писать демки заместо асма. На Hitech C вряд ли кто-то захочет писать демки (или игры).

Trol73, респект! Оценили — плотность кода выше, чем на асме? Удобнее, больше кода помещается, легче читать и воспринимать. Именно для этого нужны такие над-ассемблеры.

Trol73

18.04.2018, 09:36

Оценили — плотность кода выше, чем на асме? Удобнее, больше кода помещается, легче читать и воспринимать. Именно для этого нужны такие над-ассемблеры.
По плотности кода: одна строка расширенного синтаксиса обычно может заменить от одной до трёх ассемблерных инструкций (а в случае больших if-ов или вызова функций со множеством аргументов - намного больше).
Пара реальных примеров:
1. декомпилированная прошивка контроллера клавиатуры Caro (https://github.com/trol73/avr-86rk-ps2-keyboard-controller): 770 строк чистого ассемблера сократилось до 550 (20кб -> 15кб)
2. прошивка частотомера (https://github.com/trol73/avr-f-meter): 2700 строк сократилось до 2000 (57кб -> 48кб)

Но главное тут, кмк, даже не в количестве строк. Лично меня больше всего убивало писать руками передачу аргументов через регистры при вызове функции - приходилось держать в памяти назначение регистров и скакать туда-сюда по коду - от объявления функции до места её вызова (и при чтении этого кода потом также придётся постоянно переключаться). Сейчас стало гораздо проще и писать и читать код. Под спойлером - функция рисования окружности, теперь она почти умещается на один экран)
https://pp.userapi.com/c841435/v841435972/7d223/MTY9_K8DWMs.jpg

Shiny

18.04.2018, 09:49

C-- совсем другой язык, несовместимый с Си и более низкоуровневый. Типа PL/M, но на базе Си. Я бы сказал, что на нём можно легко писать демки заместо асма

Тогда как вызывать фрагменты ассемблера? музыку, например.

Trol73

18.04.2018, 10:27

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

Shiny

18.04.2018, 10:39

Это уже интересно.

Andrew771

18.04.2018, 16:16

Видишь ли, есть языки, в которых оптимизацию можно тонко описывать руками. Дубовый компилятор, изощрённый программист, хитрый и малопонятный код. К таким языкам я бы отнёс PL/M, ну и конечно C--

В противовес этому — умный и изощрённый компилятор, тупой программист, тупой "в лоб" код.

C-- совсем другой язык, несовместимый с Си и более низкоуровневый. Типа PL/M, но на базе Си. Я бы сказал, что на нём можно легко писать демки заместо асма. На Hitech C вряд ли кто-то захочет писать демки (или игры).

Trol73, респект! Оценили — плотность кода выше, чем на асме? Удобнее, больше кода помещается, легче читать и воспринимать. Именно для этого нужны такие над-ассемблеры.

Тогда С-- и ЯВУ - разные весовые категории. На Спеке ЯВУ для тех, кто не знает, не хочет знать Ассемблер или неохота/нет времени на нем писать. С-- им не поможет. Основные оптимизации в компиляторе не сложно и не долго делать разработчику компилятора без всяких больших коллективов.

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

На Асме кстати тоже быдлокод можно писать, рассказываю как, тут (http://zx-pk.ru/threads/17881-c-chego-nachat-gejmdev-dlya-gorbatysha.html?p=456095#post456095) :)

Trol73

18.04.2018, 16:44

Допустим, кто-то хочет написать для спека что-то более-менее серьёзное. Для этого надо выбрать язык программирования. Если выбрать ассемблер, то есть риск, что проект в какой-то момент станет слишком сложным и неуправляемым (т.е., затраты времени и сил станут неприемлимыми для любительского проекта, который just for fun). Если выбрать ЯВУ, то кодить будет намного проще, но есть опасение получить в итоге *****код, не позволяющий достичь нужной производительности и компактности.
С-- хорош тем, что можно начинать писать код на ЯВУ (вообще не зная ассемблера), в процессе заглядывая в генеримый ассемблерный листинг и оптимизируя код по мере изучения ассемблера и/или выявления существенных неоптимальных моментов. При этом будет сложнее закончить тем, что код невозможно поддерживать в силу его чрезмерной сложности или плохой оптимизации.

Oleg N. Cher

18.04.2018, 17:22

Тогда как вызывать фрагменты ассемблера? музыку, например.Легко. Просто пишешь: $асм-инструкция

: void DEOLN() {
DL = 0x0D;
AH = 2;
$int 21h
DL = 0x0A;
AH = 2;
$int 21h
}

Тогда С-- и ЯВУ - разные весовые категории.Согласен. Никто ведь и не утверждал, что C-- это ЯВУ.

На Спеке ЯВУ для тех, кто не знает, не хочет знать Ассемблер или неохота/нет времени на нем писать.На Спеке доступность ЯВУ это доступность Бейсика в ПЗУ. Можно на нём накорябать что-то. Серьёзный ЯВУ типа Си/SDCC или Оберон - недоступен из ПЗУ. А значит для его освоения нужны стимулы и понимание, зачем нужно именно это средство. У нас в сообществе в основном мнение такое, что нафиг надо, лучше асма ничего нет. И написать что-то серьёзное для Спека без знания асма невозможно даже на ЯВУ. Разве что будет действовать команда: кодер прикладного слоя, не знающий асма, и кодер-системщик, который будет ему подгонять реализацию процедур на асме. Хотя это тоже исключает разработку без знания асма. И я никогда не встречал такого работающего тандема.

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

Andrew771

18.04.2018, 17:40

Такие оптимизации вещь конечно хорошая, но всё равно приличный компилятор малыми силами не сделать. И не спорь.
Нужно понять, насколько приличный. Для Спека тоже есть компили с оптимизациями. Тесты где-то выкладывал Vitamin тут на форуме, правда давно.
SDCC, который ты используешь для Оберона, приличный?

Oleg N. Cher

18.04.2018, 17:43

Я не вполне удовлетворён качеством машкода от SDCC, но лучше ведь ничего нету. Или писать на ЯВУ и мириться с таким кодом, или использовать что-то вроде Sphinx C--, который ещё для Z80 нужно адаптировать.

Andrew771

18.04.2018, 17:49

Тесты где-то выкладывал Vitamin тут на форуме, правда давно
Вот, нашел: http://zx-pk.ru/threads/4110-yazyki-programmirovaniya.html?p=65499&viewfull=1#post65499
Смотреть это сообщение и далее на несколько страниц.

Oleg N. Cher

18.04.2018, 18:02

Добавлю ещё пару ссылок на сравнение Си-компайлеров:

https://www.z88dk.org/wiki/doku.php?id=temp:front#benchmarks
http://www.cpcmania.com/Docs/Programming/SDCC_vs_z88dk_Comparing_size_and_speed.htm

Но мы отклоняемся от темы. Всё-таки оптимизация компилятором и оптимизация руками - это несколько разные вещи. Как и высокоуровневый и низкоуровневый код.

krt17

18.04.2018, 18:18

Если есть большое желание сподвигнуть на написание компилятора, может лучше рассказать про bison/yacc/flex или что там нынче модно? Да вообще направить пытливый детский ум не в ручное написание лексического парсера и изучение исходников времен зеленых терминалов, а познакомить с правильным подходом. Может и не напишем, но книжки правильные и интересные почитаем. А то претенденты на лучший язык для спека каждые пол года новые, а реально используются максимум скрипты из агд и мк2, ну или С от безысходности.

Andrew771

18.04.2018, 22:12

я пробовал читать "Книгу Дракона" (известную в писи-кругах), но для Спека оттуда мало что применимо. Там слишком современные подходы :)

Trol73

18.04.2018, 22:32

Да, в 2018 году естественно использовать всякие там bison/yacc/flex/antlr/javacc и прочие LLVM, но их недостаток - высокий порог вхождения. Тогда как написать свой простой парсер реально за пару-тройку вечеров. Если изначально не ставить цель написания с нуля собственного ЯВУ, а сделать некоторую надстройку над ассемблером, которая улучшит структуру и читаемость кода, и постепенно её развивать, то можно получить ощутимый практический результат сравнительно небольшими усилиями.

Oleg N. Cher

18.04.2018, 23:54

может лучше рассказать про bison/yacc/flex или что там нынче модно?Дык. Сподвигайтесь.

http://other.jrsoftware.org/ip/http://www.ssw.uni-linz.ac.at/Coco/https://tproger.ru/books/compiler-design-books/http://alexei-s1.narod.ru/books/pishem_compilator.pdfhttp://www.exmortis.narod.ru/src_compilers.html
Но я продолжаю оставаться при мнении, что энтузиасту-самоделкину подвластен только простой компилятор ЯВУ со средним качеством генерации кода. То есть он даже не приблизится к SDCC, который здесь много ругали и много хвалили. Кстати, есть ещё ZSDCC из набора z88dk - SDCC с расширенным набором правил для peephole-оптимизатора. По утверждениям разработчиков - даёт код намного лучше.

Другое дело, если язык очень низкоуровневый - типа Metal, COLOSS, PL/M или C--
И тогда можно описывать все оптимизации руками и писать на нём демки и игры качества, сопоставимого с написанными на ассемблере.

mastermind

20.04.2018, 15:00

Вариация C--, кстати, на практике используется в GHC (компилятор Haskell) в качестве промежуточного кода: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Cmm

Shiny

20.04.2018, 15:08

кстати, кто копался в коде? выходит, что в x86 сравнение переменных выльется в не пойми что, если сравнивать с кодом z80.

Bolt

20.04.2018, 15:48

В коде не копался, но по-моему наоборот, в Z80 сравнение переменных выливается в не пойми что.
x86 более приспособлен под ЯВУ (локальные переменные, массивы, указатели...).

Shiny

20.04.2018, 16:02

как раз да. я увидел в Hitech C замысловатый код сравнения. в х86 выглядело бы как:

cmp ax,-1
jl..
jg..

Trol73

20.04.2018, 19:22

Если есть желание сделать новый язык, надо начать со спецификации. Описать синтаксические конструкции и ассемблерный код, в который они будут конвертироваться. Начать с самого простого и основного и постепенно расширять. Для начала можно генерировать на выходе ассемблерный листинг и использовать внешний асм-компилятор.

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

Если будет спека, любой желающий сможет начать писать компилятор. В частности, я мог бы попробовать сделать его на базе avr-asm-ext (https://github.com/trol73/avr-asm-ext). От исходников С-- Михаила тут навряд ли будет большая практическая польза для Z80.

Shiny

20.04.2018, 19:28

дерзай(:

blackmirror

20.04.2018, 19:42

как раз да. я увидел в Hitech C замысловатый код сравнения. в х86 выглядело бы как:

cmp ax,-1
jl..
jg..

это еще не самое замысловатое, на x86 можно сделать и такое:

switch:
shl al,6 ;проверяем 3 младших разряда
jc case47
jz case0 ;x00
jns case1 ;x0x
jnp case2 ;x10
case3: ;x11
...
case47: ;1xx
jz case4
jns case5
jnp case6
case7:
...

Shiny

20.04.2018, 19:44

это еще не самое замысловатое, на x86 можно сделать и такое:

ВОН ИЗ ПРОФЕССИИ!!

mastermind

30.04.2018, 01:41

Oleg N. Cher

30.04.2018, 22:50

Исполняемые файлы для win32/win64О, он собирается и для win64? Круть, не знал, что в те времена писали с учётом этого) Обычно переход на 64 бита весьма болезнен...

Vasil

01.05.2018, 13:50

О, он собирается и для win64? Круть, не знал,....

Извините за вопрос, а в чём круть-то ? Или нельзя 32-бит приложение запускать в x64 винде, или собирать в x32 винде под винду x64 ? Я в недоумении, правда :)

P.S. И вопрос на десерт.... Ну как продвигается портация сабжа на Z80 ? :):)

Oleg N. Cher

01.05.2018, 14:23

32-бит приложения запускать в x64 винде можно. Там для этого есть специальный слой совместимости и фокус не в этом.

Собирать в x32 винде под винду x64 технически тоже можно, хотя, чаще всего, это, правда, не предусмотрено. Но, например, TDM-GCC работает под Win32 и может давать таргет-код для x64.

На грани фантастики сложно портировать под 64 бита код, который не проектировался для 64 бит. Он может хранить указатели в int и делать ещё массу безобразий. Так что это превращается в очень кропотливую работу с последующим ёмким процессом отладки. Опять же, никто не мешал писать код заранее так, чтобы он потом легко портировался под разные битности. Но со старым кодом всё чаще не так - в те времена обычно программисты ещё такими вопросами не заморачивались.

Портацией на Z80 сабжа, насколько мы тут выяснили, никто пока не занимается.

mastermind

03.05.2018, 19:55

О, он собирается и для win64? Круть, не знал, что в те времена писали с учётом этого) Обычно переход на 64 бита весьма болезнен...

"Собирается" - не значит что все работает как задумано. Надо все проверять. Что я увидел по ходу дела - поправил, но там еще много что нужно проверить. Помимо этого там еще и другие проблемы (вне зависимости от 32/64 бит), например тупо пишутся неупакованные структуры в файлы. (при создании всяких PE-файлов и т.п.) Это все нужно тоже править.

Oleg N. Cher

03.05.2018, 22:56

Даже не сомневаюсь в этом! Но хотя бы начало положено :)

Vasil

04.05.2018, 13:07

Но хотя бы начало положено :)

Что-то я уж совсем ничего не понимаю. Начало чего.... нативного x64 компилятора С-- ? А на кой оно вообще нужно! и собсно о чём Ваш оптимизм ?? И вообще, это уже пошёл совсем не сабж.

Oleg N. Cher

04.05.2018, 13:53

Например, чтобы Linux 64 битов исполнял 32-битные пакеты - нужно дополнительно установить поддержку архитектуры i586, что не всегда доступно по нескольким причинам. Поэтому на такой площадке может работать только 64-битный код.

А оптимизм обычно объяснений не требует) Мне приятно, что кто-то разделяет мои взгляды на юзабельность C-- для Z80.