Ищу Си для Z80

Цитата:

---

Сообщение от Sayman

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

---

Я не знаю как ты этого добился. Может просто не так вызываешь? Глянь мои make-файлы на предмет параметров.
У меня оптимизатор HitechC на версии v3.09 (CP/Mовская бесплатная) работал всегда, что на реале Орионе, что на Винде под эмулятором (причем под несколькими разными эмуляторами).
Разница была только в том, что на реале Орионе меньше места в ТПА и соответственно меньшие исходники проглатывает оптимизатор (чаще пишет "out of memory"), поэтому я использую PC(WIN)-эмулятор CP/M c максимальным ТРА (порядка 63кб).
Попробуй ту версию HitechC, что размещена в моей темке по UZIX, там и эмулятор уже в общем архиве.
На LINUX я не пробовал.

Цитата:

---

Сообщение от Sayman

Но, при портировании юзикса ты не мог не заметить местами в коде строки типа
// don`t change, HTC crazyness
и подобное. исходники такими строками нашпигованы. я одно время тоже с такими граблями столкнулся, не мог понять, почему компилятор то вылетает, то код получался не рабочий.

---

Все подобное я нимало не беспокоясь много раз "change" и все прекрасно компилировалось и работало, никакого "crazyness".

Я писал в своей темке по портированию: авторы Юзикса собирали его не на публичной бесплатной V3.09 (потому что на ней их исходники сразу искаропки тупо не собираются, тупо нет таких операторов какие там используются - исходники пришлось поправить), а на какой-то другой (подозреваю на платной и мультиплатформенной Z80/Z180/8086 версии 5.х, жившей в конце 90-х, а сейчас платные HitechC уже 7-ю версию перешагнули).

---------- Post added at 13:24 ---------- Previous post was at 13:15 ----------

Кстати, то что ты запускаешь на Профи, может играть отрицательную роль. Hitech C использует некоторые вызовы от CP/M 3.x (какие-то вызовы для работы с датой с номерами около сотни). И соответственно если твоя "допиленная" Q-DOS пересекается по этим вызовам, но возвращает не FF как нормальная CP/M 2.2 для несуществующей функции, а напротив при таком вызове какую-нибудь несовместимую с СРМ 3.x отсебятину делает, то это может влиять, как мне кажется.

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

на счёт сборки Libc от юзикса, там только в одном месте есть употребление "не нашей" директивы inline asm - в syscalls. старый htc про такое не знает. легко превращается в asm текст и собирается через as.com. в остальных исходниках я не замечал ничего сверхъестественного. кстати, интересно. вот он рабочий порт. а что дальше? чем всё закончилось? есть какой-то "не стоковый" софт?

Цитата:

---

А что касается SDCC

---

хорошо. т.е. по твоему только HTC 3.09 является исключительным компилятором? и никаких других больше нельзя использовать? что ты скажешь про z88dk, особенно про ночные сборки? или, например, про iar?
в данной теме многие пришли к противоположному выводу касательно sdcc - продукт годный к употреблению. я пока не могу что-то конкретное сказать. потраченного времени, в целом, не жалко. Хотя почитал комент от Ширу по теме evosdk. там описана причина использования старого sdcc. ну, значит не судьба вкарячить последнюю версию. я прекрасно знаю что такое хайтех, но хотелось бы иметь инструмент работающий не под эмулем с кучей ограничений, а нормальный, под винду. скачал я последнюю версию z88dk, собрал два простых теста - hello world и демку aes256 (которая собирается влёт на хайтехе!). hello весит 1937байт, демка весит 9463 байта. многовато.
и кстати, в отличии от цпм, мне разрешено получать запускаемые файлы, в целом, неограниченного размера. т.е. зависимости между запускаемым файлом и размером tpa у меня нет. htc не даёт такой свободы. sdcc, видимо, тоже.

Цитата:

---

Сообщение от Sayman

на счёт сборки Libc от юзикса, там только в одном месте есть употребление "не нашей" директивы inline asm - в syscalls. старый htc про такое не знает. легко превращается в asm текст и собирается через as.com. в остальных исходниках я не замечал ничего сверхъестественного. кстати, интересно. вот он рабочий порт. а что дальше? чем всё закончилось? есть какой-то "не стоковый" софт?

---

В ядре было полным полно этих операторов asm(). Плюс какие-то объявления сегментов, которые не понимает ассемблер. вроде еще что-то было несовместимое на уровне директив препроцессора.

А где есть нестоковый софт? :)
Если не брать в расчет CP/M как признанного тяжеловеса для которого писал без преувеличния ВЕСЬ МИР в течении пары десятилетий, c точки зрения всех известных мне самописных ОС для Z80, на UZIX пожалуй поболее всего будет, сравнимо с легендарной UNIX Seventh Edition (UZIX по сути и есть "семерка"). Что-то ни один хакер за прошедшие 35 лет не пожаловался на то, что в "семерке мало стока" .
А дальше - что напишешь, тем и богат. Как по мне, то это только плюс. Плюс, портировать можно что приглянется.
Я возлагаю надежды и на FUZIX - оттуда можно будет делать обратный порт когда они наконец то раскачаются. Правда пока там приложений меньше чем в UZIX.

Цитата:

---

Сообщение от Sayman

хорошо. т.е. по твоему только HTC 3.09 является исключительным компилятором? и никаких других больше нельзя использовать? что ты скажешь про z88dk, особенно про ночные сборки? или, например, про iar?

---

IAR я не нашел бесплатных версий, или хотя бы с беспроблемным краком. Поэтому с ним не знаком, ничего не могу сказать. z88dk на момент моего с ним знакомства (2008-2009 год) был одним из самых неэффективных компиляторов для Z80 и привлекал только наличием какой-то реализации TCP/IP. Про глюки тогдашнего z88dk сказать не могу, т.к. переключился на SDCC, в котором тоже разочаровался.

Положа руку на сердце, хорошего компилятора С для Z80 нет. Потому что то, что для Hitech C приходится исходники "подрихтовывать" тоже не радует. Но учитывая когда он написан, в какой минималистической среде живет, и качество его кода, в сравнении с современными это конечно недостижимый образец.

Цитата:

---

Если не брать в расчет CP/M как признанного тяжеловеса

---

не не. цпм это цпм, юзикс это юзикс. если подумать, то какая практическая польза от юзикса? ядро большое и медленное. я не буду говорить за Орион, но, к примеру, порт под ту же "evo". какая там может быть польза? сомнительно, что она там может быть. игры? демы? тот же запилятор (тьфу, блин)?! маловероятно. вот он есть на Орионе и, вот его нет. только если для галочки, для фана. лучше уж тогда игрушку написать.
про z88dk, кто-то из разрабов тут выше отписывал, что какие то работы ведутся. если честно, не понятно что там изменилось. да, действительно, под зетника нет нормального компилятора.
кстати, ты можешь более детально пояснить, что в sdcc тебе не понравилось? какие версии использовал?

Цитата:

---

Сообщение от Sayman

не не. цпм это цпм, юзикс это юзикс. если подумать, то какая практическая польза от юзикса? ядро большое и медленное. я не буду говорить за Орион, но, к примеру, порт под ту же "evo". какая там может быть польза? сомнительно, что она там может быть. игры? демы? тот же запилятор (тьфу, блин)?! маловероятно. вот он есть на Орионе и, вот его нет. только если для галочки, для фана. лучше уж тогда игрушку написать.

---

Ну, игрушек тоже что-то никто не написал, в т.ч. и на evosdk ничего играбельного не было - по сути только демонстрашки что evosdk хоть что-то может. Такие игрушки на Орионе на С делали в начале 90-х (например ranger) безо всяких sdk и SDCC, а нативно на Орионе на простом С-компиляторе под Ордос. (понимаю, что для спектрумиста это звучит как набор букв :) )

И фан - это очень немаловажно. Кроме того, это растущий класс программиста. Писать под UZIX это ровно то же, что писать под любой Юникс (я например в молодости довольно много писал на C под AIX, а до того - под OpenVMS). Вот впилю туда TCPIP (а именно туда и надо впиливать, т.к. только там есть нормальная многозадачность и нормальная - на уровне ОС - реализация очередей/блокировок/консоли), и будет это единственная ОС на Z80 c нормальной поддержкой сети (не считая того же UZIX c MCX от которой потеряны исходники). И это будет реальное преимущество над любой ОС для Z80, которого сейчас для обычного пользователе не видно. Учитывая, что и CPM тож унаследуем - сам же знаешь, на UZIX есть эмулятор CP/M, надо только опять же сесть и адаптировать его нормально в мой дистриб - то это будет нормальная ОС с кучей ПО, многозадачная, многопользовательская и сетевая. А то что для нее надо 10Мгц (а лучше 20Мгц), так это путь немного голова у наших аппаратчиков поболит, а то тоже нихрена не делают.

Просто пока мне интереснее приложения поковырять. Я уже накачал десятка три того что хотелось бы портировать, все они непростые (объемные). Так что фана у меня запланировано на десятилетие вперед. :) Да и вообще на всех бы хватило, только не хочет никто (как никто не пишет игры, не пишет демодроч. Ничего никто не пишет). Я сам бы хотел раз в неделю что-нить новенькое для Ориона скачивать "на побаловаться", но - увы, всё сам.

Цитата:

---

Сообщение от Sayman

про z88dk, кто-то из разрабов тут выше отписывал, что какие то работы ведутся. если честно, не понятно что там изменилось. да, действительно, под зетника нет нормального компилятора.
кстати, ты можешь более детально пояснить, что в sdcc тебе не понравилось? какие версии использовал?

---

Использовал такое крайний раз:
>sdcc --version
SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.4 #7
479 (Mar 23 2012) (MINGW32)

Не понравилось то, что при сборке из одного и того же исходника, HitechC мне собрало работоспособные httpd и telnetd (я тогда развлекался портированием uIP), a SDCC собрал частично работающих, но зависающих непонятно почему уродов в полтора раза большего размера (при всех включенных оптимизациях).

---------- Post added at 18:52 ---------- Previous post was at 18:38 ----------

Я считаю, на Эволюшен и на АТМ обязательно надо портировать UZIX. Да и на Спринтер. С большими страницами процессов. Если не ошибаюсь, они же умеют переключать страницы озу куском по 64к (включая сразу 4 окна диспетчера по 16к)? Надо бы Алония подключить. А то выпилили с форума единственного программера и сидят как сычи.

Ибо как показал опыт FUZIX на Спеке-128, 16к на процесс -это очень мало, особенно если использовать это чудо - SDCC.

---------- Post added at 19:02 ---------- Previous post was at 18:52 ----------

Чтобы не показаться совсем необъективным, отмечу что препроцессор у SDCC лучше чем у Hitech C - SDCC умеет распутывать такие заковыристые макросы, от которых у Hitech едет крыша. Например - Contiki весь на этих заковыристых макросах построен (те самые уродские ПротоТреды). Но тут опять же до смешного доходит: к Контики идет целая телега какими версиями SDCC оно компилируется, какими не компилируется, какими компилируется но не работает. Для FUZIX тоже - только определенная версия SDCC годится. :v2_dizzy_facepalm:

ндэээ, это всё сплошной гемор. да, что примечательно, есть исходники которые на htc собираются влёт. опять-таки, тот же literatecode (aes256). sdcc отказался с ним работать. я не стал вникать в причины. но, что примечательно - z88dk собрал его с правкой всего 5 или 6 функций (прототипы выправил). и запускается на спринтере. но размер - 9.8кб...

Цитата:

---

Я сам бы хотел раз в неделю что-нить новенькое для Ориона скачивать "на побаловаться",

---

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

Цитата:

---

Сообщение от Sayman

а что мешает так же взять и что-то игровое или демодроч. забацать?

---

Я не люблю работать с графикой. Вообще не люблю. И рисую плохо. Все эти пикселы... Даже знакогенератор/фонт в редакторе поправить - сразу приступ тошноты. :)

В молодости делал текстовые игрушки типа Президента, но только пока не втянулся в системное программирование, от которого меня прет. Не знаю почему так.

Цитата:

---

Сообщение от Sayman

кстати, давно спросить хотел - какой порядок расположения "модулей" в lib файле? я тут как то пересобирал под её и накосячил с порядком.

---

А в какой? Под CP/M или под Юзикс? Там разные модули.
В целом, если у тебя есть образцовая либа, порядок должен быть примерно такойже как показывает "libr s libname". Общее правило: если из модуля идут вызовы других функций этой же либы, то этот модуль должен добавляться в либу раньше, чем модули которые он вызывает (они идут позже).

---------- Post added at 21:34 ---------- Previous post was at 21:15 ----------

Цитата:

---

Сообщение от Sayman

но размер - 9.8кб...

---

Размер небольшой программы во многом зависит от того как написан stdio (все эти printf/scanf/putc/getc). Поэтому helloworld где в main() всего один вызов, на одном компиляторе будет одного размера, а на другом - другого, т.к. у них разные либы (там тупо разный функционал реализован - более или менее полный. Например, могут отсутствовать редиректы, а могут присутствовать). А вот большие вычислительные программы, это да - уже можно судить о том хорошо ли компилятор оптимизирует именно код.

Я хотел бы в полной мере участвовать, но языковой барьер действительно трудно преодолеть :(

English in spoiler tags.

Цитата:

---

Сообщение от Sayman

скачал я последнюю версию z88dk, собрал два простых теста - hello world и демку aes256 (которая собирается влёт на хайтехе!). hello весит 1937 байт, демка весит 9463 байта. многовато.

---

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

Кроме того, вы можете использовать любой sccz80 или SDCC для компиляции С, но при использовании SDCC можно использовать только новую библиотеку С.

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

There are a couple of things here to note. In the current z88dk there are two independent c libraries -- the first the old one with which you may be familiar (a binary size of 1937 bytes is small and indicates you have used to old one) and the second is the new one which is aiming for a C11 subset. This new one has been completely rewritten from scratch in assembler and has been made compatible with sdcc. In addition you can use either sccz80 or sdcc to compile the C. But when using sdcc you can only use the new c library.

[свернуть]

Helloworld.c

Код:

---

// SCCZ80
// zcc +zx -vn -clib=new helloworld.c -o helloworld
//
// SDCC (LIBRARY USES IX)
// zcc +zx -vn -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 helloworld.c -o helloworld

#include <stdio.h>

main()
{
  printf("Hello World\n");
}

---

Программа настолько коротка, что не имеет значения, если она скомпилирована с sccz80 или SDCC.

Вот что я получаю:

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

The program is so short that it doesn't matter if it is compiled with sccz80 or sdcc. Here's what I get:

[свернуть]

2015-03-20 11:46 AM 0 helloworld
2015-03-20 11:43 AM 267 helloworld.c
2015-03-20 11:46 AM 6,666 helloworld_CODE.bin

Выход 6666 байт.

Но мы можем сделать его меньше.ЭЛТ создания кучи для таНос, что нам не нужно, это создание выездной стек нам не нужно, это создание STDIO кучу нам не нужно (мы не FOPEN FILEs). Другие значения по умолчанию уже установлены для гх цели исправить размер таблицы дескрипторов файлов и других вещей.

Чтобы избавиться от этих вещей, которые я добавить некоторые прагмами на источник:

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

The output is 6666 bytes. But we can make it smaller. The crt is creating a heap for malloc that we don't need, it's creating an exit stack we don't need, it's creating a stdio heap we don't need (we don't fopen FILEs). Other defaults already set for the zx target fix the size of the file descriptor table and other things. To get rid of these things I add some pragmas to the source:

[свернуть]

Код:

---

// Helloworld2.c

#pragma output CRT_ORG_BSS = -1
#pragma output CLIB_EXIT_STACK_SIZE = 0
#pragma output CLIB_MALLOC_HEAP_SIZE = 0
#pragma output CLIB_STDIO_HEAP_SIZE = 0

#include <stdio.h>

main()
{
  printf("Hello World\n");
}

---

Орг для сегменте BSS заставляет его быть записаны в отдельном файле, так что она не является частью двойной системы. Я, вероятно, не стоит заключать надоели с этим, но это делается.

Теперь я получаю:

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

The org for the BSS segment causes it to be written to a separate file so that it is not part of the binary. I probably shoud not have bothered with that but it is done. Now I get:

[свернуть]

2015-03-20 12:10 PM 0 helloworld2
2015-03-20 12:10 PM 430 helloworld2.c
2015-03-20 12:10 PM 8 helloworld2_BSS.bin
2015-03-20 12:10 PM 5,383 helloworld2_CODE.bin

Вплоть до 5383 байт.

Мы до сих пор не сделано. Printf поддерживает следующие преобразователи: %d, %u, %x, %X, %o, %n, %i, %p, %B (binary), %s, %c, %I (IPv4 address), %ld, %lu, %lx, %lX, %lo, %ln, %li, %lp, %lB (binary).

Сколько из них действительно использует наша программа? Ни один. Так что я удалить их из библиотеки, редактируя файл clib_cfg для серии ZX цели:

http://z88dk.cvs.sourceforge.net/vie...11&view=markup

Я могу изменить линию 247 в "defc __CLIB_OPT_PRINTF = 0". Это можно выбрать, какие именно преобразователи вы хотите быть доступны.

После этого изменения я должен восстановить библиотеку. С z88dk / libsrc / _DEVELOPMENT я запускаю "Winmake ZX" С окна командной строки.

Теперь я получаю это для размера программы:

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

Down to 5383 bytes. We're still not done. printf supports the following converters: %d, %u, %x, %X, %o, %n, %i, %p, %B (binary), %s, %c, %I (IPv4 address), %ld, %lu, %lx, %lX, %lo, %ln, %li, %lp, %lB (binary). How many of these does our program use? None. So I remove them from the library by editing the clib_cfg file for the zx target: http://z88dk.cvs.sourceforge.net/vie...11&view=markup I change line 247 to "defc __CLIB_OPT_PRINTF = 0". It's possible to select exactly which converters you want to be available. After that change I have to rebuild the library. From z88dk/libsrc/_DEVELOPMENT I run "Winmake zx" from a windows command prompt. Now I get this for the program size:

[свернуть]

2015-03-20 12:16 PM 0 helloworld3
2015-03-20 12:11 PM 430 helloworld3.c
2015-03-20 12:16 PM 8 helloworld3_BSS.bin
2015-03-20 12:16 PM 3,699 helloworld3_CODE.bin

Вплоть до 3699 байт из 6666 байт.

Если это все еще слишком велик для вас, вы должны задаться вопросом, если вам нужно Printf. Учтите, что z88dk необходимо предоставить драйверы для стандартного ввода, стандартный вывод, стандартный поток ошибок. Printf посылает потокового на стандартный вывод и водитель там должно пары, чтобы стандартного ввода, чтобы позволить возможности редактирования линия. Так что это водитель Printf не только печатает символы, это позволяет редактировать линии, прокрутка текста окна, подает звуковой сигнал, эмуляции терминала и т.д. Это не просто RST $ 10, хотя вы могли бы написать такой драйвер. Мы не имеем, как мы сначала писать все, независимо от любого системного программного обеспечения.

Одна вещь, вы можете сделать, это удалить все драйверы, поэтому нет ничего прикреплены к стандартного ввода, стандартный вывод, стандартный поток ошибок. У нас есть такой лучевой трубки, которая может быть выбрана с "-startup = 31" на линии компиляции. Если мы уберем STDOUT мы не можем использовать Printf больше так вместо этого мы можем использовать sprinf () для печати в буфер, который вы можете затем вывести на экран с вашей собственной небольшой рутины.

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

Down to 3699 bytes from 6666 bytes. If this is still too large for you, you need to wonder if you need printf. Consider that z88dk needs to provide drivers for stdin, stdout, stderr. printf is sending streamed output to stdout and the driver there needs to couple to stdin to allow line editing capabilities. So this printf driver not only prints chars, it enables line editing, scrolling, text windows, beeps, terminal emulation, etc. It's not a simple RST$10 although you could write such a driver. We haven't as we are first writing everything independently of any system software. One thing you can do is remove all the drivers so there is nothing attached to stdin, stdout, stderr. We have such a crt which can be selected with "-startup=31" on the compile line. If we remove stdout we can't use printf anymore so instead we can use sprinf() to print into a buffer which you can then output to the screen with your own small routine.

[свернуть]

Код:

---

// SCCZ80
// zcc +zx -vn -startup=31 -clib=new helloworld4.c -o helloworld4
//
// SDCC (LIBRARY USES IX)
// zcc +zx -vn -startup=31 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 helloworld4.c -o helloworld4

#pragma output CRT_ORG_BSS = -1
#pragma output CLIB_EXIT_STACK_SIZE = 0
#pragma output CLIB_MALLOC_HEAP_SIZE = 0
#pragma output CLIB_STDIO_HEAP_SIZE = 0

#include <stdio.h>

char buffer[20];

main()
{
  sprintf(buffer, "Hello World\n");
}

---

Я не показывая пользовательского процедуру печати, которые будут принимать "буфер" и вывод на экран. Вы можете себе представить то, что занимает десяток байт, если вы используете RST 10 $.

Теперь вот что я получаю:

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

I am not showing a custom print routine that will take "buffer" and output to the screen. You can imagine something that takes a dozen bytes if you use RST$10. Now here's what I get:

[свернуть]

2015-03-20 12:29 PM 0 helloworld4
2015-03-20 12:29 PM 483 helloworld4.c
2015-03-20 12:29 PM 29 helloworld4_BSS.bin
2015-03-20 12:29 PM 535 helloworld4_CODE.bin

С 6666 байт до 550!

... слишком долго, так будет продолжаться и в следующем посте

... too long so will continue in next post

... продолжал

С 6666 байт до 550!

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

Вы не должны действительно быть глядя на то, как Printf и говорят "6666 байт! Слишком много!". Это может быть, но вы должны помнить, что z88dk и SDCC используете, связывающие монтажников. Что-то вроде Printf тянет во многих библиотеки кода, чтобы сделать что-то вроде разделения, число-> преобразования текста, и т.д., и этот код будет повторно использоваться любой другой C код, который вы пишете. Так что если вы PRINTF что-то, а затем разделить два числа подразделение будет использовать тот же код деления, как Printf делает.

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

From 6666 bytes down to 550! There is a lot going on with the drivers connected to stdout, stdin, etc to allow things like line editing and text windows. If you don't need those things you don't have to use them. You shouldn't really be looking at something like printf and saying "6666 bytes! Too much!". It may be but you have to remember that z88dk and sdcc are using linking assemblers. Something like printf is pulling in a lot of library code to do things like division, number->text conversion, etc, and this code will be reused by any other C code that you write. So if you printf something and then divide two numbers the division will use the same divide code as printf does.

[свернуть]

Цитата:

---

Сообщение от Error404

Цитата:

---

Сообщение от Sayman Посмотреть сообщение
но размер - 9.8кб...

---

Размер небольшой программы во многом зависит от того как написан stdio (все эти printf/scanf/putc/getc). Поэтому helloworld где в main() всего один вызов, на одном компиляторе будет одного размера, а на другом - другого, т.к. у них разные либы (там тупо разный функционал реализован - более или менее полный. Например, могут отсутствовать редиректы, а могут присутствовать). А вот большие вычислительные программы, это да - уже можно судить о том хорошо ли компилятор оптимизирует именно код.

---

Это несколько верно, но соединительные монтажники, что SDCC и использование z88dk гарантировать, что только код, который называется входит в двоичном виде. Призыв к Е () не тянет в коде для зсапЕ (), например. Однако есть и более глубокая связь на уровне ЭЛТ. Если у вас есть стандартный ввод, стандартный вывод эти два потока в сочетании с строки редактирования требует общения между входным терминалом и выходным терминалом. Таким образом, некоторые код библиотеки тянут в поддерживать редактирование линии, когда сама программа С не может использовать зсапЕ (). Если размер программы очень важно, вы можете уменьшить требования к памяти, заменяя простые драйверы на стандартный вывод, например, или отказаться от всего потока стандартного ввода, стандартный вывод, как я сделал выше и просто ограничивать себя sscanf и Sprintf.


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

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

This is somewhat true but the linking assemblers that sdcc and z88dk use ensure that only the code that is called is included into the binary. A call to printf() does not pull in code for scanf() for example. However there is a deeper connection at the crt level. If you have stdin, stdout these two streams are coupled since line editing requires communication between the input terminal and the output terminal. So some library code is pulled in to support line editing when the C program itself may not use scanf(). If program size is important you can reduce the memory requirements by substituting simpler drivers on stdout, for example, or forego all of stdin, stdout as I did above and just confine yourself to sscanf and sprintf. I'll post another example of what can be done with the libraries later on that shows off proportional fonts in text windows. There is a large difference between the libraries in z88dk and all other c compilers. It's the code quality of the C compiler itself that people complain about and that is why we have been working with sdcc to allow sdcc to use the z88dk libraries.

[свернуть]

Что касается качества кода, SDCC улучшилась много в прошлом году.То же самое с библиотеками в z88dk. Оба проекта видели большой рост в последнее время и, конечно, всегда есть больше, чтобы сделать.

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

With regards to code quality, sdcc has improved a lot in the past year. The same goes with the libraries in z88dk. Both projects have seen a lot of growth recently and of course there is always more to do.

[свернуть]

Цитата:

---

Сообщение от Alcoholics Anonymous

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

---

https://drive.google.com/file/d/0B6X...ew?usp=sharing

Два fzx выходные клеммы создаются, один с шрифтом "префект", а другой с шрифта "RoundelSerif". Существует один входной терминал прикреплен к выходной клемме с меньшим шрифтом.

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

Чтобы сделать это демо, я создал новый ЭЛТ с двумя выходными клеммами и один вход. Мы создаем ЭЛТ с помощью винтов M4 макросов.Шаблон я использовал:

http://z88dk.cvs.sourceforge.net/vie....1&view=markup

который является шаблоном для 48k барана ZX. Я заменил строки 73-84 с моими собственными экземпляров драйверов:

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

Two fzx output terminals are created, one with font "Prefect" and another with font "RoundelSerif". There is one input terminal attached to the output terminal with the smaller font.

The same random text is printed to both output terminals and at random intervals, text is read from the keyboard and written to the other output terminal.

To make this demo, I created a new crt with two output terminals and one input terminal. We create crts using m4 macros. The template I used is:

http://z88dk.cvs.sourceforge.net/vie....1&view=markup

which is a template for the 48k ram zx. I replaced lines 73-84 with my own driver instantiations:

[свернуть]

Код:

---

include(../../clib_instantiate_begin.m4)

include(../driver/terminal/zx_01_input_kbd_inkey.m4)dnl
m4_zx_01_input_kbd_inkey(_stdin, __i_fcntl_fdstruct_1, 0x03b0, 64, 1, 500, 15)dnl

include(../driver/terminal/zx_01_output_fzx.m4)dnl
m4_zx_01_output_fzx(_window_1, 0x2330, 0, 0, 1, 14, 1, 19, 0, _ff_ao_Prefect, 14, 0, 14, 8, 112, 8, 152, 1, 0, 3, 0)dnl

include(../driver/terminal/zx_01_output_fzx.m4)dnl
m4_zx_01_output_fzx(_window_2, 0x2330, 0, 0, 16, 14, 3, 19, 0, _ff_ao_RoundelSerif, 26, 0, 26, 128, 112, 24, 152, 1, 0, 3, 0)dnl

include(../../clib_instantiate_end.m4)

---

Эти драйверы относятся к файловым дескрипторам 0, 1, 2 и данного файла * по имени стандартного устройства ввода, window_1 и window_2. Аргументы двумя выходными клеммами определить окно, цвет, шрифт и указать, что окно будет прокручиваться, не останавливаясь.

После определения того, что водители экземпляра, я сделал ЭЛТ, запустив m4 на него и создания ЭЛТ с уникальным именем:

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

These drivers are assigned to file descriptors 0, 1, 2 and are given FILE* named stdin, window_1 and window_2. The arguments to the two output terminals define the window, colour, font and indicate that the window will scroll without pausing.

After defining what drivers are instantiated, I made the crt by running m4 on it and creating the crt with a unique name:

[свернуть]

m4 zx_crt_ram.m4 > zx_crt_200.asm

Затем я добавил zx_crt_200 к файлу zx_crt.asm используемой серии ZX цели:

http://z88dk.cvs.sourceforge.net/vie...13&view=markup

путем вставки этого в файле:

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

I then added zx_crt_200 to the zx_crt.asm file used by the zx target:

http://z88dk.cvs.sourceforge.net/vie...13&view=markup

by inserting this into the file:

[свернуть]

Код:

---

IF startup = 200

  ; three terminal windows on screen
  ;
  ; stdin    = zx_01_input_kbd_inkey (connected to window_1)
  ; window_1 = fzx terminal (font = Prefect)
  ; window_2 = fzx terminal (font = RoundelSerif)
 
  INCLUDE "startup/zx_crt_200.asm"

ENDIF

---

Имея это в месте, где я могу выбрать, что ЭЛТ с "-startup = 200" на линии компиляции.

Программа C прост:

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

With that in place I can select that crt with "-startup=200" on the compile line.

The C program is simple:

[свернуть]

Код:

---

// sccz80
// zcc +zx -vn -startup=200 -clib=new fzx_term2.c -o fzx_term2
//
// sdcc
// zcc +zx -vn -startup=200 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 fzx_term2.c -o fzx_term2

#include <stdio.h>
#include <stropts.h>
#include <arch/spectrum.h>
#include <stdlib.h>
#include <string.h>

extern FILE *window_1;
extern FILE *window_2;

main()
{
  static int i;
  static char buffer[100];

  zx_border(INK_BLACK);
  zx_cls(INK_GREEN | PAPER_GREEN);

  ioctl(1, IOCTL_OTERM_CLS);
  ioctl(2, IOCTL_OTERM_CLS);

  while (1)
  {
      // fill buffer with random letters
     
      memset(buffer, 0, 100);
     
      for (i = rand() % 100; i >= 0; --i)
        buffer[i] = (char)((rand() % ('z' - ' ')) + ' ');
     
      // print to both windows
     
      fprintf(window_1, "%s\n", buffer);
      fprintf(window_2, "%s\n", buffer);
     
      // gather input
     
      if (rand() > 32200)
      {
        fprintf(window_1, "\nEnter some text: ");
       
        fflush(stdin);
        scanf("%99[^\n]", buffer);
       
        i = ioctl(2, IOCTL_OTERM_FCOLOR, INK_YELLOW | PAPER_BLUE);
        fprintf(window_2, "\n%s\n\n", buffer);
        ioctl(2, IOCTL_OTERM_FCOLOR, i);
      }
  }
}

---

Вы можете видеть, что вы можете печатать на клеммах определенных ЭЛТ, и вы можете настроить терминалов во время выполнения с помощью IOCTL ().

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

Я не ожидал, что кто следуют за этим, это просто указание на различие между минимальным едва функциональной библиотеки (SDCC) или простой зависит от операционной системы (HiTech) и одной, которая пытается быть полным (z88dk).

При сравнении размеров кода, вы также должны иметь в виду, компилятор, как ВЫСОКОТЕХНОЛОГИЧНЫЙ полагается на операционную систему для обеспечения функциональности. Таким образом, ее бинарные может занять определенный размер, но это также делает использование кода операционной системы, которые могут быть 8k или более в размере, который скрыт от выходного двоичного файла. бинарные z88dk являются полностью независимыми и могут существовать отдельно от любой операционной системы. У вас есть возможность писать драйверы, использующие программное обеспечение системы, но мы не сделали, что еще для новой библиотеки.

В ZIP Вы также можете сравнить выход АНМ, порожденную SDCC и sccz80 по исследуются файлы "fzx_term2_sdcc.asm" и "fzx_term2_sccz80.opt". В этом случае SDCC скомпилированные бинарные файлы 13514 байт и sccz80 скомпилированные бинарные файлы 13185 байт. При использовании статических переменных, я сделал sccz80 произвели код лучше. Другие различия связаны с SDCC необходимости IX сохранились и конвенций призвание sccz80 быть гораздо лучше.

Далее ~ 5k может быть сбрил, делая то же рода вещей, которые я сделал в прошлом посте.

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

You can see that you can print to the terminals defined by the crt and you can configure the terminals at runtime via ioctl().

I can see a bug in the terminal code in that attributes are being affected below the text windows. It may be an error in the fonts or in the fzx driver that I will have to look into.

I don't expect anyone to follow this, it's just an indication of the difference between a minimal barely functional library (sdcc) or a simple one reliant on the operating system (hitech) and one that tries to be complete (z88dk).

When comparing code sizes, you also have to keep in mind a compiler like hitech is relying on the operating system to provide functionality. So its binaries may occupy a certain size but it's also making use of operating system code that might be 8k or more in size that is hidden from the output binary. z88dk's binaries are completely independent and can exist apart from any operating system. You do have the option to write drivers that use the system software but we haven't done that yet for the new library.

In the zip you can also compare the asm output generated by sdcc and sccz80 by examing the files "fzx_term2_sdcc.asm" and "fzx_term2_sccz80.opt". In this case the sdcc-compiled binary is 13514 bytes and the sccz80-compiled binary is 13185 bytes. By using static variables, I've made sccz80's produced code better. The other differences have to do with sdcc needing ix preserved and the calling conventions of sccz80 being much better.

A further ~5k can be shaved off by doing the same sorts of things I did in the last post.

[свернуть]