SDCC - Small Device C Compiler [Архив] - Speccy

Valen

20.11.2011, 02:56

В компилятор SDCC (начиная с ревизии #6588), добавлен новый регистровый оптимизатор, который генерит более компактный код z80.
По заявлянию (https://sourceforge.net/apps/trac/sdcc/wiki/Philipp%27s%20TODO%20list) автора нового оптимизатора Philipp Klaus Krause, в теперешнем виде, этот оптимизатор уже сравнялся по размеру генерируемого кода, с компилером HITECH-C 7.80PL2
(Также уже запланированы всячиские новые улучшения для оптимизатора.)

Сам оптимизатор был запланирован (https://sourceforge.net/tracker/?func=detail&aid=3059743&group_id=599&atid=350599) уже давно.

jerri

20.11.2011, 09:12

во во только сейчас и сравняли

NovaStorm

20.11.2011, 11:44

Вообще то это совсем не "сейчас", сейчас уже r7037. А эти тесты у Филипа висят уже порядочно. И если бы у jerri было желание, он бы увидел, что ещё задолго до этого sdcc уже в некоторых тестах драл хайтек. =)
Ну и как обычно - всегда можно найти тест, который завалит кого надо.

jerri

20.11.2011, 14:31

хайтек да завалит :) а ручную работу - никогда!

siril

21.11.2011, 10:52

хайтек да завалит :) а ручную работу - никогда!

А кто вручную C в ASM Z80 компилит?

breeze

21.11.2011, 13:55

А кто вручную C в ASM Z80 компилит?

тонко :)

jerri

21.11.2011, 14:50

А кто вручную C в ASM Z80 компилит?

да были люди в наше время

VNN_KCS

22.11.2011, 00:38

А кто вручную C в ASM Z80 компилит?
Мдя. А кто-то в АLASM-е, Tasm-е кодит? Знаю одного - tiboh. Это Тасм. Я в Аласм. А кто ещё кодит в Спековских ассемблерах?

siril

22.11.2011, 08:26

Мдя. А кто-то в АLASM-е, Tasm-е кодит? Знаю одного - tiboh. Это Тасм. Я в Аласм. А кто ещё кодит в Спековских ассемблерах?

На спекрумовских ассемблерах (или на не-спектрумовских кросс-ассемблерах) кодят практически все, кто зашёл дальше бейсика =)

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

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

Каркас алгоритма можно, разумеется, написать на языке высокого уровня, но это будет прототипированием. А последующая реализация на асме - не будет являться "ручной компиляцией".

Макросы могут дать более высокий уровень абстракции, но это далеко не уровень си =)

---------- Post added at 10:26 ---------- Previous post was at 10:22 ----------

P.S.Люди, а кто-то LLVM к z80 приспособил? ^_^

Valen

18.02.2012, 18:42

В 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 (http://sdcc.sourceforge.net/doc/sdccman.html/node64.html).
Ветка (http://sourceforge.net/mailarchive/forum.php?thread_name=4EC15590.9030605%40spth.de&forum_name=sdcc-user) обсуждения из sdcc-user mail list (есть пример кода).

bigral

19.02.2012, 02:46

1 а что если при включении нужной банки она уже и так включенна?
2 а что если вместе с ней выключиться кусок стека или кода на который указывает вектор прерывания или который сейчас выполняется?

Eltaron

19.02.2012, 16:37

Лучше б они возможность размещать глобальные переменные в кодовом сегменте сделали. Объявлять нужные переменные константами и обращаться к ним через указатели очень не айс. Есть какой-то макрос для этого, но для z80 он не работает.

Valen

19.02.2012, 16:49

1 а что если при включении нужной банки она уже и так включенна?
Компилятор вставляет минимально необходимое кол-во вызовов функции переключения банка. (это в мануале написано: SDCC inserts the minimum possible number calls to the bank selection functions. )

2 а что если вместе с ней выключиться кусок стека или кода на который указывает вектор прерывания или который сейчас выполняется?
Программист в ответе за правильный setup памяти (где код/данные/стек).
Просто нужно, один раз, правильно сконфигурить раскладку памяти для программы и юзать.

Valen

21.02.2012, 01:31

Лучше б они возможность размещать глобальные переменные в кодовом сегменте сделал
А чем не нравится обычное расположение переменных в сегменте данных ?

Valen

26.02.2012, 17:03

попутно вспомнил, чем еще раздражает sdcc - решетками # перед числами в асме. Мозг отказывается воспринимать такие числа не как hex

Да, есть такая бяка.
Поэтому использую sdcc asm, только для маленьких inline кусочков асм кода.
Если нужно кодить на асме много, просто юзаю другой асм компилятор (с более удобным синтаксисом) и затем уже линкую скомпиленный асмом бинарь к бинарю sdcc.

а как, руками? там форматы все какие-то самописные и ни с чем не совместимые вроде бы

Да, руками бинарники объединяю.
(например, вызываю bin2c для асмовского бинарника и потом просто #include в sdcc Си файл или же загружаю файл асмовского бинарника, при старте программы)

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

Да, получается так.

Eltaron

26.02.2012, 18:18

Valen

26.02.2012, 20:34

Я пару месяцев назад начал патчить sdcc, чтоб научить его генерировать asm-код, совместимый с ассемблером из GNU binutils for z80. Если закончу, можно будет линковаться через обычные объектные файлы в coff-формате.
Интересная мысль.

(На досуге гляну, какой там синтаксис/возможности у асм-а из binutils-z80.)

Eltaron

27.02.2012, 01:04

А чем не нравится обычное расположение переменных в сегменте данных ?

Тем, что они инициализируются при старте. На килобайт данных три килобайта кода инициализации. Константы же сразу инициализированными создаются, через DEFB. Но в константы писать нельзя, и приходится извращаться

Valen

18.03.2012, 21:13

Примерчик, чтобы был.

Ситуация:
В видео-памяти лежит 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::

Shadow Maker

18.03.2012, 22:19

Valen, ты на будущее сразу сюда пиши все интересные фичи SDCC, если что полезное добавили, чтобы не плодить кучу тем.

bigral

19.03.2012, 03:47

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

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

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

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

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

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

alone

19.03.2012, 08:51

для какой нибудь навороченной проги (длинной в 512кб готового кода)
А как он по памяти этот код раскидывать будет?

newart

19.03.2012, 11:02

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

19.03.2012, 23:30

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

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

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

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

Error404

28.03.2012, 15:13

Всем привет!

Вопрос тем знатокам, кто пользуется 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

28.03.2012, 15:39

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

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

Error404

28.03.2012, 16:12

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

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

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

A _GSINIT size 0 flags 0 addr 0

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

Eltaron

28.03.2012, 16:33

Error404

28.03.2012, 19:28

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

b2m

28.03.2012, 19:42

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

Error404

28.03.2012, 20:06

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

Увы мне!
Это действительно частично мой код (от всяческих моих самописных printf-ов), а частично математические функции.
Маленькая программа (во вложении), не использующая никакие модули кроме crt0cpm вышла всего в 300 байт.

Вообще, конечно, удручает. Два экрана кода на С (моих самописных printf-ов) транслируется в 3 с гаком кб кода. CP/M-овский Hitech C 3.06 образца 1987 года компилировал этот же самый код моих самописных printf-ов куда как компактнее (раза в два примерно).

Eltaron

28.03.2012, 20:14

CP/M-овский Hitech C 3.06 образца 1987 года компилировал этот же самый код моих самописных printf-ов куда как компактнее (раза в два примерно).
а у HITECH long какой длины был?
у sdcc - 32 бита, отсюда и громоздкость

Error404

28.03.2012, 21:52

тоже 32 бита. один из немногих СРМ-овских кто умел 32 бита лонг

b2m

28.03.2012, 22:35

Вообще, конечно, удручает. Два экрана кода на С (моих самописных printf-ов) транслируется в 3 с гаком кб кода.
Ещё раз увы тебе :)
Посмотрим внимательнее на твой .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. Так что, если написать свою арифметику, то будет компактнее.

Error404

30.03.2012, 16:06

А там какая-то фигня, когда подцепляется этот модуль, то за ним тянется вся арифметика. Причём в самом модуле лишь переходы на реальные процедуры, перед которыми иногда присутствуют команды LD A,5 / RST 8.

выкинув из printf все связанное с long, получил уменьшение кода с 4к до 2к.

Так что, если написать свою арифметику, то будет компактнее.

Не, нафиг. Тогда уж проще сразу писать на ассемблере с макросами :)
Я компилер ищу не для того, чтобы его еще наполовину переписывать, это не интересно.

Error404

04.04.2012, 14:35

NovaStorm

04.04.2012, 15:25

>селерон<
Под виндой так сразу сказать сложно, под линуксом я бы попробовал пересобрать sdcc с graphite(и его плюшками), -march=native, -O3 и перекинуть его в рамдиск.

Error404

04.04.2012, 16:08

Так доооолго компилирует. Буквально часами исходный файлик на полста килобайт. Комп селерон2дуо (2 ядра каждое по 2ГГц). Кто знает отчего это, и можно с этим что-нибудь сделать?

А вот чем оно несколько часов занималось.
Кроме того что долго, оно на выходе еще дает полный *****кретинизм (см. 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к ОЗУ в середине прошлого века), но такое явное УГ это уже перебор. :)

ZEK

04.04.2012, 16:25

2 страницы назад уже обсуждали
const поставь

Error404

04.04.2012, 17:35

зашибись. Оттого что у авторов бардак в голове, теперь во всех исходниках определение строк править... Ну, поправлю конечно, куда я денусь то.

alone

04.04.2012, 17:37

Используй старую версию (см. EVO SDK).

Error404

04.04.2012, 18:36

Используй старую версию (см. EVO SDK).

Не, я на обещания супероптимизаций в 3.x.x купился прочно.

---------- Post added at 18:36 ---------- Previous post was at 17:54 ----------

Скомпилировал проект, разработанный на CP/M-овском HitechC v3.09 образца 1986 года (TCP/IP стек с веб-сервером, если вдаваться в детали). Результат компиляции SDCC не работает (что ожидаемо после того сколько раз оно мне доставило удивления в процессе), и по размеру исполняемого файла в 1,43 раза больше, чем генерит HitechC (26кб против 18кб). Вот вам и древние компиляторы, работавшие на напорядки более слабой технике. В-общем, надо отлаживать, может и заработает чего-то.

bigral

05.04.2012, 15:39

Вот вам и древние компиляторы, работавшие на напорядки более слабой технике. В-общем, надо отлаживать, может и заработает чего-то.

Гы, раньше и воздух чище был :)

Hitech писался строго под i8080 при этом писался он не на OS/360 и не на VAX-е а на компах с прямоадресуемым пространством в 64kb и самое главное писали его за деньги и для денег. SDCC поддерживает пачку процов, написан на компах которые круче OS/360 и VAX-a ну и написан по-приколу энтузиастами. Как говорится почувствуйте разницу! :)

Eltaron

05.04.2012, 16:37

Error404

06.04.2012, 09:33

Ну да, Hitech же под один проц, а значит никаких уровней абстракции там нет практически
Оболочку бы под него удобную, чтоб на пц компилироваться можно было бы (cp/m эмулятор то бишь + обрамляющий скрипт). Какая-то есть в комплекте с UZIX, но глючная, помнится.

Самое главное там нет source-level отладчика. Принтфами тяжеловато отлаживаться. Также есть ряд ограничений на сложность конструкции - "if and and and and на пол-экрана" оно не обработает, приходится делить на несколько вложенных if. Иногда на таких сложных конструкциях оно просто виснет. Однако ж uIP я под него приспособил - а там код: "я те врежу" какой. Еще момент: очень сложные дефайны Hitech не понимает (типа прототредов/протосокетов автора uIP - когда из кучи якобы обособленных "процедур" через дефайны всё собирается в общий case). Но такое и SDCC, похоже, не понимает. По крайней мере он ругался на эти быдлоконструкции.

Поэтому я и ищу замену для Hitech С.

Sayman

06.04.2012, 10:43

Оболочку бы под него удобную, чтоб на пц компилироваться можно было бы (cp/m эмулятор то бишь + обрамляющий скрипт).
zxcc вам в помощ. под фриБСД работает нормлаьно. под венду не пробовал, хотя условия сборки этого эмуля говорят о возможности работы в венде/досе.
использовать MyZ80 это костыль, крайне не удобная штука изза работы с образами. z80mu крайне глючный эмуль. тот же хайтех на некоторых исходниках там тупо вылетает или вышибает сам эмуль.

Какая-то есть в комплекте с UZIX, но глючная, помнится.
к юзиксу нету оболочек для компилятора. есть только несколько "батников" для разных эмулей - для z80mu, 22nice, zxcc и вроде ещё какой то. в качестве компилятора использовался именно цпмная версия хайтеха.

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

Error404

06.04.2012, 11:36

Error, а ты z88dk не пробовал?

Я почитал про него, и даже проинсталлировал. Смутило то, что проект давно не развивается и везде пишут что он на выходе хуже код дает чем SDCC (еще хуже). Хотя сравнивающие на хуже/лучше явно сравнивали по принципу "на безрыбье", т.к. по прочтении их сравнений я был уверен, что любой из (z88dk, SDCC) будет лучше CP/M-овских. :)
SDCC кстати такой рыхлый код делает из-за злоупотребления индексными регистрами. Hitech хотя динамические переменные на стеке и адресовал тоже через IX, но делал это как-то более оптимально.

Кроме того я не припоминаю есть ли в z88dk source-level отладчик (а это то, за что надо бороться).

CP/M-вский Azteс C (он же ManxC) я смотрел, но пользоваться им не буду, т.к. оно - это голый K&R, а так теперь уже никто не пишет, и ценность такого компилера для портирования мала не смотря на поддержку long32 и float.

А вот Hitech С - единственный кто поддерживает сразу и K&R и ANSI. Такого не умеют ни z88dk, ни SDCC (которые только ANSI), ни как я уже написал CP/M-вский Azteс C (K&R).

Sayman

06.04.2012, 11:43

Error404

06.04.2012, 12:24

Error404, варианта два - либо пользоваться хайтехом, либо брать исходники других компиляторов и править их, доводить до нужной консистенции. например bds c либо small c 1.0 кажется... кстати последний более мение приближен к анси...почему в последующих версиях безобразие, не понятно.

Слишком дофига доводить. bds С и small С настолько убоги (как по поддерживаемым типам, так и по набору реализованных конструкций языка), что проще будет писать с нуля, а не помножать чужие глюки. Собственно, так и поступили разработчки SDCC. К чему они пришли за десять с гаком лет, мы тут уже обсудили: еще пилить и пилить.

Sayman

06.04.2012, 12:33

ну, скажем так, bds c самый более менее привлекательный из открытых 9на которые можно найти исходники под цпм). он много не умеет, но глюков на порядок меньше чем у других и кстати есть свой дебагер. к сожалению все исходники под интел8080...просто писать с нуля дело явно мутное...

Eltaron

06.04.2012, 19:16

Еще момент: очень сложные дефайны Hitech не понимает
но это ведь проблема препроцессора, а препроцессор можно использовать любой, хоть cpp из GCC.

zxcc вам в помощ. под фриБСД работает нормлаьно. под венду не пробовал, хотя условия сборки этого эмуля говорят о возможности работы в венде/досе.
Под 64битный линукс из коробки не собрался, но после пары хаков в configure-скриптах стало ок. ХайтекСи запускается и компилит. Спасибо.

Sayman

06.04.2012, 19:39

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

Error404

06.04.2012, 20:44

но это ведь проблема препроцессора, а препроцессор можно использовать любой, хоть cpp из GCC.

В теории - да. Однако попользовавшись, я бы насчет ХитекС ни о чем заранее не зарекался.

Вот тут (http://uzix.sourceforge.net/common/htc_linux/htc) скрипт для компиляции HitechC на Linux - как раз в качестве препроцессора используется GCC.
Вот тут (http://uzix.sourceforge.net/common/htc_linux/htlibr) скрипт для линковки HitechC на Linux.
Попробуй - потом напиши как оно.