Solid C - компилятор Си для Спринтера

[Vasil Ivanov]

Солид, в плане генерации кода, на ступеньку выше будет всех сишных компиляторов,
имеющихся на данное время на 8-ми битках. Сравни асм-листинги после твоего Хайтек-Си и от Солида. Вот и тебе "пример простой, но..."

а солид умеет юзать регистры проца как часто используемые переменные?

и вообще какой-нибудь компилятор сей для z80 это умеет делать?

Кусок из фидошной эхи (былые времена):
======================================
в Hi-Tech C для PC есть
- глобальное распределение регистров и
- передача аргументов в регистрах
(этих фич нет в варианте для CPM)

MSX-C/SOLID-C: кроме того, что есть в Hi-Tech имеет:
- нерекурсивные ф-ции
- распределение регистров с помощью PUSH/POP
======================================

Кусок из доки Солид Си:
==============================================
Одной из целей разработки компилятора MSX-C было создание инструментального средства, которое позволяяет писать и саму операционную систему, и программное обеспечение для ЭВМ. Для достижения этой цели в кодогенератор введены различные дополнительные средства.Так, разработаны средства автоматического распределения регистров. Благодаря этим средствам, которые впервые внедрены в компиляторе для микро-ЭВМ, удалось существенно повысить эффективность объектного кода. В результате этих мероприятий стало возможным писать на высоко-уровневом языке, которым является Си, даже системы, работающие в условиях жестких ограничений по памяти и реальному масштабу времени. При этом почти полностью устранена необходимость программирования на Ассемблере.
==============================================

Уверен, что переменные не всегда будут попадать в регистры (только для самых простых случаев), обязательно будут переменные и в ячейках памяти. Регистров мало, а передавать нужно много чего и данный компилятор не настолько умен, чтобы удивить кодеров, пишущих на асме. Ессно с ручной оптимизацией все эти компиляторы все-равно не стоит сравнивать. Поэтому считаю, что для 8-ми биток самым оптимальным вариантом будет инструмент типа "C--", можно одновременно писать к примеру lzw-алгоритмы и boot-загрузчики

[Sayman]

не то, чтобы некропостинг, но всё таки:

Code: Select all

Еще не надоело похваляться "своим" Хайтек-Си, который "все прекрасно собирает"

тут следует задать встречный вопрос - а ваш Солид умеет в 32 бита? нет, не умеет. и с этим огромным минусом можно просто хоронить данный компилятор.
т.е. в рамках CP/M этот компилятор может и был бы хорош, но у нас тут и файлы могут быть больше мегабайта и сектора 32бита. не имея 32х битной логики и арифметики пилить на таком инструменте что-либо просто не возможно. банально тот же fdisk пролетает мимо данного компилятора. большие файлы тоже не прогрузить "нахрапом" (особенно когда по размеру файла нужно вычислять кол-во выделяемой памяти) и т.д. а так, хайтех древний под цпм тоже умеет "распределять" по регистрам, но через директиву register, т.е. вручную.

[Lavr]

а солид умеет юзать регистры проца как часто используемые переменные?
и вообще какой-нибудь компилятор сей для z80 это умеет делать?

Извините, что вмешиваюсь, но мне этот вопрос тоже очень интересен...

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

Поэтому как-то в другую сторону меня качнуло - посмотреть на компилятор PL/M.
Он вроде как поумнее компилирует код, по сравнению с тем-же Best_C.
Но смысл компилятора С в некоторой переносимости программ, хотя... попадалась мне заметка Демина aka Begoon,
где он пишет, что z80 и i8080 в принципе весьма неудобные процы для создания эффективного компилятора С...

[Sayman]

Solid C, конечно умеет передавать аргументы через стек. это очень здорово. согласно мануала, до трёх аргументов. для типа char использует A, E, C. Для типа int - HL, DE, BC. остальные аргументы через стек засылаются. и т.д.
далеко не все компиляторы умеют в регистры для z80. некоторые прям фанатеют от SDCC, а он регистры ненавидит. максимум что о н может, это передавать только 1 аргумент через регистр и то, не при помощи стандартной директивы register, а левыми (правыми) __z88dk_callee и подобной хернёй.
Хайтех для cp/m с регистрами работать не умеет совсем. однако версия под ms-dos уже этому обучена.
какие ещё компиляторы умеют передавать аргументы через регистры и далее с ними работать не через стек, точно даже не смогу подсказать.
Оригинальных исходников Solid C не существует. У Василия декомпиляция, как я понял (можно попробовать у него поклянчить). Сам же автор компилятора давно умер (к сожалению) не успев расшарить исходники.

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

кстати, Лавр, а где твой Спринтер? или его у тебя и не было никогда?

2Василий. возрадуйся, чел. Ты когда то прям желал компилятор C-- под z80. Вот он:
https://github.com/alemorf/zx_spectrum_ ... r/cmm_last

[Shaos]

кстати, Лавр, а где твой Спринтер? или его у тебя и не было никогда?

Лавр у нас фанат Специалиста

[Sayman]

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

[Lavr]

кстати, Лавр, а где твой Спринтер? или его у тебя и не было никогда?

Лавр у нас фанат Специалиста

Ну компилятору С это как бы немного безразлично должно быть.
И цпм на Специалисте есть и процессоры те же...

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

[Sayman]

когда то давно под i8080 был один компилятор сей, BDS C. запускался он из под цпм. поставлялся в комплекте с исходниками. вроде генерил код под i8080 и на нём же работал. но он не умеет в long и float.

[Lavr]

когда то давно под i8080 был один компилятор сей, BDS C. запускался он из под цпм. поставлялся в комплекте с исходниками.

Когда я потерпел неудачу с Best-C для "Специалиста", то поискал другой образец, как писать компилятор С.

И нашел я следующий проект: SMALL C

SMALL C is a "C" language compiler that is available with source code. It is very easy to port to another CPU, and this has been done many times.

Там есть и такой вариант:

SMALL C/Plus v1.0 : Small C V1.0 with structures/unions, floating point, and more. Runs on CP/M (61K TPA required). Generates a rather weird set of mnemonics but assembler is furnished.

Вот только времени заняться этим пока не нашлось...

[Sayman]

SmallC это помойка. на его основе как раз и написаны такие компиляторы, как SDCC и Z88DK.
лучше на BDS C посмотри.
загляни сюда. если не заглядывал ранее: http://www.z80.eu/c-compiler.html

[Shaos]

SmallC упоминался на этом форуме в 2017:
http://www.nedopc.org/forum/viewtopic.php?f=72&t=17191

[Lavr]

лучше на BDS C посмотри.
загляни сюда. если не заглядывал ранее: http://www.z80.eu/c-compiler.html

Видел это ранее... но - спасибо, исходник скачал...

На SmallC я обратил внимание, поскольку его успешно переносили на разные платформы.
Выходит, подумал я, - код его многим достаточно понятен.
Так-то опыта у меня в этом практически нет.

[Shaos]

Склеил несколько разных тем по Solid C в одну - так проще ориентироваться

Я обратил внимание, что сборки Solid C, включающей английские документы, которые мы тут всем посёлком переводили в своё время, так и не случилось - вот я думаю может собрать такую сборку и заодно поддержку DLL туда же воткнуть? Там правда новый CLIB.IRL к которому нет исходников - так вот может Василий покопается в архивах и выдаст нам обновлённые исходники CLIB где есть поддержка DLL?

[Shaos]

В данном случае нам не нужен массив чаров - нам нужен первый элемент массива, т.к. 0x%02X. Далее, чтобы подучить первый элемент массива надо разыменовать указатель на него, т.е. *buffer. Ты говоришь, что компилятор это не просекает, т.е. надо писать (char)*buffer, но никак не (char*)*buffer, т.к. последнее означает преобразовать первый символ по указателю к указателю...

В папке Examples-ов в bin2c.c, откуда этот пример, обращение идет
именно как к чар-массиву.

Твои рассуждения правильны, но в отношении к данной версии Солида они не подходят. Только что проверил:
...

Да - это глюк. А если попробовать вот так:

printf("0x%02X\n", *(char*)buffer);

кол-во звездочек такое же, но они переставлены и код является верным с точки зрения любого компилятора Си

Только что проверил сам - похоже, что %X вообще неработает с типами char - ни с *buffer, ни с buffer[0], ни просто с переменной типа char - прибавляется еще старший байт, НО если предварительно сделать присвоение int i = *buffer и именно этот int скормить принтфу - то все будет ок.

Перепроверил через 16 лет - да, %X не работает нормально с типами char - ему надо 16-битный int т.е.

int i = *buffer;
printf("0x%02X\n", i);

отработает верно

P.S. вот так тоже работает:

printf("0x%02X\n", (int)*buffer);

т.е. суть в том, что в этом компиляторе если в формате стоит %X то аргументом должен быть int (а с char будет работать только %c показывая соответствующую букву)

[Shaos]

Всё присматриваюсь как автоматизировать процесс сборки - если C-файл положить вместе с EXE-шниками, то можно собирать батничком (это HELLO.BAT, который лежит в EXAMPLES):

Code: Select all

@echo off
cc1 -m hello.c
cc2 hello.tmc
as hello.asm
ld hello,clib/l/gXMAIN /x
del hello.rel
del hello.asm

Далее выяснилось, что cc1 принимает только файлы с раширением .c, cc2 - только с расширением .tmc, а asm - только с расширением .asm - и если расширения не указывать, то оно само их добавит:

Code: Select all

@echo off
cc1 -m hello
cc2 hello
as hello
ld hello,clib/l/gXMAIN /x
del hello.rel
del hello.asm

Для того, чтобы можно было применять этот батничок к разным файлам, можно завести переменную:

Code: Select all

@echo off
set PROG=hello
cc1 -m %PROG%
cc2 %PROG%
as %PROG%
ld %PROG%,clib/l/gXMAIN /x
del %PROG%.rel
del %PROG%.asm

Потом я попробовал разнести EXE-шники и исходники в разные места - CC1 и CC2 понимают длинные пути (до 80 и 64 символов длиной соответственно - так указано в документацией), AS вроде тоже (на сколько длинно - не проверял), а вот LD ожидает имя длиной не более 12 символов - соответственно он может работать только с файлами из текущего каталога, где также должна лежать либа CLIB.IRL