Вид для печати
В компилятор SDCC (начиная с ревизии #6588), добавлен новый регистровый оптимизатор, который генерит более компактный код z80.
По заявлянию автора нового оптимизатора Philipp Klaus Krause, в теперешнем виде, этот оптимизатор уже сравнялся по размеру генерируемого кода, с компилером HITECH-C 7.80PL2
(Также уже запланированы всячиские новые улучшения для оптимизатора.)
Сам оптимизатор был запланирован уже давно.
во во только сейчас и сравняли
Вообще то это совсем не "сейчас", сейчас уже r7037. А эти тесты у Филипа висят уже порядочно. И если бы у jerri было желание, он бы увидел, что ещё задолго до этого sdcc уже в некоторых тестах драл хайтек. =)
Ну и как обычно - всегда можно найти тест, который завалит кого надо.
хайтек да завалит :) а ручную работу - никогда!
А кто вручную C в ASM Z80 компилит?Цитата:
Сообщение от jerri
тонко :)Цитата:
Сообщение от siril
да были люди в наше времяЦитата:
Сообщение от siril
Мдя. А кто-то в АLASM-е, Tasm-е кодит? Знаю одного - tiboh. Это Тасм. Я в Аласм. А кто ещё кодит в Спековских ассемблерах?Цитата:
Сообщение от siril
На спекрумовских ассемблерах (или на не-спектрумовских кросс-ассемблерах) кодят практически все, кто зашёл дальше бейсика =)Цитата:
Сообщение от VNN_KCS
Но я впервые слышу о странной методологии написать в спектрумовском ассемблере исходник на си, а затем вручную его перевести в asm z80.
Обычно такие вещи сразу пишутся на асме, без промежуточных этапов типа си, так как при современных техниках оптимизации с широким использованием самомодифицирующегося кода и метапрограммирования, невозможно корректно и однозначно выразить все эти приёмы.
Каркас алгоритма можно, разумеется, написать на языке высокого уровня, но это будет прототипированием. А последующая реализация на асме - не будет являться "ручной компиляцией".
Макросы могут дать более высокий уровень абстракции, но это далеко не уровень си =)
---------- Post added at 10:26 ---------- Previous post was at 10:22 ----------
P.S.Люди, а кто-то LLVM к z80 приспособил? ^_^
В SDCC теперь есть поддержка работы с Си данными, в разных банках памяти. Реализовано это через стандартный Embedded C механизм "Named address spaces".
Пример:
void set_bank0(void); // функция включения банка 0
void set_bank1(void); // функция включения банка 1
__addressmod set_bank0 space_bank0; // "Именованное адресное пространство" space_bank0, которое использует ф-цию set_bank0
__addressmod set_bank1 space_bank1; // "Именованное адресное пространство" space_bank1, которое использует ф-цию set_bank1
space_bank0 int x; // int в адресном пространстве space_bank0
space_bank1 int* y; // указатель на int в адресном пространстве space_bank1
space_bank0 int *space_bank1 z; // указатель в адресном пространстве space_bank1, который указывает на на int, в адресном пространстве space_bank0
Суть метода:
SDCC автоматически вызывает необходимую функцию при доступе (чтение или запись) к переменной. (Функция должна подключить нужную банку в адресное пространство CPU. )
Manual.
Ветка обсуждения из sdcc-user mail list (есть пример кода).
1 а что если при включении нужной банки она уже и так включенна?
2 а что если вместе с ней выключиться кусок стека или кода на который указывает вектор прерывания или который сейчас выполняется?
Лучше б они возможность размещать глобальные переменные в кодовом сегменте сделали. Объявлять нужные переменные константами и обращаться к ним через указатели очень не айс. Есть какой-то макрос для этого, но для z80 он не работает.
Компилятор вставляет минимально необходимое кол-во вызовов функции переключения банка. (это в мануале написано: SDCC inserts the minimum possible number calls to the bank selection functions. )Цитата:
Сообщение от bigral
Программист в ответе за правильный setup памяти (где код/данные/стек).Цитата:
Сообщение от bigral
Просто нужно, один раз, правильно сконфигурить раскладку памяти для программы и юзать.
А чем не нравится обычное расположение переменных в сегменте данных ?Цитата:
Сообщение от Eltaron
Цитата:
Сообщение от Eltaron
Цитата:
Сообщение от Valen
Цитата:
Сообщение от Eltaron
Цитата:
Сообщение от Valen
Да, получается так.Цитата:
Сообщение от Eltaron
Я пару месяцев назад начал патчить sdcc, чтоб научить его генерировать asm-код, совместимый с ассемблером из GNU binutils for z80. Если закончу, можно будет линковаться через обычные объектные файлы в coff-формате.
Интересная мысль.Цитата:
Сообщение от Eltaron
(На досуге гляну, какой там синтаксис/возможности у асм-а из binutils-z80.)
Тем, что они инициализируются при старте. На килобайт данных три килобайта кода инициализации. Константы же сразу инициализированными создаются, через DEFB. Но в константы писать нельзя, и приходится извращатьсяЦитата:
Сообщение от Valen
Примерчик, чтобы был.
Ситуация:
В видео-памяти лежит 15 фонтов, размером 8x8 (1байт на пиксел). Фонты занимают 12 страниц видео памяти (0-11).
(Любую страницу видео-памяти, можно подключить в 8KB адресное окно z80 и затем уже в этом окне, z80 может работать с видео-памятью.)
Нужно:
Пройтись по этим фонтам и присвоить не-нулевым пикселям нужный цвет. Цвет для каждого фонта разный, рассчитывается по ходу дела.
Заметка:
4 байта локальных переменных легло на регистры z80.
Остальные переменные объявлены как static, что ускорит обращение к ним через константный адрес, а не через стэк и ix (например ld a,(ix+1) )
Код:#define FONT_8x8_SIZE (96UL*8*8) // chunky font size
void Display_SetFontPixelColors(void)
{
BYTE* pFont = (BYTE*)VIDEO_BASE;
WORD counter = 0;
static BYTE fontColor = 1;
static BYTE video_page = 0;
PAGE_IN_VIDEO_RAM();
SET_VIDEO_PAGE(video_page);
while(video_page < 12) {
// modify pixel
if(*pFont)
*pFont = fontColor; // if pixel is not zero, set pixel to font color
pFont++;
if(pFont >= (BYTE*)VIDEO_BASE + 0x2000) {
pFont = (BYTE*)VIDEO_BASE;
video_page++; // inc video page
SET_VIDEO_PAGE(video_page);
}
counter++;
if(counter >= (WORD)FONT_8x8_SIZE) {
counter = 0;
fontColor++; // inc font color
}
}
PAGE_OUT_VIDEO_RAM();
}
Код:; ---------------------------------
; Function Display_SetFontPixelColors
; ---------------------------------
_Display_SetFontPixelColors_start::
_Display_SetFontPixelColors:
;src/fs/display_tilemap.c:409: BYTE* pFont = (BYTE*)VIDEO_BASE;
ld de,#0x2000
;src/fs/display_tilemap.c:410: WORD counter = 0;
ld bc,#0x0000
;src/fs/display_tilemap.c:416: PAGE_IN_VIDEO_RAM();
in a,(_io__sys_mem_select)
set 6, a
out (_io__sys_mem_select),a
;src/fs/display_tilemap.c:417: SET_VIDEO_PAGE(video_page);
ld a,(#_Display_SetFontPixelColors_video_page_1_122 + 0)
;src/fs/display_tilemap.c:419: while(video_page < 12) {
ld (#_mm__vreg_vidpage + 0),a
00107$:
ld iy,#_Display_SetFontPixelColors_video_page_1_122
ld a,0 (iy)
sub a, #0x0C
jr NC,00109$
;src/fs/display_tilemap.c:421: if(*pFont)
ld a,(de)
or a, a
jr Z,00102$
;src/fs/display_tilemap.c:422: *pFont = fontColor; // if pixel is not zero, set pixel to font color
ld a,(#_Display_SetFontPixelColors_fontColor_1_122 + 0)
ld (de),a
00102$:
;src/fs/display_tilemap.c:423: pFont++;
inc de
;src/fs/display_tilemap.c:424: if(pFont >= (BYTE*)VIDEO_BASE + 0x2000) {
ld a,d
sub a, #0x40
jr C,00104$
;src/fs/display_tilemap.c:425: pFont = (BYTE*)VIDEO_BASE;
ld de,#0x2000
;src/fs/display_tilemap.c:426: video_page++; // inc video page
ld iy,#_Display_SetFontPixelColors_video_page_1_122
inc 0 (iy)
;src/fs/display_tilemap.c:427: SET_VIDEO_PAGE(video_page);
ld a,0 (iy)
ld iy,#_mm__vreg_vidpage
ld 0 (iy),a
00104$:
;src/fs/display_tilemap.c:430: counter++;
inc bc
;src/fs/display_tilemap.c:431: if(counter >= (WORD)FONT_8x8_SIZE) {
ld a,b
sub a, #0x18
jr C,00107$
;src/fs/display_tilemap.c:432: counter = 0;
ld bc,#0x0000
;src/fs/display_tilemap.c:433: fontColor++; // inc font color
ld iy,#_Display_SetFontPixelColors_fontColor_1_122
inc 0 (iy)
jr 00107$
00109$:
;src/fs/display_tilemap.c:438: PAGE_OUT_VIDEO_RAM();
in a,(_io__sys_mem_select)
and a, #0xBF
out (_io__sys_mem_select),a
ret
_Display_SetFontPixelColors_end::
Valen, ты на будущее сразу сюда пиши все интересные фичи SDCC, если что полезное добавили, чтобы не плодить кучу тем.
Посмотрел на этот кусок кода и подумал (субьективное мнение):
1. довольно неплохо генерит код, могло быть и хуже раза в 2...4 (как в других компилерах);
2. для какой нибудь навороченной проги (длинной в 512кб готового кода) sdcc сократит время разработки в 3..4 раза, по сравнению например с написанной на макро-ассемблере;
3. руками allocated регистры + оптимизация в макро-ассемблере могут потенциально дать ускорение максимум в 2...3 раза ну или сокращение самого кода в 2...3 раза (сомневаюсь что для большенства случаев можно будет одновременно получить и первое и второе), конечно при ручном написании легче найти компромис между скоростью и обьемом;
4. "вставки" на асме никто не отменял;
5. для игрушек и дем не годится так как там надо выжимать "последние соки", но писать OS и всякую productivity байду для спектрума вполне можно на этом SDCC;
А как он по памяти этот код раскидывать будет?Цитата:
Сообщение от bigral
Серьезно? Всё что я писал на спектрум из игр могло быть написано и на SDCC и выглядело бы так же.Цитата:
Сообщение от bigral
А если сделать игровой фреймворк то вообще разницы не будет.
Основное же время тратиться на работу с графикой.
И если ты вместо того что бы :
fox x=1 to 16
for y 1 to 12
drawtile(x,y, tile )
next y
next x
Сделаешь DrawTileMap(x,y,w,h,map+ofset) то разница между асмом будет минимальна.
;) гы! он этого делать за тебя не будет, он только ASM исходник на выходе даст.Цитата:
Сообщение от alone
А дальше сам компилируй, придумывай как связать свои функции, выдумывай какой-то там самопальный OBJ формат, отдельно добавляй туда .data и .bss блоки, смотри за переключением страниц, загрузку модулей, memory manager и т.д.
Короче вывод - SDCC не runtime и не OS для малых систем а всего лишь C compiler для них.
Всем привет!
Вопрос тем знатокам, кто пользуется SDCC.
Пишу программу helloworld для CP/M, использую опцию --no-std-crt0 и модуль crt0 от MSXDOS (на самом деле это не принципиально, так, для привязки)
Вопрос: Что должно быть в кодовом блоке соответствующем секции GSINIT и кто заполняет эту секцию?
В собранном коде я получаю такое:
Соответственно, при выполнения вместо инициализации структур, должной происходить в секции, получаем call в область из пяти байтов 0FFh, рестарт на адрес 38h и зависон, т.к. в CP/M по этому адресу лежит мусор.Код:код модуля crt0
.....
0100 call gsinit
0103 some_code
.....
.area _CODE
.....
код модуля helloworld
.....
.area _DATA
.....
gsinit: .area _GSINIT
XXX0 rst38
XXX1 rst38
XXX2 rst38
XXX3 rst38
XXX4 rst38
XXX5 ret
hex2bin v1.0.1, Copyright (C) 1999 Jacques Pelletier
Lowest address = 0x00000100
Highest address = 0x000011EE
0 1 2 3 4 5 6 7 8 9 A B C D E
00000100: CD E9 11
...
000011E0: 56 07 DD F9 DD E1 C9 00 00 FF FF FF FF FF C9
Что я делаю не так?
Какие-то опции не указал? Как я компилирую - см. во вложении.
Инициализация global'ов и static'овЦитата:
Сообщение от Error404
Если глянуть внутрь линкуемых .rel-файлов, будет видно, какому модулю принадлежит эта лажа.
Где есть, везде имеет видЦитата:
Сообщение от Eltaron
Ничего не понимаю. Какого хека оно кладет мне в бинарь 5 рестартов в области инициализации?Код:A _GSINIT size 0 flags 0 addr 0
Почему исходник в 100 строк (из которых половина - ассемблер) линкуется в 4кб бинарь? Я не использую никакие стандартные либы, указываю явно только собственные rel-ы от своих исходников.
Что-то тяжко начинать с sdcc после нормальных компилеров. :)
Тогда мне скорее непонятно откуда этот call взялся.
Вообще, sdcc не спрашивает про точку входа, игнорирует main, и всегда в начало бинарника кладет первую функцию первого файла. Поэтому я, дабы с ним не бороться, просто первой функцией кладу
Но в случае, когда GSINIT не пустой, это не сработает.Код:void main_jump() __naked
{
jp _main
}
Может где-нибудь явно ORG указано? Тогда промежуток между участками кода нулями забивается.Цитата:
Почему исходник в 100 строк (из которых половина - ассемблер) линкуется в 4кб бинарь? Я не использую никакие стандартные либы, указываю явно только собственные rel-ы от своих исходников.
Еще если используются инициализированные массивы, то код тоже разрастается до гигантских размеров - но это как раз за счет GSINIT.
Совершенно справедливый вопрос, этот call - рукотворный, он из самописного модуля crt0cpm.s (которым я меняю штатный crt0.rel)Цитата:
Сообщение от Eltaron
Просто как оказалось, в современном SDCC в области инита за каким-то хреном сначала зачем-то всегда идет поле в 5 кодов 0FFh, а уже затем код инициализации. Когда я это поле в 5 кодов 0FFh стал пропускать, все стало инициализироваться как надо и работает как надо, т.е. можно считать, что катомизация для CP/M есть.
Массивы пока не использую (пример пока что простейший - с одним printf, тоже самописным - небольшим). ORG имеется - в crt0cpm.s (в ассеблерном модуле) перво-наперво делается "org 0x100" - это нормально, все CP/M-овские программы имеют стартовый адрес 100h. Но даже если и из-за него, 100h это 256байт, а не 4кб.Цитата:
Сообщение от Eltaron
Откуда же эти 4к оверхеда? :v2_confu: Весь мой код (как ассемблерный, так и С-шныий) я в бинарнике вижу (и в отладчике прошагал), он весь в начале файла - 3 сотни байт. За ним идет 4кб какого-то мусора и уже затем в конце файла код инициализации переменных (в моем примере это всего десяток байт). Общий размер файла бинарника 4,3кб. Отчего такое может быть?
А ты загляни в .map, там всё побайтно расписано, с какого адреса какая функция. Судя по всему, компилятор прилепил всю арифметику для long. Функция kprint использует ltoa, а последняя - всю остальную арифметику.Цитата:
Сообщение от Error404
Увы мне!Цитата:
Сообщение от b2m
Это действительно частично мой код (от всяческих моих самописных printf-ов), а частично математические функции.
Маленькая программа (во вложении), не использующая никакие модули кроме crt0cpm вышла всего в 300 байт.
Вообще, конечно, удручает. Два экрана кода на С (моих самописных printf-ов) транслируется в 3 с гаком кб кода. CP/M-овский Hitech C 3.06 образца 1987 года компилировал этот же самый код моих самописных printf-ов куда как компактнее (раза в два примерно).
а у HITECH long какой длины был?Цитата:
Сообщение от Error404
у sdcc - 32 бита, отсюда и громоздкость
тоже 32 бита. один из немногих СРМ-овских кто умел 32 бита лонг
Ещё раз увы тебе :)Цитата:
Сообщение от Error404
Посмотрим внимательнее на твой .map
Код test1
начало 017D конец 01AE длина 49 байт
Код conio
начало 01FF конец 09DB длина 2012 байт
Код dos
начало 09DB конец 0AA9 длина 206 байт
Из библиотеки Z80.rel
начало 0AA9 конец 124C длина 1955 байт!
---------- Post added at 23:35 ---------- Previous post was at 23:28 ----------
Последние 2Кб из-за того, что conio ссылается на:
__moduint_rrx_s
__divuint_rrx_s
__modslong_rrx_s
__divslong_rrx_s
А они ведут в stubs.rel из z80.lib. А там какая-то фигня, когда подцепляется этот модуль, то за ним тянется вся арифметика. Причём в самом модуле лишь переходы на реальные процедуры, перед которыми иногда присутствуют команды LD A,5 / RST 8. Так что, если написать свою арифметику, то будет компактнее.
выкинув из printf все связанное с long, получил уменьшение кода с 4к до 2к.Цитата:
Сообщение от b2m
Не, нафиг. Тогда уж проще сразу писать на ассемблере с макросами :)Цитата:
Сообщение от b2m
Я компилер ищу не для того, чтобы его еще наполовину переписывать, это не интересно.
Так доооолго компилирует. Буквально часами исходный файлик на полста килобайт. Комп селерон2дуо (2 ядра каждое по 2ГГц). Кто знает отчего это, и можно с этим что-нибудь сделать?
>селерон<
Под виндой так сразу сказать сложно, под линуксом я бы попробовал пересобрать sdcc с graphite(и его плюшками), -march=native, -O3 и перекинуть его в рамдиск.
А вот чем оно несколько часов занималось.Цитата:
Сообщение от Error404
Кроме того что долго, оно на выходе еще дает полный *****кретинизм (см. asm во вложении).
Для массив static char [] оно сначала делает нужного размера .ds N (кусок пустого места) в сегменте _DATA (т.е. в бинаре), потом в секции _GSINIT копирует туда данные ПОБАЙТНО в конструкции вида:
;fsdata.c:11: static char data_cgi_files[] = {
ld hl,#_data_cgi_files
ld (hl),#0x2F
inc hl
ld (hl),#0x63
ld hl,#_data_cgi_files + 2
ld (hl),#0x67
ld hl,#_data_cgi_files + 3
ld (hl),#0x69
ld hl,#_data_cgi_files + 4
ld (hl),#0x2F
и так несколько тысяч раз
Вместо того чтобы единократно СРАЗУ определить заполненный массив через .db
Вопрос - что за кретины это сочиняли? Я уже смирился со "студенческими" болезнями компилятора (на энтузиазме пишется какими-то непонятными людьми, понятно что не приходится ждать оттуда профессионального компилятора, которые умудрялись работать на Z80 и в 48к ОЗУ в середине прошлого века), но такое явное УГ это уже перебор. :)
2 страницы назад уже обсуждали
const поставь
зашибись. Оттого что у авторов бардак в голове, теперь во всех исходниках определение строк править... Ну, поправлю конечно, куда я денусь то.