Вид для печати
Манипулировать стеком надо только если нужно прочитать передаваемые параметры (т.к. они лежат выше по стеку чем адрес возврата). В остальных случаях достаточно просто не портить стек - компилятор после возврата из твоей функции всегда подымает стек на нужную величину чтобы скомпенсировать им же ранее загруженные на стек параметры функции.Цитата:
Сообщение от Sayman
Sergey, расскажи, пожалуйста, как можно прикрутить к code::blocks компиляцию через bat файл? ты говорил, что умеешь с ним готовить всякие компиляторы...или я путаю?
Error404, ты не вкурсе, у хайтеха видать глюк или комплект стоковых библиотек не полный. в библиотеке libf.lib нет процедуры flxor (float xor). всю башку уже сломал над этой хренью...
Ну, наверное экзотики там может и не быть. Хor вообще-то битовая функция. Битовые функции над вещественными числами это какой-то особый вид извращений.Цитата:
Сообщение от Sayman
Нет. С code::blocks я пока использую SDCC. И для постобработки (для получения SCL со скомпиленной в boot прогой) - скрипт на REXX.Цитата:
Сообщение от Sayman
Сборка CP/M-компиляторами осуществляется REXX-скриптом с помощью эмулятора CP/M, из командной строки. На выходе - SCL с boot`ом.
SCL - частность, - скрипт можно допилить и на другие форматы.
Конкретизируй, пожалуйста, что тебе нужно.
Короче, сони.
Прилагаю архив с дистрибутивом HiTech C v3.09, к которому добавлен эмулятор CP/M (cpm.exe) и два скрипта на REXX с интуитивнопонятными названиями. На выходе у обоих скриптов SCL-файл будет одинаковый (оптимизированный).
Разница в том, что скрипт "optim" выдаст еще два исходника на ассемблере, до и после оптимизации.
Использование:
HiTech2zx48scl.rex source_name.c [, *.lib... [*.obj...]]
библиотека "libc.lib" добавляется в линковку автоматически.
P.S.
Для оптимизации кода НЕ нужно вручную проделывать все шаги вместо компилятора. Достаточно указать последнему ключик "-O". И тот же результат достигается в одну строчку: "cpm.exe C.COM -Dz80 -C -O myprog.c".
Я не понял пост выше. Это таки для интеграции в GUI или просто что-то спектрумовое?
Что касается вызова компилятора, то вызов "по составляющим" дает +1.5к к буферам компилятора/оптимизатора/еtс, т.к. в противном случае сс сажает в верхушке TPA резидента ($EXEC), который уменьшает ТПА, а все что он делает - это вызов той самой кучки бинарей, которые можно вызвать самому и за счет этого собрать более крупные файлы не нарвавшись на "out of memory"
Это не для GUI - я не настолько знаю code::blocks (правильнее сказать, вообще не знаю) чтобы прикрутить туда в качестве компилятора cp/m-программу. Приложенные скрипты предназначены для сборки из командной строки windows. Также там есть пример: cls.c.Цитата:
Сообщение от Error404
по-пробуй (если у тебя установлен Regina REXX): optimHiTech2zx48scl.rexx cls.c
должны появиться файлы cls.asm, cls_opt.asm, cls.bin и cls.scl.
Вот это полезная информация. Спасибо.Цитата:
Сообщение от Error404
Sayman, кстати, а ты, что, С-компилером для Спринтера не пользуешься?!
Sergey, не особо. для спринтера си мало пригоден в плане чего-то графического. объёмы данных слишком большие, чтобы на си с ними ворочать. и памяти мало (всего 64кб, а точнее, ТПА всего 48кб или даже меньше, если учесть, что вывод в одно окно графики, то и вовсе 32кб). утилиты под дос писать мало интереса, да и хватает как бы. да и ещё не удобно, что на си стэк фигово контролировать. есть риск, что код сишный залезет на область стэка. да и дальние вызовы там геморные.
Я имел ввиду использование нативного SolidC для SprinterDOS :)Цитата:
Сообщение от Sayman
Да кто-же всё ЦЕЛИКОМ-то на Сях пишет?! Делай либы на асме и дёргай их из Сей. Низкоуровневые процедуры пишут только на асме. И как-то это не вяжется с твоими вопросами, как сделать crt0.s для сборки екзешников для Спринтера. ;)Цитата:
Сообщение от Sayman
Это невозможно. Стек может испортить только криво написанная подрограмма на асме, которая за стеком не следит.Цитата:
Сообщение от Sayman
не не, спасибо. такое я точно пользовать не буду. никаких 32 bit long, float, double, #asm/#endasm и других красивостей.Цитата:
использование нативного SolidC для SprinterDOS
процедуры на асме тут не причём. тут только на фон нужно иметь 82кб буфер. про прочие спрайты, которые в среднем весят от 2.5кб до 5кб, а могут и больше. с такими данными шибко не удобно работать на сях. постоянно нужно следить за границами буферов. не удобно в общем.Цитата:
Да кто-же всё ЦЕЛИКОМ-то на Сях пишет?!
вяжется это так, что хотел попробовать сдцц к спринтеру. попробовал. не понравилось. отложил.Цитата:
как сделать crt0.s для сборки екзешников
для мелких проектов да, а когда ехешник выростает килобайт до 40, вот тут уже начинаются грабли с сями. что говорить. если банальный printf в среднем 2.7кб.Цитата:
Это невозможно.
DI DI/Gl.vars Коэфф. Ассемблер (эталон) 323 323 1,00 HiTech C v.7.50 (MS-DOS) 432 1814 0,74 Z88DK (Win32) 512 - 0,631 SDCC v.3.51 (Win32) 528 765 0,612 IAR (Win32) 803 858 0,4022 HiTech C v.3.09 (cp/m, z80) 979 856 0,3320/0,3773 Aztec C (cp/m, i8080) 1738 - 0,186 HiSoft-C v.1.35 (CP/M, Z80) 3660 0,0000/0,0882 MI-C v3.18I (CP/M, Z80) 4160 3760 0,0776/0,0859 WarpC 14.01 (TR-DOS, Z80) 4910 4640 0,0660/0,0696 MeSCC 1.08 (CP/M, i8080) 8370 4850 0,0386/0,0667
Поскольку меня торкнуло написать печаталку на Сях, и она, таки, заработала, решил устроить небольшое соревнование между компиляторами Си, позволяющими компилировать код для ZX-Spectrum.
Сам тест состоял в вызове 2560 (для очень медленных компиляторов - 256) раз процедуры печати текста. Текст был выбран случайно и оказался длиной 333 символа.
Время запуска и окончания цикла фиксировалось по встроенным CMOS-часам. В таблице результаты времени отработки цикла в секундах.
Изначально время замерялось при включенных прерываниях, что не совсем правильно. - В последующим данные для всех компиляторов будут дополнены.
Кроме того интересно было оценить, насколько на эффективность влияет "локальность" переменных.
Для процедуры на ассемблере ничего не дало - это естественно. Там можно было вынести в глобальные только переменную цикла. В Си-версии процедуры - их шесть. На примере Aztec C, разница заметно видна.
За эталон взята самописная процеура печати 64 сим./стр. на ассемблере. Шрифт используется "экономный" в левых тетрадах байта латинские символы, в правой - кириллица. Итого 1кб.
До кучи, сравнил эффективность кода Хайтек 3.09 до и после оптимизации (прерывания выключены): 483/472 секунд.
Вот сишный исходник:
Кстати, сишный исходник, наверняка, можно оптимизировать. Если знатоки, решат его поправить, - добавлю в таблицу соответствующие данные. Это тоже интересно, сколько может дать оптимизация на высоком уровне. Пока в глаза бросается, что можно было обойтись без вычисления промежуточной переменной index и return(dest).Код:#include "minifont.c"
#define LAT 0
#define RUS 1
char text[16];
void i2s(char*, int num);
unsigned int iBCD2int(unsigned int num);
unsigned int rd_cmos_minsec(void);
unsigned char atX,atY;
const unsigned char* ScreenTable[24] = {
0x4000,0x4020,0x4040,0x4060,0x4080,0x40A0,0x40C0,0x40e0,
0x4800,0x4820,0x4840,0x4860,0x4880,0x48A0,0x48C0,0x48e0,
0x5000,0x5020,0x5040,0x5060,0x5080,0x50A0,0x50C0,0x50e0
};
unsigned int iBCD2int(unsigned int num) __naked
{ num;
__asm
pop af
pop de
push de
push af
ld hl,#0
ld a,d
rrca
rrca
rrca
rrca
and a,#0x0f
ld l,a
call 2$ ; x10
ld a,d
and a,#0x0f
ld b,h
ld c,a
add hl,bc
call 2$ ; x10
add hl,hl
ld c,l
ld b,h
add hl,hl
add hl,bc ; x6
ld a,e
rrca
rrca
rrca
rrca
and a,#0x0f
add a,a
ld c,a
add a,a
add a,a
add a,c
ld c,a ; x10
ld a,e
and a,#0x0f
add a,c
ld c,a
ld b,#0
add hl,bc
ret
2$: add hl,hl
ld c,l
ld b,h
add hl,hl
add hl,hl
add hl,bc
ret
__endasm;
}
unsigned int rd_cmos_minsec(void) __naked
{
__asm
ld bc,#0xeff7
ld a,#0x80
out (c),a
ld b,#0xdf
xor a
out (c),a
ld b,#0xbf
in l,(c)
ld b,#0xdf
ld a,#2
out (c),a
ld b,#0xbf
in h,(c)
ld b,#0xef
xor a
out (c),a
ret
__endasm;
}
void i2s(char* d, int num) __naked
{ d, num;
__asm
pop af
pop bc
ex (sp),hl
push bc
push af
xor a,a
ld de,#10000
call 2$
xor a,a
ld de,#1000
call 2$
xor a,a
ld de,#100
call 2$
xor a,a
ld de,#10
call 2$
ld a,#0x30
add a,l
ld (bc),a
inc bc
xor a,a
ld (bc),a
ret
2$: or a,a
sbc hl,de
jp c,1$
inc a
jp 2$
1$: add hl,de
; or a,a
; ret z
add a,#0x30
ld (bc),a
inc bc
ret
__endasm;
}
void put__ch(char sym)
{
unsigned char* dest;
unsigned char* src;
unsigned char lang,q,i;
unsigned int index;
dest = (unsigned char*)(ScreenTable[atY]+atX/2);
lang = LAT;
if(sym&0x80) lang = RUS;
sym = sym&0x7f;
index = sym*8;
src = (unsigned char*)(minifont + index);
if(lang==0) {
if(atX&0x01) {
for(i=0;i<8;i++)
{
q = (*dest)&0xf0;
*dest = q | ((*src++)/16&0x0f);
dest+=256;
}
}
else {
for(i=0;i<8;i++)
{
q = (*dest)&0x0f;
*dest = q | ((*src++)&0xf0);
dest+=256;
}
}
}
else {
if(atX&0x01) {
for(i=0;i<8;i++)
{
q = (*dest)&0xf0;
*dest = q | ((*src++)&0x0f);
dest+=256;
}
}
else {
for(i=0;i<8;i++)
{
q = (*dest)&0x0f;
*dest = q | ((*src++)*16)&0xf0;
dest+=256;
}
}
}
}
void print(char* str)
{
while(*str) {
put__ch(*str++);
atX++;
if(atX>63) {atX=0; atY++;};
}
}
void main(void)
{
unsigned int begin, end;
unsigned int i = 2560;
begin = rd_cmos_minsec();
while(i) {
atX=atY=0;
print("Привет, В форуме проскальзовали идеи о том, что дескать неплохо было бы с реального спектрума выходить в какой-никакой интернет. И даже якобы за рубежом изобрели какую-то хреновину, которая является чем-то типа модема для спектрума и вставляется в стандартный системный разъем фирменного спека. Только вот что было дальше я не понял.");
--i;
};
end = rd_cmos_minsec();
begin = iBCD2int(begin);
end = iBCD2int(end);
end = end - begin;
i2s(text,end);
atX =0;
atY +=2;
print("Печать вышерасположенного текста 2560 раз заняла ");
print(text);
print(" секунд");
}
Странный этот ваш sdcc какой-то. один и тот же исходник, а старый хайтех выдаёт 9.4кб, сдцц выдаёт 12.7кб. при этом после sdcc местами валят не верные данные при отработки бинарника.
Это не странность, а плата за мультиплатформенность.
sdcc никто и не тестирует для ретро-платформ, упор только на свои силы.
ДДаааа... столь мелкий кодик sdcc собирает медленнее древнющего HTC, да ещё и бинарник медленный оказывается. уж не знаю про выше указанные тесты, но что-то тут не так, sdcc даёт код более медленный, хотя стоит оптимизация по скорости. При чём HTC версии 3.09, под цпм.
Sergey, не могли бы вы предоставить ссылку, чтобы загрузить "minifont.c"?
Я хотел бы, чтобы скомпилировать пример. Hitech C v7.50 очень редко производит более быстрый код, чем z88dk/sdcc во всех испытаниях я сделал, так что я хотел бы, чтобы скомпилировать двоичный для вас попробовать.
Вы можете увидеть результаты некоторых тестах мы запускаем, в том числе Dhrystone 2.1 и Whetstone 1.2, здесь: http://www.z88dk.org/wiki/doku.php?i...#dhrystone_2.1
Скрытый текст
Sergey could you provide a link to download "minifont.c" ?
I would like to compile your example. Hitech C v7.50 very rarely produces faster code than z88dk/sdcc in all the testing I have done so I'd like to compile a binary for you to try.
You can see results of some benchmarks we've run, including Dhrystone 2.1 and Whetstone 1.2, here: http://www.z88dk.org/wiki/doku.php?i...#dhrystone_2.1
[свернуть]
Hello, Alcoholics Anonymous!
I would be very grateful for your work. This is my sources adapted to z88dk.
HiTech C постоянно выдаёт более быстрый код. Я перекопал форум msx, там довольно много кода сравнивали с z88dk, sdcc, msx-c и htc (как 3.09 так и 7.50/7.80). Почти всегда хайтех в лидерах.Цитата:
Hitech C v7.50 очень редко производит более быстрый код
вот пример странички
http://www.msx.org/forum/development...rison-part-two
а тут конкретно z88dk и htc
http://www.msx.org/forum/development...art-two?page=2
6 пост сверху
Цитата:
HTC: 8/9 secs
z88dk: 21 secs.
А я 7.50/7.80 так и не нашел нормально поломаный и чтобы запускать из командника, а не из экранных форм. Где его можно взять погонять? :rolleyes:Цитата:
Сообщение от Sayman
Я думаю, что некоторые из наших инструментов есть проблемы с кириллицей, которые мне придется взять добычу в.Цитата:
Сообщение от Sergey
Но вот компиляции, что я надеюсь, что произведения. На эмуляторе я вижу выход, но, конечно, нет CMOS часы для измерения времени.
Скрытый текст
I think some of our tools have problems with the cyrillic alphabet which I will have to take a loot at.
But here's a compile that I hope works. On an emulator I can see the output but of course there's no cmos clock for time measurement.
[свернуть]
https://drive.google.com/file/d/0B6X...ew?usp=sharing
Если вы используете бинарный вместо крана, вы должны CLEAR 32768, а затем загрузить двоичный обратиться 32768 и, наконец, RAND USR 32768.
Позвольте мне знать, если он не работает.
Одна вещь, я не сделать, изменить программу, чтобы передавать параметры реестра или использовать вызываемого абонента связь, которая большинство других компиляторов не может сделать, чтобы получить более прямое сравнение.
Скрытый текст
If you use the binary instead of the tap, you must CLEAR 32768, then load the binary to address 32768 and finally RAND USR 32768.
Let me know if it doesn't work.
One thing I didn't do was change the program to pass parameters by register or use callee linkage which most of the other compilers cannot do to get a more direct comparison.
[свернуть]
Есть ли у вас ссылка на полной программе, чтобы проверить? Ни один из программ в этой дискуссии не будет полным - часть исходного кода была отрубили по некоторым причинам.Цитата:
Сообщение от Sayman
Скрытый текст
Do you have a link to a complete program to test? None of the programs in that discussion is complete -- some of the source code has been chopped off for some reason.
[свернуть]
В общем, люди не используют компиляторы должным образом. Например, вы не должны использовать встраиваемые ASM с SDCC, потому что это мешает локальной оптимизации. Вы можете получить некоторые странные код из SDCC как статических нагрузок не избежать, если встроен ASM вставляется в C коде. С sccz80 (родной компилятор z88dk), а на самом деле со всеми компиляторами, лучше Код производительности должны использовать глобальные или локальные статику, если это разумно. Особенно с sccz80 это может сделать большую разницу в производительности. Оптимизация должна быть положить на макс, и многие люди не знают, как это сделать. С sccz80 Это -O3 и SDCC, который заходящего --max-allocs-per-node на что-то высокое (как 200000). Обычно вы можете получить лучший код из SDCC, запрещая использование слишком гу, добавив --reserve-regs-iy.
Скрытый текст
In general, people are not using the compilers properly. For example, you should not be using inlined asm with sdcc because it interferes with peephole optimization. You can get some weird code out of sdcc like dead loads not being eliminated if inlined asm is inserted into C code. With sccz80 (z88dk's native compiler) and actually with all the compilers, best performance code should be using globals or local statics if that is reasonable. Especially with sccz80 this can make a big difference in performance. Optimizations should be put on max and many people don't know how to do that. With sccz80 that's -O3 and with sdcc that's setting --max-allocs-per-node to something high (like 200000). You can usually get better code out of sdcc by forbidding use of iy too by adding --reserve-regs-iy.
[свернуть]
sccz80-сгенерированный код никогда не будет самым быстрым. Причина он пытается реализовать компилятора операции, используя вызовы подпрограмм, чтобы быть наименьшим. При том, что в сочетании с языка ассемблера библиотеки, где производительность, как предполагается, пришли, результат маленький и быстрый код. sccz80 сгенерированный код, как правило, меньше, чем SDCC или HITECH, иногда с большим отрывом, но sccz80 требует программировать для компилятора, а не делать вид, что это 32-битная платформа с кодом. Вы можете видеть, что в некоторых крупных программ, составленных мы. Например, clisp.c - это Lisp interpretter> 1200 строк в C - компилирует 27000 байт под sccz80 и 32000 байт под HTCv7.50. startrek.c (> 2100 строк в C) доходит до 41000 байт под HTCv7.50 и 32600 байт под z88dk + SDCC. Последнее особенно связано в основном с более библиотек z88dk так размер кода похож на HTC и SDCC если код библиотеки исключены.
Скрытый текст
sccz80-generated code is never going to be the fastest. The reason is it's trying to implement compiler operations using subroutine calls in order to be the smallest. When that is combined with assembly language libraries, where the performance is supposed to come from, the result is small and fast code. sccz80 generated code is normally smaller than sdcc or hitech, sometimes by a large margin, but sccz80 requires you to program for the compiler rather than pretend it's a 32-bit platform with the code. You can see that in some of the large programs we compiled. Eg, clisp.c -- a lisp interpretter > 1200 lines in C -- compiles to 27000 bytes under sccz80 and 32000 bytes under HTCv7.50. startrek.c (> 2100 lines in C) comes to 41000 bytes under HTCv7.50 and 32600 bytes under z88dk+sdcc. The latter especially is due mainly to better libraries in z88dk since code size is similar for HTC and sdcc if library code is excluded.
[свернуть]
Версия z88dk на sourceforge (1.10) не является текущей. Текущая версия может использовать SDCC, как компилятор, улучшить свой код несколько, и поставить на ассемблере библиотеки из z88dk. Это то, что, кажется, превосходит все остальное большую часть времени в скорости, размер кода и полноты. Я очень заинтересован в поиске, когда эта комбинация не так хорошо, другие компиляторы, чтобы увидеть, где некоторые очевидные улучшения могут быть сделаны.
Скрытый текст
The version of z88dk at sf (v1.10) is not current. The current version is able to use sdcc as compiler, improve its code somewhat, and supply assembly language libraries from z88dk. This is what seems to be outperforming everything else most of the time in speed, code size and completeness. I'm very interested in finding out when this combination does not perform as well as other compilers to see where some obvious improvements can be made.
[свернуть]
It works fine. 512 sec. Great!Цитата:
Сообщение от Alcoholics Anonymous
Can You give "magic" command line options for ZCC? ;)
You must have sdcc installed.Цитата:
Сообщение от Sergey
sdcc must be modified a little bit to be compatible with z88dk. If you are running on windows, copy zsdcc.exe from this zip file to sdcc's bin directory sdcc/bin. If you're not running on windows, check out http://www.z88dk.org/wiki/doku.php?id=temp:front#sdcc1 .
You must have a recent version of z88dk installed. I'd suggest waiting until the Dec 15 build is finished in about 3 hours from now. I put in a fix so the tools will not crash if the source contains Cyrillic letters. The nigthly build is here: http://nightly.z88dk.org/ Click on the latest win32 build and unzip where you like. You must set a few environment variables as described here: http://www.z88dk.org/wiki/doku.php?i...:front#windows sdcc should also be in the path.
z88dk compiles are very configurable so one compile line (and a set of pragmas in your source code) does not always fit. The library can also be rebuilt to make the compiled code faster or smaller by selecting different options. For example, you can opt out of individual printf/scanf converters to reduce size or you can enable the fast integer library if you are ok with an additional ~1k code. The latter makes z88dk's integer math several times faster than all other compilers. If you read through the links mentioned in this section: http://www.z88dk.org/wiki/doku.php?i...ling_with_sdcc you will have an idea of how things work.
A general magic compile line for the zx looks like one of these:
32 column stdin/stdout/stderr z88dk terminal drivers
zcc +zx -vn -SO3 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test
zcc +zx -vn -SO3 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test
64 column stdin/stdout/stderr z88dk terminal drivers
zcc +zx -vn -SO3 -startup=4 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test
zcc +zx -vn -SO3 -startup=4 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test
fzx proportional fonts stdin/stdout/stderr z88dk terminal drivers
zcc +zx -vn -SO3 -startup=8 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test
zcc +zx -vn -SO3 -startup=8 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test
Nothing on stdin/stdout/stderr
zcc +zx -vn -SO3 -startup=31 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test
zcc +zx -vn -SO3 -startup=31 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test
The "-clib=sdcc_iy" compile gives IX to sdcc and IY to the c library. This will be the smallest and fastest code. However, you must disable interrupts or have your own isr installed because the rom interrupt uses iy and if it runs, it will be poking random stuff into memory and eventually cause a crash.
The "-clib=sdcc_ix" option has sdcc and the c library sharing IX. The rom isr can continue to run.
You must add "-lm" if using floats. If you need to printf floats (%aefg) you must re-build the library because the default build has %aefg disabled. You can also use stdlib functions dtoa / ftoa, etc to render floats into text.
The default zx crt is doing something we call an "automatic malloc". It creates a heap between the end of the program and the bottom of the stack automatically when the program runs. If it finds the available space is 0 or less, the program will just exit without any indication. This can happen if you CLEAR before loading the program because CLEAR moves the stack underneath the executable. So by default the crt also moves the stack pointer underneath the UDGs. For someone new to C and just wanting to compile stuff, this is most often what is wanted. But for more complicated programs this is often not what you want. You can put pragams into the source to change the crt behaviour. These two may be helpful:
#pragma output REGISTER_SP = -1 // do not change the stack pointer
#pragma output CLIB_MALLOC_HEAP_SIZE = 0 // do not create a heap
z88dk's library and crts are very configurable so if you use it, take some time to learn these things in order to make best use of the compiler.
If you get things working, try compiling your program in the zip I posted a little further back. The compile line I used is listed at the top of the .c file. You can make the result a little bit faster by changing the function linkage of put__ch() and print() like this:
unsigned char* put__ch(char sym) __z88dk_fastcall
void print(char* str) __z88dk_fastcall
Adding "__z88dk_fastcall" will make sdcc pass a single parameter by register instead of by stack. This shaves another 10 seconds or so from running time.
There are a few example programs in z88dk/libsrc/_DEVELOPMENT/EXAMPLES
- - - Добавлено - - -
В z88dk пространство памяти делится на разделы. Раздел представляет собой контейнер, чем может удерживать код или данные и может иметь дополнительный Org. По умолчанию компилирует настроить карту памяти, которая будет производить один двоичный в разделе "CODE" (так выходные двоичные файлы из z88dk всегда будет под названием "name_CODE.bin"); это на самом деле содержит двоичный код традиционной / части DATA / BSS исполняемого все слиплись.Цитата:
Сообщение от krt17
Это очень легко иметь код компилятора компиляции на 32768 и есть один раздел определяемые пользователем отображается на 23296, например, что вы положили данных или подпрограммы по сборке в. Просто создайте другой файл, как это:
Скрытый текст
In z88dk the memory space is divided into sections. A section is a container than can hold code or data and can have an optional ORG. The default compiles set up a memory map that will produce a single binary in the "CODE" section (so output binaries from z88dk will always be called "name_CODE.bin"); this binary actually contains the traditional CODE/DATA/BSS parts of an executable all stuck together.
It's very easy to have the compiler compile code at 32768 and have another user-defined section mapped to 23296, eg, that you put data or assembly routines into. Just create another file like this:
[свернуть]
И добавить его к линии компиляции. Тогда выход будет два бинарных файла: "name_CODE.bin", содержащий C код компилятора на 32768 и "name_LOWMEM.bin", содержащий другие вещи, которые должны быть загружены по адресу 23296.Код:SECTION LOWMEM
org 23296
PUBLIC _map
_map: defs 100
...
Это, как большинство людей используют нижние области памяти, потому что это легко. Если вы действительно хотите, чтобы скомпилировать код там, вы должны сказать SDCC использовать другое имя раздел, и это делается по линии компиляции. Я никогда не делал этого, так что я не могу дать конкретные указания. В любом случае, если вы сообщите его скомпилировать в разделе "Lowmem", код будет поставить там. Но SDCC можно скомпилировать только одной секции с каждого исходного файла. Так что вам нужно сделать, это разделить ваш источник C, так что каждый С файла относится к собственной секции. Тогда ты скомпилировал бы каждый файл C объектный файл, а затем, наконец, положить все это вместе на последнем этапе компиляции. Затем выводе будет одним двоичным в разделе определенной которые вам придется загрузить в память.
Вот как это будет работать с z88dk но я никогда не делал этого раньше.
Скрытый текст
And add it to the compile line. Then the output will be two binaries: "name_CODE.bin" containing the C compiler code at 32768 and "name_LOWMEM.bin" containing the other stuff that should be loaded at address 23296.
This is how most people are using the lower areas of memory because it's easy. If you actually want to compile some code there, you have to tell sdcc to use a different section name and this is done on the compile line. I have never done this so I can't give specific instructions. Anyway if you tell it to compile into the "LOWMEM" section, code will be put there. But sdcc can only compile to one section with each source file. So what you need to do is divide up your C source so that each C file belongs to its own section. Then you would compile each C file to an object file and then finally put it all together in the last compile step. Then the ouput will be one binary per section defined which you will have to load into memory.
That's how it would work with z88dk but I have never done this before.
[свернуть]
Добавил в табличку информацию об эффективности WarpC: 0,066.
Как насчет измерения для BDS C и вот этого компилера раз пошла такая пьянка :)Цитата:
Сообщение от Sergey
С BDS не помню, почему до сих пор не потестил. А по второму, - вот:
Занятная штуковина этот Mescc. Подвид Small C Compiler, синтаксис K&R. Не умеет инициализированные массивы. Зато очень беспечен ко всему, что заключено между #asm/#endasm. Так массивы и впихнул :) Особенно порадовала работа с объявлением функций, написанных на асме. Главное, чтобы у неё была своя метка. Остальное - мало..учий факт: компилятор передаст ей столько аргументов, сколько захочешь, любых типов - сам отвечаешь, что у тебя подпрограмма из этого "скушает", не нужно каким-либо образом формально сообщать компилятору количество и тип аргументов, а также и тип возвращаемого значения и то, есть оно или нет. Анархия - мать порядка! :)
Интересная особенность: аргументы передаются в порядке, обратном обычному: первым со стека снимается последний аргумент, а не первый.
Выдаваемый код ужасен. По каждому чиху call на runtime-функции, состоящие из 3-х-4х комманд, а с локальными переменными какие пляски с бубном устраивает, - зрелище не для слабонервных. Хоть он и заявлен, что Z80, от Z80 у него только мнемоники в выходном ассемблерном файле, - локальные переменные используются через мудрёные спецпроцедуры, - про индексные регистры компилятор не в курсе :(. Итак: MeSCC: 0,0386/0,0667.
Но есть и положительные моменты: если использовать его как макроассемблер с Си-синтаксисом, ужасность его кода для конечного результата особого значения не имеет. И, учитывая, что есть исходники и компилятора и используемого им ассемблера, его возможно достаточно легко портировать в ТR-DOS. Нативный компилятор Си, выдающий верный код, на Спеке лишним не будет :)
Прилагаю архивчик с SCL, а также исходники теста, модифицированный mescc.h (обязательно инклюдить) и скрипт на REXX, который поможет интересующимся собирать на Mescc приложения для Спектрума. (Изменения внесены на скорую руку. Если кому-то интересно, - тогда уже отрехтую для серьёзной работы ).
BDS C так и не осилил - очень ограниченный. Трудновато слепить на нём печаталку.
Зато побаловался с MI-C. Результат таков: 0,0776/0,0859.
В процессе не удалось пока собрать всё штатными средствами - m80/l80. Поэтому поступил так:
Сгенерил компилятором ассемблерный файл и перенёс его в ALASM. То же самое сделал и с runtime библиотекой, которая хранится в ассемблерном файле.
Добавил служебных процедурок для замера времени, и всё. Ассемблится и запускается ручками в ALASM/STS. Результат можно посмотреть в дампе памяти по адресу #60BC ("PASSED:nnn"). Полуфабрикат, конечно, зато интересующиеся смогут посмотреть выдаваемый MI-C код. ТРДшник прилагаю.
Как компилятор K&R, MI-C, вполне, адекватный, каких-либо неудобств с точки зрения совместимости С-кода не ощутил. BDS C с ним не сравнить.
Однако, особенностей Z80 компилятор не использует, а лишь способен выдавать ассемблерный текст в соответствующих мнемониках. Ну, и, понятно, к локальным переменным обращается не через индексные регистры, а через HL, складывая указанное в ней смещение со значением SP.
а zds 3.68 от зилога не встречалось никому с невыпеленым компилятором С ?
Добавил в табличку сведения по HiSoft-C.
Вообще, я хотел проверить версию для TR-DOS, однако не вышло - компилятор почему-то ругается на нехватку памяти. Поэтому, чтобы получить представление о возможностях спектрумовского компилятора пришлось использовать его cp/m-ного собрата. Правда, на спектруме используется более старая версия: 1.1.
Для версии с глобальными переменными коэффициент относительно аналогичной программы на ассемблере составил 0,0882.
256 вызовов отработали за 366 секунд.
Этот компилятор генерит сразу машинный код, минуя стадию ассемблера, и не даёт возможности компиляции под произвольный адрес - только с 0x100.
Но, поскольку каких-либо функции, завязанных на CP/M я не использовал, то решил задачу в лоб: полученный com-файл CP/M запустил на Пентеве с адреса 0x100. И всё получилось.
HiSoft-C заточен именно на Z-80, обращается к локальным переменным через IX. Однако качество кода настолько низкое, что по эффективности, фактически, ничем не отличается от компиляторов для I8080.
Установил SDCC и Codeblocks.
Настройку для среды делал по сайту http://www.ibm.com/developerworks/ru...locks_and_sdcc
В Compilier settings установил флаги [CPU]Zilog Z80[-mz80] и [Z80]When lincing, skip stsndard crt0.o object file[--no-std-crt0]
В Linker settings добавил флаги в поле Other linker options:
--code-loc 0x7530
--data-loc 0xA530
Создап проект. В настройках проекта на вкладке Build targets для Debug и Release выбрал Type не Console Applications, а Native, при этом убрал флажок Auto-generate filename extension и вручную прописал расширение HEX.
Правильно ли я сделал настройки? Сделал пробную пробную сборку. Как делать ассемблерные вставки и как передаются параметры для ассемблерной процедуры?
Вот тут есть почитать про настройку Code::Blocks + SDCC, там есть примеры ассемблерных вставок, но, вроде, ничего не увидел про передачу параметров. Много примеров исзодников для SDCC (в том числе, и с ассемблерными вставками) есть в поставке Оберона.
Во всех случаях возвращается значение в подгруппе DEHL. Если возвращаемое значение 32 бита это в DEHL, если это 16-бит Это в HL, если это 8-бит это в L. Кроме того, во всех случаях ваш подпрограмма не должна изменять IX или IY.Цитата:
Сообщение от Alex Rider
Есть три связи:
Скрытый текст
In all cases the return value is in a subset of DEHL. If the return value is 32-bits it's in DEHL, if it's 16-bits it's in HL, if it's 8-bits it's in L. Also in all cases your subroutine must not modify IX or IY.
There are three linkages:
[свернуть]
1. Normal
Параметры помещаются в стек в правом левом порядке. Стек не должен быть изменен вызываемой функции. Интс 2 байта, Лонги и поплавков 4 байта. Чар выталкивается в 1 байт, но если функция va_arg, символы продвигаются в целое перед толкнул. Возвращаемое значение находится в подгруппе DEHL.
Скрытый текст
Parameters are pushed onto the stack in right to left order. The stack must not be altered by the called function. Ints are 2-bytes, Longs and Floats are 4-bytes. Char is pushed as 1-byte but if the function is vararg, chars are promoted to int before being pushed. Return value is in a subset DEHL.
[свернуть]
extern char *strcpy(char *dst, const char *src);
Код:_strcpy:
pop af ;; return address
pop de ;; de = char *dst
pop hl ;; hl = char *src
push hl
push de
push af
..
;; return value in HL
ret
2. Fastcall
Реализованные на совместимость z88dk в 3.5.5 купить исправления были применены после этого релиза. Использовать текущий SDCC для обеспечения он работает правильно.
Один параметр передается в регистре в подгруппе DEHL и возвращаемое значение в подгруппе DEHL.
Скрытый текст
Implemented for z88dk compatibility in 3.5.5 but bugfixes were applied after that release. Use the current sdcc to ensure it works properly.
A single parameter is passed by register in a subset of DEHL and the return value is in a subset of DEHL.
[свернуть]
extern int strlen(char *s) __z88dk_fastcall;
SDCC не в состоянии генерировать звонки на быстрых функций обработки вызовов с помощью указателей функций, если он не имеет права использовать регистр IY. В z88dk мы делаем функция указатели другой способ, чтобы они всегда работать.Код:_strlen:
;; hl = char *s
...
;; return value in HL
ret
Скрытый текст
sdcc is unable to generate calls to fastcall functions through function pointers unless it is allowed to use the IY register. In z88dk we do function pointers a different way so that they always work.
[свернуть]
3. Callee
Реализованные на совместимость z88dk в 3.5.5 купить исправления были применены после этого релиза. Использовать текущий SDCC для обеспечения он работает правильно.
Параметры помещаются в стек в справа налево для того, как в [B] 1. Normal [/ B], но называется функция отвечает за ремонт стек. Преимуществом является абонент не должен очистить стек после вызова функции каждого. Возвращаемое значение находится в подгруппе DEHL.
Скрытый текст
Implemented for z88dk compatibility in 3.5.5 but bugfixes were applied after that release. Use the current sdcc to ensure it works properly.
Parameters are pushed onto the stack in right to left order as in 1.Normal but the called function is responsible for repairing the stack. The advantage is the caller does not have to clear the stack after every function call. The return value is in a subset of DEHL.
[свернуть]
extern char *strcpy(char *dst, const char *src) __z88dk_callee;
Я не уверен, что если SDCC может генерировать указатель функции звонки на вызываемого абонента функций. Если он может, они будут по-разному набрали, так что указатели на функции не вызываемого абонента может быть назначен указателей на обычные функции. В z88dk мы делаем функция указатели другой способ, так что все работает прозрачно.Код:_strcpy:
pop hl ;; hl = return address
pop de ;; de = char *dst
ex (sp),hl ;; hl = char *src, ret address onto stack
..
;; return value in HL
ret
Скрытый текст
I'm not sure if sdcc can generate function pointer calls to callee functions. If it can, they will be typed differently so that pointers to callee functions cannot be assigned to pointers to regular functions. In z88dk we do function pointers a different way so everything works transparently.
[свернуть]
В дополнение к этому есть новые __preserves_regs () атрибут, который может сказать, что компилятор регистрирует функцию АНМ не меняется. На данный момент SDCC использует только информацию о нашей BC и DE, но я включаю все регистры главного набора в только в случае, SDCC расширяет это в будущем:
Скрытый текст
In addition to this there is a new __preserves_regs() attribute that can tell the compiler what registers the asm function does not change. At the moment sdcc only uses information about BC and DE but I include all registers of the main set in just in case sdcc expands this in the future:
[свернуть]
extern int strlen(char *s) __preserves_regs(d,e) __z88dk_fastcall;
Собрать среда для SDCC немного болезненные так много людей встроить свои функции ASM внутри C функций, которые вы можете сделать, но это не самый лучший способ делать вещи. Самый лучший способ, чтобы полностью отдельных ASM функции из кода C. Если вы сделаете это вы будете иметь больше контроля над тем, где ASM код находится в памяти, имея свободу, чтобы присвоить код АНМ в конкретной области или раздела. Также помните, что встроенный монтаж мешает глазок оптимизатора SDCC в:
Скрытый текст
The assemble environment for sdcc is a little bit painful so many people inline their asm functions inside C functions, which you can do, but it is not the best way to do things. The best way is to completely separate asm functions from the C code. If you do this you will have more control over where asm code is placed in memory by having the freedom to assign the asm code to a specific area or section. Also be aware that inlined assembly interferes with sdcc's peephole optimizer:
[свернуть]
В z88dk мы ввели встроенные функции, так что общие одиночные инструкции, как ди Е.И. остановке, и т.д. могут быть встроены, не влияя на глазок слишком много:Код:void myfunc(void)
{
.....
// sdcc peepholer can't look into the asm block so it assumes all registers are modified by the "di"
__asm
di
__endasm;
...
}
Скрытый текст
In z88dk we introduced intrinsics so that common single instructions like di, ei, halt, etc can be inlined without impacting the peepholer too much:
[свернуть]
Призыв к intrinsic_di() заменяется на "di", прежде чем глазок видит. Функция объявлена как сохранение всех регистров, так что компилятор может сохраняться регистры по вызову.Код:void myfunc(void)
{
.....
intrinsic_di();
.....
}
Скрытый текст
The call to intrinsic_di() is replaced by "di" before the peepholer sees it. The function is declared as preserving all registers so that the compiler is able to persist registers across the call.
[свернуть]
Кто-нибудь сделайте и выложите небольшой проект с двумя-тремя функциями и ассемблерными вставками. У меня чего-то выдаёт ошибку - <a> неправильное размещение в памяти.
- - - Добавлено - - -
Нашёл ошибку. Написал ld a, 2 ,а надо было ld a, #2.
Какой файл crt0.s нужен для спекки?
У меня такой:
Просто переход на ф-цию main. Может не работать инициализация неконстантных массивов. Могут быть другие проблемы.Код:.module crt0
.globl _main
jp _main
Если прога стартует с самого начала - юзаем ключик --no-std-crt0
на memset замени и еще быстрее будетЦитата:
Сообщение от Smalovsky
Oleg N. Cher, скипнул crt0.s, но опциях линкера поставил -
--code-loc 35000
--stack-loc 55000
Набросал пробную программу:
#include <stdio.h>
#include <stdlib.h>
int main()
{
int i=0;
char *p;
__asm
call 3435
ld a, #2
call 5633
ld a, #22
rst 16
ld a, #10
rst 16
ld a, #10
rst 16
ld bc, #12345
call 11563
call 11747
__endasm;
for (i=16384;i<22528;i++){
p=(char*)i;
*p=(char)0xf;
}
return 0;
}
Собрал, прогнал через hex2bin и bin2tap. Всё работает - экран очищается, быстро выводится число 12345 и рисуется "зебра". Правда всё очень быстро происходит - скорость отличная!
вот только зачем тут си?
Специфика программирования для спекки подразумевает использования ассемблерных вставок, поэтому я потренировался совместить ассемблерный код и код Си. Еще предстоит написать графические процедуры с использованием ассемблера, а логика программы будет на Си.Цитата:
Сообщение от s_kosorev
Если есть у кого готовые библиотеки, то выкладывайте.
тут ассемблер с вставками на си :)Цитата:
Сообщение от Smalovsky
Smalovsky, возьми за правило скидывать весь асмовый код в отдельные модули/библиотеки которые потом просто вызываешь в основном коде. когда ты кидаешь и сишный код и асм в один скроллинг, код становится громоздким и нечитаемым. ты сам начнёшь косяки пороть и думать в чём проблема. и вызывать бейсиковые процедуры тоже не есть гут. они медленные. напиши сам их замену или возьми из того, что уже было до тебя написано. В библиотеках сдцц и z88dk многое есть в открытом виде, можно подсмотреть или использовать то, что уже скомпилино в библиотеки.
и кстати, большая часть ответов на твои вопросы по сдцц есть в его родном мануале. Несколькими страницами назад есть даже модифицированный crt0.s...