Ищу Си для Z80

[Alcoholics Anonymous]

мне не понятно, зачем применять такие извращённые методы сборки, как совмещение двух разных компиляторов?

Я не уверен, почему вы думаете об этом как извращенное? Набор компилятор состоит из трех независимых частей: (1) язык переводчик, переводит с C (например) ASM, (2) библиотеки функций, и (3) ассемблер / линкера / библиотекаря, который может построить двоичные файлы. Это не редкость, чтобы иметь возможность поменять детали, особенно библиотеку. Есть несколько библиотек C, доступных для загрузки, которые можно использовать в комбинации с любым компилятором, который соответствует замена из (2). Многие современные компиляторы могут составлять для нескольких языков, что соответствует замена из (1). Visual Studio может скомпилировать C, C ++, C #, Fortran, .... все, используя один и тот же код .NET и компоновщик. Существует даже пример старого компилятора с 1980-х годов под названием Kit Amsterdam Compiler, который может скомпилировать C, Pascal, Fortran и предназначается для нескольких процессоров. Все одни и те же библиотеки кода и ассемблер но язык переводчик выгружена в зависимости от языка.

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

I'm not sure why you think of it as perverse? A compiler kit is composed of three independent parts: (1) a language translator that translates from C (for example) to asm, (2) a library of functions, and (3) an assembler / linker / librarian that can build binaries. It's not unusual to be able to swap out parts, especially the library. There are several C libraries available for download that can be used in combination with any C compiler which corresponds to swapping out (2). Many modern compilers can compile for several languages which corresponds to swapping out (1). Visual Studio can compile C, C++, C#, Fortran, .... all using the same .NET code and linker. There is even an example of an old compiler from the 1980s called the Amsterdam Compiler Kit that can compile C, Pascal, Fortran and targets multiple CPUs. All share the same library code and assembler but the language translator is swapped out depending on the language.

[свернуть]

Это ничем не отличается в z88dk. Вы можете выбрать, какой компилятор C для использования (есть два варианта сейчас), и вы можете выбрать, какую библиотеку использовать (есть также два варианта). В будущем очень хорошо могут быть и другие варианты для C компилятора или компиляторы для других языков. Пределы только до доступного времени и интересов вкладчиков.

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

This is no different in z88dk. You can choose which C compiler to use (there are two choices now) and you can choose which library to use (there are also two choices). In the future there very well may be other choices for C compiler or compilers for other languages. The limits are only down to available time and interests of contributors.

[свернуть]

если уж на то пошло, почему просто не дизасемблировать тот же htc 3.09 for cp/m, который бесплатный и не применить кодогенерацию по его образу и подобию+свои оптимизации.

HTC 3.09 для имп не был бы лучшим выбором, но, как вы читали, я не неблагоприятных для добавления других переводчиков

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

HTC 3.09 for cpm wouldn't be the best choice but as you've read I'm not adverse to adding other translators

[свернуть]

Сильно не удобно, если честно, использовать длинные конструкции для сборки одного кода из двух разных компиляторов, пусть и в обном bat файле. Запоминать гору ключей, библиотек. Это всё заморочки не нужные.

Я не знаю, почему вы думаете, что это трудно построить двоичные файлы. Это, как я скомпилировать программу для CP / M с помощью SDCC:

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

I'm not sure why you think it's difficult to build binaries. This is how I compile a program for cp/m using sdcc:

[свернуть]

zcc +cpm -vn -SO3 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test

Это все. Выход "test_CODE.bin", который может быть переименована в "test.com". Это файл ком запуске в CP / M

Эта же программа составлена для гх с использованием SDCC:

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

That's all. The output is "test_CODE.bin" which can be renamed "test.com". That's the com file you run in cp/m

The same program compiled for zx using sdcc:

[свернуть]

zcc +zx -vn -SO3 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test

Это все. Выход "test_CODE.bin", который может быть загружен по адресу 32768 и RAND USR 32768, чтобы запустить его. Если вы хотите, чтобы сделать водопроводную файл, который вы можете запустить appmake на нем (appmake является инструментом в z88dk).


Если ваш проект содержит несколько исходные файлы Си и несколько ASM файлы, которые вы можете собрать его так:

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

That's all. The output is "test_CODE.bin" which can be loaded at address 32768 and RAND USR 32768 to run it. If you want to make a tap file you can run appmake on it (appmake is a tool in z88dk).


If your project contains several C source files and several asm files you can compile it like this:

[свернуть]

zcc +zx -vn -SO3 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test1.c test2.c test3.c m1.asm m2.asm -o test

Это все. Выходной сигнал будет "test_CODE.bin"


Там нет сложных пакетных файлов - только одна строка компиляции. Если вам нужна более сложная обработка файлов или вы хотите индивидуально компилировать C Источник, вы можете использовать пакетный файл или Makefile конечно.


Я не думаю, что это можно сделать проще. Вы могли бы думать о SDCC, которая требует от вас индивидуально компиляции исходных файлов, связать их вместе, а затем запустить ihx2bin, чтобы сгенерировать двоичный файл.

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

That's all. The output will be "test_CODE.bin"


There are no complicated batch files -- just one compile line. If you need more complicated processing of your files or you want to individually compile c source, you can use a batch file or makefile of course.


I don't think it's possible to be made simpler. You might be thinking of sdcc which requires you to individually compile source files, link them together and then run ihx2bin to generate a binary.

[свернуть]

Куда проще взять эмулятор cpm для windows, взять бесплатный htc и спокойно мелким батником это собирать. Хотя и make хорошо прикручивается.
Опять таки, сидел ставил эксперименты по тематике ray casting`а понял, что sdcc всё ровно выдаёт более тяжёлый код, даже на фоне старого htc.

SDCC код может быть улучшена, и мы работаем над этим все время. Я был бы заинтересован в том, что некоторые из исходного кода, чтобы мы могли увидеть, если мы могли бы улучшить выход, если он уже не улучшается z88dk. Мы можем исправить многое, но не все, так как мы только пытаемся улучшить код после того, как он уже был создан компилятором. Код выхода из SDCC, когда используется z88dk не то же самое, как то, что выходит из SDCC сам по себе.

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

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

sdcc's code can be improved and we work on this all the time. I would be interested in seeing some of that source code so we could see if we could improve output, if it isn't already improved by z88dk. We can fix many things but not everything since we are only trying to improve code after it has already been generated by the compiler. The code coming out of sdcc when used by z88dk is not the same as what comes out of sdcc by itself.

Sometimes you have to help the compiler generate better code by making some variables static or by breaking large functions into many smaller ones.

[свернуть]

Кстати, во всех этих извратных манипуляциях и библиотеках, поддержки спринтера так и нет.

Еще нет. Новая библиотека C имеет только три цели в данный момент: Zx СРМ и внедренные. Мы концентрируясь на добивании модель драйвера и дискового ввода / вывода, прежде чем мы начнем перенос на новые цели.

Классическая библиотека C действительно имеет экспериментальную поддержку спринтер, включая файл ввода / вывода, но это не представляется возможным использовать SDCC для компиляции для классической библиотеки C пока. Вот над этим работают в настоящее время.
http://www.z88dk.org/wiki/doku.php?id=targets

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

Not yet. The new c library only has three targets currently: zx, cpm and embedded. We're concentrating on finishing the driver model and disk i/o before we start porting to new targets.

The classic C library does have experimental support for the sprinter including file i/o but it is not possible to use sdcc to compile for the classic c library yet. That's being worked on now.
http://www.z88dk.org/wiki/doku.php?id=targets

[свернуть]

http://nightly.z88dk.org/

[Sergey]

ассемблер отдельно взятых си компиляторов, к сожалению. только к ним и относятся и никакими другими не заменить.
Не припоминаю чтобы к сдцц можно было бы прикрутить тот же sjasm для генерации z80 кода.

Во-первых, функции для библиотек можешь писать на чём хочешь, главное, обеспечь их сборку в rel или lib.
Во-вторых, с ключиком --asm= можно заставить SDCC генерировать ассемблерный текст для других ассемблеров - пожалуйста, можешь редактировать и компилить отдельно любимым асмом.

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

Снова здорова! Да вы чем читате?! Даже если ты шестнадцатиричное число без неё наберёшь, асм это тоже не поёмет. Решётка - обозначение непосредственной адресации. Для Z80 такой синтаксис, конечно, избыточен, это издержки унификации.

сдцц, как и z88dk, базируется на древнем цпм компиляторе small-c. Только вот z88dk по части асма более близок к пользователю, а в sdcc всё сильно извратили.

Как говорится, одни ищут возможности, другие - причины. Если уж так решётки не нравятся - что, нельзя скриптик написать для их "выкусывания"?
ТАКАЯ БОЛЬШАЯ проблема! Самому-то не смешно?
Лично, я, вообще, никаких проблем с переходом на этот синтаксис не заметил - даже мысли не возникло претензии по этому поводу предъявлять.

К слову говоря о бесплатности и "лучшести" - не совсем близкие значения.

Боюсь, ты будешь шокирован, но эти значения ещё дальше друг от друга, чем тёплое и мягкое.

Может для всяких pic`ов и подобных он и лучший, но для z80 не фонтан, откровенно говоря. Даже твои тесты показывают, что sdcc уступает древнему и бесплатному htc (кстати, ты табличку так и не подправил).

Таблички все поправлены. Лучше SDCC код дали только HTC 7.50 и z88dk, использующий пропатченый (ВНЕЗАПНО) sdcc. Что касается htc то, боюсь, если ты решётку в sdcc не осилил, то танцы с бубном в компании DosBOX, htc7.50, cp/m эмулятора и htc3.09, чтобы собрать файл для спека, и подавно.
HTC7.50 можно использовать в случае, если не жалко усилий ради конечного результата.

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

Как, кстати, получить доступ к локальным переменным функции в SDCC со стороны ассемблера ?

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

Если тебе это понадобилось, значит, 99,99% ты что-то делаешь не правильно. Если эта переменная требуется где-то ещё, объяви её ГЛОБАЛЬНОЙ.

[Sayman]

не понравилась мне прошлая писанина. переписал слегка...
во1х, у нас речь про sdcc, так? какие из существующих, например, ассемблеров, умеют генрировать rel/lib, тем более совместимый с sdcc? таких нет. даже древнющие m80, zmac и подобные не смотря на наличие rel, они не совместимы с sdcc.
во2х, на кой чёрт мне использовать ни с чем не совместимый синтаксис асма sdcc? к какому компилятору мне его потом прикладывать? таких тоже нет.
в3х, в sdcc на асме решётка применяется для обозначения 10тичного числа. для 16тиричных чисел используется 0x. Если перенесёшь числа с решёткой в тот же sjasm, то кроме ошибок в своём проекте ничего не получишь.
в4х, htc 3.09 в паре с эмулятором cpm под виндой (консольный эмулятор) прекрасно генерит у меня код и для cpm и для профи (не дописал библиотеку) и для спринтера. не вижу тут сильного гемора, хотя есть некоторые выбешивающие моменты.
в5х, по твоей таблице htc 3.09 с включённым оптимизатором выдаёт результат в 483/472 секунд, а sdcc (в табличке 3.51, видимо правленый) выдаёт 528 765, т.е. медленнее. я потому и спросил, почему табличку не исправляешь.
мне вот только одного не ясно, в чём заключается смысл защищать продукт, который по качеству генерируемого кода хуже, чем доистрический htc?

[Sergey]

во1х, у нас речь про sdcc, так? какие из существующих, например, ассемблеров, умеют генрировать rel/lib, тем более совместимый с sdcc? таких нет. даже древнющие m80, zmac и подобные не смотря на наличие rel, они не совместимы с sdcc.

Это частности, которые к делу не относятся. Нету? - не ной, напиши конвертер! Мне это не надо знать - меня и так всё устраивает, как и большинство, пишущих на Си для z80.

Прелесть sdcc в том, что можно Сишный текст и функции на асме держать в одном исходнике, и можно по ходу дела, в них что-то поправить, а затем в один клик скомпилить готовый результат.
В HTC 3.09 так нельзя, потому что, хоть он и допускает такое размещение, после оптимизатора твоя асмовая функция может быть изменена до неузнаваемости. Поэтому приходится держать в разных исходниках, изменять отдельный исходник, потом ассемблировать ручками в объетник, а уже ПОТОМ собирать весь проект и оценивать результат.
Если по сравнению с этим вы решётку считаете неудобством, то увольте.

во2х, на кой чёрт мне использовать ни с чем не совместимый синтаксис асма sdcc? к какому компилятору мне его потом прикладывать? таких тоже нет.

Прекрасно компилится, например, sdasz80.exe.

в3х, в sdcc на асме решётка применяется для обозначения 10тичного числа. для 16тиричных чисел используется 0x.

Нет, ну хватит уже вводить общественность в заблуждение. Чего пишешь, если мат.части не знаешь?
А ваш любимый SJasm вообще не умеет из консоли бинарники выдавать - я ж молчу.

в4х, htc 3.09 в паре с эмулятором cpm под виндой (консольный эмулятор) прекрасно генерит у меня код и для cpm и для профи (не дописал библиотеку) и для спринтера. не вижу тут сильного гемора, хотя есть некоторые выбешивающие моменты.

7.50, 7.50, семь-пятьдесят, СЕМЬ-ПЯТЬДЕСЯТ! - "Танцы с бубном" касаются только версии СЕМЬ-ПЯТЬДЕСЯТ ДЛЯ MS-DOS.
1) Запускаешь DOS-BOX
2) Запускаешь HTC_7.50,
3) Открываешь в его IDE файл на Си
4) Генеришь ассемблерный файл.
5) Выходишь из DOS-BOX
6) Правишь полученный исходник под формат HTC_3.09.
7) Запускаешь скрипт, применяющий к исходнику ассемблер и линкер из комплекта HTC_3.09.
8) Радуешься жизни.

в5х, по твоей таблице htc 3.09 с включённым оптимизатором выдаёт результат в 483/472 секунд, а sdcc (в табличке 3.51, видимо правленый) выдаёт 528 765, т.е. медленнее. я потому и спросил, почему табличку не исправляешь.
мне вот только одного не ясно, в чём заключается смысл защищать продукт, который по качеству генерируемого кода хуже, чем доистрический htc?

В адвокаты SDCC я не записывался, - просто, я за всё хорошее против всего плохого.
Ты зачем перевираешь данные из моей таблицы?! Не 483/472, а 432/1814 принадлежит HTC 7.50, а не 3.09. Так что, определённо, лучше, чем SDCC, - только HTC 7.50.

	DI	DI/Gl.vars	Коэфф.
HiTech C v.7.50 (MS-DOS)	432	1814	0,74
SDCC v.3.51 (Win32)	528	765	0,612
HiTech C v.3.09 (cp/m, z80)	979	856	0,3320/0,3773

На мой взгляд, серьёзных бесплатных компиляторов сейчас доступно 4: sdcc, z88dk и HTC 3.09/7.50. Какой использовать - дело вкуса.

[Sayman]

Нету? - не ной, напиши конвертер!

ну да, мне заняться больше не чем же)))

Прелесть sdcc в том, что можно Сишный текст и функции на асме держать в одном исходнике,

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

Если по сравнению с этим вы решётку считаете неудобством, то увольте

если мне нужны асмовые вставки, то я выношу асм в отдельный файл в виде отдельных процедур/функций. это совершенно не мешает. Решётка которой почему то разрабы решили обозначить адресацию и 10чные числа вводит в заблуждение тех, кто впервые пришёл к коду на sdcc и пытается перенести этот код в свои проекты на других компиляторах. надеюсь понимаешь. что когда ты пишешь 10 и #10 это два разных числа и результаты у программы будет разными. Вариант при котором ты предлагаешь сидеть и пилить 100500 конверторов, скриптов и других фигнов для переноса текста sdcc является не корректным. может тебе, в меру своей любопытности или может у тебя времени свободного полно, интересно сидеть за такими делами, а большинству нужен рабочий и исправный инструмент. желательно применяющий общеизвестные стандарты. не видно что-то армий и полчищ поклонников sdcc, которым нравятся все его извраты.

Ты зачем перевираешь данные из моей таблицы?!

извиняй, а это тогда что?

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

[свернуть]

7.50, 7.50, семь-пятьдесят, СЕМЬ-ПЯТЬДЕСЯТ! - "Танцы с бубном" касаются только версии СЕМЬ-ПЯТЬДЕСЯТ ДЛЯ MS-DOS.
1) Запускаешь DOS-BOX
2) Запускаешь HTC_7.50,
3) Открываешь в его IDE файл на Си

ВНЕЗАПНО, IDE тут вообще не нужен.

А ваш любимый SJasm вообще не умеет из консоли бинарники выдавать

ОПА, sdcc не выдаёт с ходу бинарник, он выдаёт в формате ihx, который потом нужно конвертить в бинарник. а что значит не выдаёт из консоли бинарник? ты про это:

..\..\asm\sjasm.exe -L %1.asm %1.exe %1.lst

??

[Oleg N. Cher]

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

Пустая программа void main(void){ return; } занимает после компиляции SDCC 1 байт - RET. Это весь оверхед. Бери и сшивай асм код прямо из Си:

LD(a,10);
LD(b,7); // Макросы
Func1();
LD(c,1);
Func2();

О каких потерях производительности и памяти вообще идёт речь?

[Advertiser]

[Sayman]

Пустая программа void main(void){ return; } занимает после компиляции SDCC 1 байт - RET

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

О каких потерях производительности и памяти вообще идёт речь?

даже не знаю что сказать. типа, код генерируется совершенно ресурсонезависимый. даже не знаю что тут можно сказать. табличка описанная Сергеем показывает какой компилятор выдаёт лучший по производительности код. потеря по памяти - один и тот же код sdcc и htc 3.09 выдают разной длинны. sdcc примерно на 2 - 4 килобайта больше. и это ещё небольшая разница. у меня htc на одном исходнике выдал около 8кб бинарника, а sdcc почти 15кб. т.е. почти в 2 раза разница. на кой чёрт оно такое счастье нужно?
прямо сейчас попытался засунуть ещё один код в sdcc, но он упорно не желает принимать стандартные вещи для всех известных компиляторов.
подсовывал как-то ради интереса в sdcc код на си, который любая версия htc сжирает с потрохами и выдаёт рабочий на 146% бинарник. sdcc от этого исходника плюётся по сей день. могу скинуть ради интереса (letteral code так называемый или просто демка aes256).
sdcc варится сам в себе со своими собственными какими-то приблудами которые понимают только разве что сам разраб и ещё с десяток фанатов. в общем, эту тему пора прикрыть. кому нравится извращаться, ну, продолжайте дальше. Только вот я про табличку так и не понял, данные есть, но они вынесены за пределы. в чём прикол то?

[denpopov]

народ, давайте поищем приличный Паскаль для з80.

[Sayman]

народ, давайте поищем приличный Паскаль для з80.

все известные паскали выдающие код в z80:
http://www.z80.eu/pas-compiler.html
про кросс средства ничего не слышал. кажется, таких нет. под трдос ещё что-то было. ну, ещё оберон какой-то в соседних темах предлагают...

[s_kosorev]

На форуме рассматривался Oberon, можно сказать Pascal с нюансами