SDCC - Small Device C Compiler

[bigral]

Посмотрел на этот кусок кода и подумал (субьективное мнение):

1. довольно неплохо генерит код, могло быть и хуже раза в 2...4 (как в других компилерах);

2. для какой нибудь навороченной проги (длинной в 512кб готового кода) sdcc сократит время разработки в 3..4 раза, по сравнению например с написанной на макро-ассемблере;

3. руками allocated регистры + оптимизация в макро-ассемблере могут потенциально дать ускорение максимум в 2...3 раза ну или сокращение самого кода в 2...3 раза (сомневаюсь что для большенства случаев можно будет одновременно получить и первое и второе), конечно при ручном написании легче найти компромис между скоростью и обьемом;

4. "вставки" на асме никто не отменял;

5. для игрушек и дем не годится так как там надо выжимать "последние соки", но писать OS и всякую productivity байду для спектрума вполне можно на этом SDCC;

[alone]

для какой нибудь навороченной проги (длинной в 512кб готового кода)

А как он по памяти этот код раскидывать будет?

[newart]

5. для игрушек и дем не годится так как там надо выжимать "последние соки", но писать OS и всякую productivity байду для спектрума вполне можно на этом SDCC;

Серьезно? Всё что я писал на спектрум из игр могло быть написано и на SDCC и выглядело бы так же.

А если сделать игровой фреймворк то вообще разницы не будет.
Основное же время тратиться на работу с графикой.
И если ты вместо того что бы :

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) то разница между асмом будет минимальна.

[bigral]

А как он по памяти этот код раскидывать будет?

гы! он этого делать за тебя не будет, он только ASM исходник на выходе даст.

А дальше сам компилируй, придумывай как связать свои функции, выдумывай какой-то там самопальный OBJ формат, отдельно добавляй туда .data и .bss блоки, смотри за переключением страниц, загрузку модулей, memory manager и т.д.

Короче вывод - SDCC не runtime и не OS для малых систем а всего лишь C compiler для них.

[Error404]

Всем привет!

Вопрос тем знатокам, кто пользуется SDCC.
Пишу программу helloworld для CP/M, использую опцию --no-std-crt0 и модуль crt0 от MSXDOS (на самом деле это не принципиально, так, для привязки)

Вопрос: Что должно быть в кодовом блоке соответствующем секции GSINIT и кто заполняет эту секцию?

В собранном коде я получаю такое:

код модуля 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

Соответственно, при выполнения вместо инициализации структур, должной происходить в секции, получаем call в область из пяти байтов 0FFh, рестарт на адрес 38h и зависон, т.к. в CP/M по этому адресу лежит мусор.

Что я делаю не так?
Какие-то опции не указал? Как я компилирую - см. во вложении.

[Eltaron]

Вопрос: Что должно быть в кодовом блоке соответствующем секции GSINIT и кто заполняет эту секцию?

Инициализация global'ов и static'ов

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

[Error404]

Инициализация global'ов и static'ов

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

Где есть, везде имеет вид

A _GSINIT size 0 flags 0 addr 0

Ничего не понимаю. Какого хека оно кладет мне в бинарь 5 рестартов в области инициализации?
Почему исходник в 100 строк (из которых половина - ассемблер) линкуется в 4кб бинарь? Я не использую никакие стандартные либы, указываю явно только собственные rel-ы от своих исходников.
Что-то тяжко начинать с sdcc после нормальных компилеров.

[Eltaron]

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

void main_jump() __naked 
{
 jp _main
}

Но в случае, когда GSINIT не пустой, это не сработает.

Почему исходник в 100 строк (из которых половина - ассемблер) линкуется в 4кб бинарь? Я не использую никакие стандартные либы, указываю явно только собственные rel-ы от своих исходников.

Может где-нибудь явно ORG указано? Тогда промежуток между участками кода нулями забивается.
Еще если используются инициализированные массивы, то код тоже разрастается до гигантских размеров - но это как раз за счет GSINIT.

[Error404]

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

void main_jump() __naked 
{
 jp _main
}

Но в случае, когда GSINIT не пустой, это не сработает.

Совершенно справедливый вопрос, этот call - рукотворный, он из самописного модуля crt0cpm.s (которым я меняю штатный crt0.rel)
Просто как оказалось, в современном SDCC в области инита за каким-то хреном сначала зачем-то всегда идет поле в 5 кодов 0FFh, а уже затем код инициализации. Когда я это поле в 5 кодов 0FFh стал пропускать, все стало инициализироваться как надо и работает как надо, т.е. можно считать, что катомизация для CP/M есть.

Может где-нибудь явно ORG указано? Тогда промежуток между участками кода нулями забивается.
Еще если используются инициализированные массивы, то код тоже разрастается до гигантских размеров - но это как раз за счет GSINIT.

Массивы пока не использую (пример пока что простейший - с одним printf, тоже самописным - небольшим). ORG имеется - в crt0cpm.s (в ассеблерном модуле) перво-наперво делается "org 0x100" - это нормально, все CP/M-овские программы имеют стартовый адрес 100h. Но даже если и из-за него, 100h это 256байт, а не 4кб.

Откуда же эти 4к оверхеда? Весь мой код (как ассемблерный, так и С-шныий) я в бинарнике вижу (и в отладчике прошагал), он весь в начале файла - 3 сотни байт. За ним идет 4кб какого-то мусора и уже затем в конце файла код инициализации переменных (в моем примере это всего десяток байт). Общий размер файла бинарника 4,3кб. Отчего такое может быть?

[b2m]

Откуда же эти 4к оверхеда?

А ты загляни в .map, там всё побайтно расписано, с какого адреса какая функция. Судя по всему, компилятор прилепил всю арифметику для long. Функция kprint использует ltoa, а последняя - всю остальную арифметику.