Вид для печати
Версия компилятора - 3.5.0. Функция понастоящему нужна. Иначе меню на экран даже не выведешь...
- - - Добавлено - - -
Я, наверно, ошибся. Нельзя чередовать посимвольный вывод и вывод последовательности символов. Буду делать новую функцию - всё через последовательность символов.
Я решил параметры брать не через восстановление стека, а через чтение памяти по базе указатель стека+2 (два байта занимает адрес возврата).
Пути SDCC неисповедимы в работе. Лишь бы у вас сил хватило, понять:)
Почти свежак. 3.6.0 уже на дворе.
От версии к версии исходники не компилируются (часто) на SDCC. Лучше тут разобраться, в чем причина. Так с на скоку тяжело понять. Я Пас. Вы исходные данные написали, может, кто поможет.
Разобрался в чём причина. Компилятор две переменных типа char сохранил в стеке как одну пару байтов, а я думал что каждую переменную сохранит в отдельной паре.
Исправленная функция.
void cursor(char x, char y){
__asm
//call 3405 - лучше сброс временных атрибутов вынести в отдельную функцию
ld hl, #2
add hl, sp
ld b, (hl)
inc hl
ld c, (hl)
ld a,#22
rst 16
ld a, c
rst 16
ld a, b
rst 16
ret
__endasm;
}
Код:void Basic_AT_ROM_stdcall (unsigned char x, unsigned char y) __naked {
__asm
;LD IY,#0x5C3A
;LD A,#2
;CALL 0x1601 // IX-safe
LD A,#22
RST 16
POP HL
POP BC
PUSH BC
LD A,B // x
RST 16
LD A,C // y
RST 16
JP (HL)
__endasm;
} //Basic_AT_ROM_stdcall
Написал меню на Си. Размер кодового блока 353 байта. Меню совсем простое, можно на бейсике такое сделать. Сколько в памяти будет занимать аналогичная программа на бейсике?
Непонятно, почему при очистке экрана не закрашивается область системных сообщений? Хотя вроде нормальную функцию очистки экрана написал.
void cls(){
__asm
call 3435
ld a, #2
call 5633
ret
__endasm;
}
почитай про каналы, для системных сообщений применяется другой номерЦитата:
Сообщение от Smalovsky
Здравствуй,
Вы уверены, что "call 5633" не изменяет HL?Код:void cursor(char x, char y){
__asm
ld hl, #2
add hl, sp
ld a, #2
call 5633
ld b, (hl)
inc hl
inc hl
ld c, (hl)
....
SDCC толкает символов в виде одного байта в стек. Так оно и должно быть "ld b,(hl); inc hl; ld c,(hl)"
Еще одна проблема связана с регистром IY.
1. Если у вас есть обработчик прерываний на 0x38 ром работает, ваша программа не может изменять IY.
2. Если вы используете Rom подпрограммы для выполнения таких задач, как печать, IY должен быть установлен на значение, ожидаемое РОМ.
Чтобы предотвратить SDCC от модификации IY вы должны компилировать с флагом "--reserve-regs-iy". Однако это не остановит SDCC от использования IY, если кадр стека становится большим.
Лучший способ на гх, чтобы обойти эту проблему, чтобы отключить прерывания или заменить РОМ ISR и убедитесь, что IY устанавливается на ожидаемое значение, прежде чем сделать Rom вызовы, которые зависят от него. Если вы не сделаете это, вы будете испытывать странные сбои.
Скрытый текст
Hi,
You're sure "call 5633" does not modify HL?Код:void cursor(char x, char y){
__asm
ld hl, #2
add hl, sp
ld a, #2
call 5633
ld b, (hl)
inc hl
inc hl
ld c, (hl)
....
sdcc pushes characters as single bytes onto the stack. So it should be "ld b,(hl); inc hl; ld c,(hl)"
Another problem has to do with the IY register.
1. If you have the rom interrupt routine at 0x38 running, your program cannot modify IY.
2. If you use rom subroutines to carry out tasks like printing, IY must be set to the value expected by the rom.
To prevent sdcc from modifying IY you must compile with the "--reserve-regs-iy" flag. However this will not stop sdcc from using IY if the stack frame becomes large.
The best way on the zx to get around this problem is to disable interrupts or replace the rom isr and make sure IY is set to the expected value before you make rom calls that depend on it. If you don't do this you will experience odd crashes.
[свернуть]
Что бы экран очищался правильно, нужно атрибуты устанавливать не только для основного экрана, но и для окна системных сообщений.
void setattr(char attrib){
__asm
ld hl, #2
add hl, sp
ld a, (hl)
ld (23693), a
ld (23624),a
__endasm;
}
5633 точно изменяет hl. Координаты возьмутся из космоса.Цитата:
Сообщение от Alcoholics Anonymous
Общепринятый. :)
Error404 писал:
z88dk может ещё конкуренцию составить. А так SDCC очень неплохой компилятор. Не я один считаю, что SDCC крут.Цитата:
Общепринятый.
Alex Rider, я уже давно исправил функцию. А неправильный вариант можно считать демой. ))
один аргумент забирать можно ПРОЩЕ!Цитата:
Сообщение от Smalovsky
Если аргументов до 4-х слов, забирать со стека лучше через pop/pushКод:void setattr(char attrib) __z88dk_fastcall __naked {
__asm
ld a,l
ld (23693), a
ld (23624),a
ret
__endasm;
}
Последний аргумент можно забрать в HL так: ex (sp),hl
Ух ты, а я и не знал о такой фишке. Значит, __z88dk_fastcall это однобайтовый аргумент в регистре L? Очень разумно. Вообще новые ключики SDCC __preserves_regs, __z88dk_callee и __z88dk_fastcall позволяют делать весьма интересные оптимизации, которые раньше были недоступны, в свете чего можно отрефакторить все библиотеки (ZXDev), оптимизировав различными способами получение параметров.
Например, вот эту процедуру можно оптимизнуть:
- - - Добавлено - - -Код:void Basic_AT_ROM_stdcall (unsigned char x, unsigned char y) __z88dk_callee __naked {
__asm
LD A,#22
RST 16
POP HL
POP BC
LD A,B
RST 16
LD A,C
RST 16
JP (HL)
__endasm;
} //Basic_AT_ROM_stdcall
В случае использования моделей вызова __z88dk_callee и __z88dk_fastcall есть проблемы с вызовом функций по указателю, на что указал Alcoholics Anonymous, но далеко не все функции нужно юзать таким способом, иногда в этом просто нет смысла.
- - - Добавлено - - -
Вот какая красота. Филипп обещал регистровые параметры и сделал. Пока что __z88dk_fastcall не тянет на идеал (можно только 1 параметр передавать), но, надо думать, идея получит развитие, я на это очень надеюсь.
Это, пожалуй, тот штрих, которого мне больше всего не хватало в Си для Z80 - именно регистровой передачи параметров. Ещё два момента, которые упорно обходят и не реализовывают - это:Цитата:
Сообщение от sdccman.pdf
- помещение процедур и переменных в отдельные сегменты (аналог GCC'шных -ffunction-sections и -fdata-sections), что позволило бы не хранить функции в разных файлах, а если и хранить, то не резать код вручную на кусочки. Впрочем, для автоматизации этого процесса у нас есть моя утилита smartlib);
- присвоение структур a = b;
SDCC глючен, и глупо было бы отрицать это. Но оптимизирующие компиляторы вообще сложны, и глюки фиксятся только благодаря стараниям команды и тех, кто их находит и не ленится репортить, т.е. нас с вами. SDCC (и бэк-энду для Z80) в этом смысле не хватает массового юзера. Но хорошая новость тут в том, что каждый глюк попадает в базу автоматических тестов, и потенциально мы имеем большую и всё увеличивающуюся базу различных тестов, которую даже наверное можно использовать для верификации других компиляторов языка Си.
Это на самом деле не конкуренция - это больше похоже на сотрудничество. В "z88dk_callee" и "z88dk_fastcall" функциональных связей происходят из z88dk и "smallc" был добавлен легко взаимодействовать с библиотекой кода, написанного для sccz80, который выталкивает параметры функции в порядке слева направо (это наследуется от малых С и все компиляторы происходит от небольшой C разделяют эту idiosyncracy). Эти дополнения позволяют SDCC генерировать чистый и эффективный код при вызове в библиотеки языка сборки z88dk в. Они также служат очень хорошо для взаимодействия с пользователем сборки кода. Со стороны z88dk мы адаптировали в большую часть кода библиотеки в SDCC и создали модифицированную версию SDCC (zsdcc), что позволяет нашим ассемблер, z80asm, который будет использоваться в качестве заднего конца. Изменения включают имеющие SDCC правильно генерировать Экстерн списки и создание переводчика, чтобы перевести asz80 код на стандартный Zilog (The peepholer опирается на синтаксис asz80 так что вы не можете изменить SDCC генерировать стандартный код, то, что мы пытались в первую очередь). Тогда наша версия SDCC был изменен, чтобы сгенерировать лучший код: - это происходит от исправления ошибки в peepholer, чтобы он мог правильно определить, какие регистры считываются и записываются, в паре с добавлением тысячи новых правил глазок, чтобы исправить некоторые из сомнительного код SDCC производило. Также были добавлены некоторые правила, чтобы исправить некоторые ошибки генерации кода и больше возможностей для оптимизации размера кода при работе с длинных позиций, поплавки и longlongs. Я ожидаю, что эти улучшения или подобные ему будут появляться в SDCC в конце концов.Цитата:
Сообщение от Smalovsky
Скрытый текст
It is not really competition -- it's more like cooperation. The "z88dk_callee" and "z88dk_fastcall" function linkages come from z88dk and "smallc" was added to interface easily with library code written for sccz80 which pushes function parameters in left to right order (this is inherited from small C and all compilers derived from small C share this idiosyncracy). These additions allow sdcc to generate clean and efficient code when calling into z88dk's assembly language libraries. They also serve very well for interfacing with user assembly code. From z88dk's side we adapted most of the library code to sdcc and created a modified version of sdcc (zsdcc) that allows our assembler, z80asm, to be used as back end. The changes involve having sdcc properly generate extern lists and creating a translator to translate asz80 code to standard Zilog (the peepholer relies on asz80 syntax so you cannot change sdcc to generate standard code, something we tried at first). Then our version of sdcc was modified to generate some better code :- this comes from fixing a bug in the peepholer so that it can properly identify which registers are read and written, paired with adding a thousand new peephole rules to fix some of the questionable code sdcc was generating. Also added were some rules to fix some code generation errors and more opportunities for code size optimization when dealing with longs, floats and longlongs. I expect these improvements or similar ones will appear in sdcc eventually.
[свернуть]
SDCC также способен компиляции z88dk __fastcall функции C ++, но он не может генерировать код для функций z88dk_callee абоненту.Цитата:
В случае использования моделей вызова __z88dk_callee и __z88dk_fastcall есть проблемы с вызовом функций по указателю, на что указал Alcoholics Anonymous, но далеко не все функции нужно юзать таким способом, иногда в этом просто нет смысла.
Хорошо:
Код:unsigned int abs(int a) __z88dk_fastcall
{
if (a < 0)
return -a;
return a;
}
Но есть проблемы с указателями на функции. SDCC не сможет генерировать указатель вызовы функций z88dk_fastcall или z88dk_callee функции, если это не разрешено использовать IY (так что вы не можете скомпилировать с "--reserve-регуляров-гу»). Существует также проблема, что расстраивает z88dk_fastcall и z88dk_callee являются частью типа функции. Это должно быть так, потому что компилятор должен знать, как вызвать функцию.
Скрытый текст
But there are problems with function pointers. sdcc will not be able to generate function pointer calls to z88dk_fastcall or z88dk_callee functions unless it is allowed to use IY (so you cannot compile with "--reserve-regs-iy"). There is also the frustrating problem that z88dk_fastcall and z88dk_callee are part of the type of the function. It has to be that way because the compiler has to know how to call the function.
[свернуть]
So:
Это означает, что вы должны иметь три ароматы указателей на функции, которые не могут быть взаимозаменяемыми.Код:int func1(int a);
int func2(int a) __z88dk_fastcall;
int (*f)(int a);
int (*g)(int a) __z88dk_fastcall;
f = func1; // OK
f = func2; // error
g = func1; // error
g = func2; // ok
g = (int (*)(int a) __z88dk_fastcall)func1; // ok (I think) forced cast
g(-10); // does not work as call is via fastcall linkage without parameter on stack
Чтобы обойти эту проблему, в z88dk мы делаем все звонки через указатели на функции, используя стандартную связь и обеспечивают две точки входа для каждой функции: одну стандартную связь и одну азЬсаИ или вызываемого абонента. Если функция присваивается указатель на функцию, она всегда задается точка входа со стандартной связью. Во всех остальных случаях используется азЬсаИ или вызываемая связь.
Скрытый текст
This means you must have three flavours of function pointers that cannot be interchanged.
To get around this, in z88dk we do all calls through function pointers using standard linkage and provide two entry points for each function: one standard linkage and one fastcall or callee. If a function is assigned to a function pointer, it is always given the entry point with standard linkage. In all other cases, the fastcall or callee linkage is used.
[свернуть]
In z88dk:
Код:unsigned char *(*f)(unsigned int s);
unsigned char *a;
f = malloc; // standard linkage entry point
a = malloc(100); // fastcall linkage
a = f(100); // standard linkage
Существует только один вид указателя функции и выбор стандартной связи по сравнению с азЬсаИ или вызываемая является прозрачным. Это делается с помощью соответствующих макросов в файле заголовка. Вы можете увидеть, как в одном из заголовков:
Скрытый текст
There is only one kind of function pointer and the selection of standard linkage versus fastcall or callee is transparent. This is done with appropriate macros in the header file. You can see how in one of the headers:
[свернуть]
http://z88dk.cvs.sourceforge.net/vie....8&view=markup
Это невозможно с генератором тока кода. Все z80 компиляторы были написаны начиная с идеей кадра стека, так что никто из них не сможет сделать это. Даже дискуссии я видел здесь о LLVM начинать с предположения кадра стека, так это опять-таки не было бы возможно с такой компилятор. (Существует еще один фронт компилятор конец вокруг под названием vbcc, который предназначен для пытается передать параметры через регистры, это было бы хорошим кандидатом для z80 компилятора, если у кого есть время, чтобы посмотреть на него).Цитата:
Пока что __z88dk_fastcall не тянет на идеал (можно только 1 параметр передавать), но, надо думать, идея получит развитие, я на это очень надеюсь.
Z88dk_fastcall и z88dk_callee связи то, что может быть сделано после того, как генератор кода уже написано. Вы можете попытаться придумать связи аналогично азЬсаИ, скажем, два параметра, но при добавлении параметров вы добавляете сложность кода, ведущих к вызову, потому что теперь компилятор должен жонглировать значения в правильные регистры и что не приходят бесплатно. Я смотрел на это некоторое время назад, и решил, что z88dk_callee был, вероятно, лучший компромисс, поскольку это позволяет ASM процедуры для сбора параметров в регистры через стек, используя минимальное число толчков и хлопков. АзЬсаИ связь по двум параметрам не всегда может привести к лучший код, чем 21-цикл PUSH / поп-пары при получении значения в двух регистрах. Возможно, в определенных обстоятельствах, как мимо двух символов это могло бы быть лучше, но я не думаю, что это стоит. Есть еще много других областей для улучшения, которые будут иметь большее влияние, я думаю.
Скрытый текст
This is not possible with the current code generator. All z80 compilers have been written beginning with the idea of the stack frame so none of them will be able to do this. Even discussions I have seen here about LLVM begin by assuming a stack frame so this again would not be possible with such a compiler. (There is another compiler front end around called vbcc that is designed for trying to pass parameters via registers; it would be a good candidate for z80 compiler if anyone has the time to look at it).
The z88dk_fastcall and z88dk_callee linkages are what can be done after a code generator is already written. You can try to come up with a linkage similar to fastcall for, say, two parameters but when you add parameters you add complexity to the code leading up to the call because now the compiler has to juggle values into the right registers and that does not come free. I looked at this some time ago and decided that z88dk_callee was probably the best compromise as it allows asm routines to gather parameters into registers via the stack using the minimum number of pushes and pops. A fastcall linkage for two parameters may not always produce better code than a 21-cycle push/pop pair when getting values into the two registers. Perhaps in specific circumstances like passing two chars it might be better but I don't think it's worth it. There are still a lot of other areas for improvement that would have more impact I think.
[свернуть]
Alcoholics Anonymous, the model __z88dk_fastcall is the thing that I really needed and did not have earlier in SDCC compiler, and I am very happy now that there are models __z88dk_fastcall and __z88dk_callee. __preserves_regs is a very interesting feature too! And all they are really useful for practical coding, and not only for compatibility with libraries written for other compilers, as written in the manual. And for new libraries design with so effective passing parameters to functions, which is close to pure assembler. Great thing! And many thanks to all those who made it possible, firstly thanks z88dk team, of course!
I still haven't tried your peephole optimizer, but I'll exactly do it in the near future.
How do you look at the idea to extend the concept of the model __z88dk_fastcall ? Now it allows only one parameter of 8, 16 and 32 bits size. You can allow using more parameters, wherein the first byte of a first parameter to be placed in L, the second byte in H, after it, in E, D, C, B, A, IY.
That is, for example, three parameters of "void PutPixel (unsigned char x, unsigned char y, unsigned char color)" will be placed: x in L, y in H, color in E. The three parameters of "void PutPixel3D (int x, int y, int z)" will be placed: x in HL, y in DE, z in BC. Etc. Such model would be even more useful than current __z88dk_fastcall. What do you think?
Использую SDCC. Перенёс функции в библиотеку - написал заголовочный файл и файл описаний. Подключил библиотеку через #include "...". Скомпилированая программа вылетает с сообщением о неправильном цвете чернил. Хотя если функции в одном файле с главной функцией программы - то всё работает.
Почему так происходит?
Недостаточно информации. Кажи код.
Код тут не причём. Я в главной функции закомментировал вызовы функций. Результат - программа не работает. Если закомментировать include компилируется и запускается. Может дело в каких-нибудь ключах компилятора?
- - - Добавлено - - -
В моём проекте нет crt0.s, а адрес размещения кода задаётся --code-loc. Я подумал, надо добавить crt0.s.
Возьму пример отсюда http://www.speccy.pl/articles.php?article_id=22
На сайте есть примеры интересных решений из области MCU:
__sfr __at 0xfe border; // port for border colour setting
__sfr __banked __at 0x7ffe keyboard; // port for reading keyboard (space)
это объявление ячеек с фиксированными адресами как специализированных регистров.
Этот сайт нельзя показывать и BlastOFF'у и wbr'у, а то они быстро найдут дополнительную аудиторию для своей газеты.))
Я всегда удивлялся, зачем люди придумывают себе такие сложности. Хотя до простоты нужно идти часто ещё дальше. В данном случае люди спотыкаются об генерацию tap, конвертирование ihx в bin, вот этот самый crt0 - нужен или нет? Smalovsky, возьмите EmuZWin и пройдите программу по шагам, там это легко. Задайте в PC стартовый адрес своего машкода, откройте дебаггер и прошагайте по F7/F8 весь код, и ошибка непременно найдётся.
Цитата:
Сообщение от Oleg N. Cher
Скрытый текст
The best way to see what the problems are is to try to write the code by hand that the compiler will have to write ahead of a function call. Use a real compiler-generated assembly listing and try to modify code leading into those calls to use fastcall linkage like this. The issue with forcing the compiler to place values into registers is that as registers are given their values, the compiler can no longer use those registers to gather more values. This leads to a lot of code ahead of the call.
So in "void PutPixel3D (int x, int y, int z)" after putting x into HL, the compiler can no longer use HL to put y into DE. After it puts y into DE the compiler cannot use HL or DE to put z into BC. The code will be poor unless x,y,z are static variables. This is what I meant by the callee linkage being quite a good compromise -- because it allows the parameters to be gathered without register restriction and it only costs 21 cycles / 2 bytes for the push before the function call and the pop inside the function. Better, the called function can pop the values into the registers it needs them in whereas using a fastcall linkage like this the called function will have to shuffle the registers into the correct destination registers.
You might be thinking that the parameter gathering into registers from local values is not a big deal since it can be done easily with (ix+d) offsets. But the compiler needs to stay away from ix as much as possible to get any sort of decent performance or decent code size. sdcc tries to keep things in registers, as it should, and only spills to (ix+d) or the stack when it has to. If it has to gather values into specific registers, I think you will see a lot more pushing/popping to save registers or even storing in temporaries created by the compiler and indexed by ix, which is what sdcc does when it has too many variables in its working set.
In specific circumstances like gathering two chars into HL, it's very a likely a win but I'm not too enthusiastic about other cases for the reasons mentioned above.
[свернуть]
Лучший способ, чтобы увидеть, какие проблемы есть, чтобы попытаться написать код вручную, что компилятор должен будет написать впереди вызова функции. Используйте реальный компилятор сгенерированный ассемблерный листинг и попытаться изменить код, ведущий в те вызовы использовать азЬсаИ связь, как это. Проблема с заставляя компилятор поместить значения в регистры, что, как регистры приведены их значения, компилятор больше не может использовать эти регистры, чтобы собрать больше значения. Это приводит к большому количеству кода перед вызовом.
Таким образом, в "ничтожной PutPixel3D (INT х, у Int, Int г)" после того, как положить х в HL, компилятор больше не может использовать HL положить у в DE. После того, как он ставит у в DE компилятор не может использовать HL или DE, чтобы положить в г до н. Код будет плохим, если х, у, г не статические переменные. Это то, что я имел в виду вызываемым связи будучи довольно хороший компромисс - потому что это позволяет параметры должны быть собраны без ограничений регистра и стоит всего 21 циклов / 2 байта для толчка перед вызовом функции и поп-музыки внутри функции. Лучше, вызываемая функция может выскочить значения в регистры он нуждается в них в то время как с помощью азЬсаИ связи, как это вызываемая функция придется перетасовать регистры в соответствующие регистры назначения.
Вы можете подумать, что параметр сбора в регистры из локальных значений не имеет большого значения, так как это может быть сделано легко с (IX + D) смещений. Но компилятор должен держаться подальше от IX как можно больше, чтобы получить какой-либо достойной производительности или достойного размера кода. SDCC пытается держать вещи в регистрах, как и положено, и только разливает к (IX + D) или в стеке, когда он должен. Если он должен собрать значения в конкретные регистры, я думаю, вы увидите гораздо больше, толкания / выскакивают, чтобы сохранить регистры или даже хранить в современниками, созданных компилятором и проиндексированных IX, которая является то, что SDCC делает, когда он имеет слишком много переменных в его рабочий набор.
В конкретных обстоятельствах, как сбор двух символов в HL, это очень вероятный выигрыш, но я не слишком энтузиазма по поводу других случаев по причинам, указанным выше.
Учитесь у буржуя=) Мысли по делу излагать. Мини Хелп с разжёвыванием как оно работает.
Хотя он там об оптимизации кода говорит или ... Да и пусть. Любитель.
- - - Добавлено - - -
Вы еще Си не нашли, тогда вам к нам HI-TECH Z80 C Compiler. Занимает 30кБ +30кБ +30кБ. Адекватен. Понятен. Доступен всем!!!
- - - Добавлено - - -
HI-TECH Z80 C Compiler написан на Си HI-TECH Z80 C Compiler. ВО!!!. Академичные алгоритмы мало интересны для Z80 если они не могут переплюнуть разработку 83 года) Тем более не адекватностью генерируемого кода зашкаливает у новоделов.
Знаем, смотрели Си HI-TECH Z80 в IDA Pro с хитрыми макросами. Написан на СИ.
HI-TECH Z80 C Compiler запускается из-под CP/M. Во! ;-) И имеет глюки, которые уже никто не исправит. Тоже во! ;-) И нам без разницы на чём он написан, потому что исходников нет. И эмоциями тут делу не поможешь.
Smalovsky, насчёт вашего глюка. Я рискну предположить, что вы инклюдите не хидер *.h, а *.c-файл. Это плохо. Потому что инклюдить нужно только хидеры, как бы руки ни чесались. Так задумано.
Второе, это наверняка ваша main() расположена не первой, а программа стартует с самой первой функции. Из-за отсутствия правильного crt0, который переходит к стартовой точке - ф-ции main().
Всё это вкупе даёт такой глюк:
Программа будет стартовать с первой ф-ции из файла mufuncs.c - рискну предположить, что там ф-ция задания цвета, которая получает на вход случайный аргумент?Код:#include "mufuncs.c" // <--
void main(void) {
return;
}
Рискну предложить такой crt0:
Записываете его в файл crt0.s и ассемблируете:Код:.module crt0
.globl _main
jp _main
Цитата:
sdasz80 -o ..\crt0.rel crt0.s
У меня нет эмоций. Все понятно, и еще раз понятно.Цитата:
Сообщение от Oleg N. Cher
Мучайтесь дальше=)
Мазохисты форевер уже лет 20)
Мы наслаждаемся...
- - - Добавлено - - -
Как будто бы сношаться с эмулем CP/M это не мазохизм?
Я вот сделал ставку на SDCC в своё время, и ни капельки не жалею. Компилятор жив, открыт, мультиплатформенн, развивается, можно пообщаться с разработчиками. Пока я совершенствовал Ofront, команда SDCC развивала мой бэк-энд. А с учётом появления фич __preserves_regs, __z88dk_callee и __z88dk_fastcall мне вообще все другие компилеры не пригодятся. Кстати, HITECH C неоптимально использует стек при передаче однобайтовых параметров ф-циям. А в версии 7.50 есть глюки, на что указал мне приватно Alcoholics Anonymous. А юзать компилер с глюками и без надежды на их исправление - та ещё байда.
Так что "где-то когда-то видел в дизасме код, и я тащусь" слабо актуально. Это вы ещё не видели код после peephole оптимизатора z88dk-sdcc.
- - - Добавлено - - -
Да, кстати, а есть в HITECH C возможность не занимать рег. IY? В SDCC есть --reserve-regs-iy. И вообще, прислушиваться надо к мнению тех, кто кодил на нём, а не "где-то что-то" видел. ;)
Немного разобрался. crt0.s нужен был. Взял с форума тэсэлыча.)) У денпопова в тетрисе такой же.
Проект компилируется, запускается подготовленный тап. Только компилятор глобальный массив инициализирует с ключевым словом const - иначе никак. Может, получше crt0.s найду потом - пока этого хватит.
Я тут написал inkey().
unsigned char inkey(){
__asm
ld a, (23560)
ld l, a
ld h, #0
ld a, #0
ld (23560), a
ret
__endasm;
}
Только функция чего-то символы псевдографики и udg ловит. Стартаповый файл, видимо, режим ввода меняет. Буду разбираться.
- - - Добавлено - - -
Ничего не понял... Кукую переменную надо поменять, что бы изменить режим ввода? Прочитал о MODE и FLAGS. Менял MODE - inkey() ловит коды в режиме G.
Может, лучше задействовать K_STATE( ячейка #5C04( 23556) )?
Если из массива производится только чтение, то const рекомендую и оставить. Иначе же данные массива сдублируются два раза - копия начального состояния массива всё равно будет храниться. Так что это примерно то же самое, что и завести два массива - константный и обычный, и копировать при старте из константного в обычный. Только делается в стартовой секции crt0 неявно. Мой вариант crt0 урезан и эту инициализацию не выполняет.
У меня INKEY устроен иначе:
Код:unsigned char Basic_INKEY (void) {
__asm
LD A, (#0x5C07)
CP #0xFF
JR Z, INKEY_RET_0X$
CALL 0x28E
LD C, #0
JR NZ, INKEY_RET_0X$
CALL 0x31E
JR NC, INKEY_RET_0X$
DEC D
LD E, A
CALL 0x333
LD L, A
RET
INKEY_RET_0X$:
LD L, #0
__endasm;
} //Basic_INKEY
А теперь правильный инкей:Цитата:
Сообщение от Smalovsky
В моём варианте 2048 клавиатура опрашивается так.Код:unsigned char inkey(void) __naked
{
__asm
ld a,(0x5c04) ; BASIC var
ld l,a
1$: ld a,(0x5c04)
inc a
ret z
jr 1$
__endasm;
}
Можно укоротить на 1 байт и 1 такт:
- - - Добавлено - - -Код:ld hl,(0x5c04) ; BASIC var
Здравствуйте, - а как же будут переменные и массивы инициализироваться?!Цитата:
Сообщение от Oleg N. Cher
Ну, до сих пор для ZXDev такого crt0 хватало (в Обероне нет проинициализированных переменных и массивов).
Я тут, кое-что напрограммировал. Делаю головоломку. Оцените скорость генерации уровня и качество перемещения фишки. После изображения уровня нажмите любую клавишу для появления фишки. Пожалуйста, отпишитесь.
По компилятору возникло много вопросов. Например, глобальные переменные видны только main, и их придится передовать в качестве параметров другим функциям. Компилируется с ошибками, когда доступ к стуктуре происходит через указатель.
Вложение 58360
Почитай что нить по си хотя бы классику, Керниган и РитчиЦитата:
Сообщение от Smalovsky
Hitech C CPM уступает по справедливой отрывом z88dk / SDCC. Hitech C v7.50 для DOS ближе. Вы можете взглянуть на некоторые из сравнений, которые мы сделали 10 месяцев назад с использованием реальных программ и общих критериев:Цитата:
Сообщение от OrionExt
http://www.z88dk.org/wiki/doku.php?i...#dhrystone_2.1
С тех пор я не стал бы ожидать больших изменений в скорости для z88dk / SDCC, но некоторые типы программ будет значительно меньше сих пор.
Где Hitech действительно выходит вперед в скорости в плавающей точкой, когда он работает. Но причина этого в том, что реализация флоат Hitech является 32-бит, тогда как z88dk является 48-битный.
Есть и другие факторы, помимо качества генерации кода, которые являются важными или более важными. Такие вещи, как соответствие стандартам качества, библиотек и гибкого набора инструментов. Я бы сказал Hitech был превзойден по всем этим пунктам. Так что нет, я не совсем согласен с вашей оценкой, что современные инструменты не лучше, чем в 1983 г. продукт :)
Существует текущее развитие при помощи LLVM с C фоновым, а затем передавая, что через компилятор Z80 C для генерации кода. LLVM выполняет больше оптимизацию, чем SDCC и, похоже, может быть, LLVM-> sdcc-> z80 может генерировать лучший код. Еще одна интересная возможность это открывает использует LLVM для компиляции других языков на C, которые затем могут быть скомпилированы для Z80. Это именно то, как работает Оберон Олега.
Зачем идти от LLVM-> C, а не LLVM-> z80? Причина заключается в задний конец инструмента LLVM являются не подходят для генерации кода для 8-битных целей. Много усилий придется вложить, чтобы сделать это. Маршрут LLVM-> C ярлык и выглядит, как это может быть нормально, даже для перевода C-> C. Но я думаю, что более интересный аспект будет на других языках, переведенных на C после оптимизации с помощью LLVM.
Скрытый текст
Hitech C CPM is outperformed by a fair margin by z88dk/sdcc. Hitech C v7.50 for DOS is closer. You can have a look at some of the comparisons we did 10 months ago using real programs and common benchmarks:
http://www.z88dk.org/wiki/doku.php?i...#dhrystone_2.1
Since then I would not expect much change in speed for z88dk/sdcc but some types of programs will be significantly smaller now.
Where Hitech does come out ahead in speed is in the floating point, when it works. But the reason for that is that Hitech's float implementation is 32-bit whereas z88dk's is 48-bit.
There are other factors besides quality of code generation that are important or more important. Things like standards compliance, quality of libraries and flexible toolchain. I would say Hitech has been surpassed on all these points. So no, I don't quite agree with your assessment that modern tools are no better than a 1983 product :)
There is current development in using LLVM with a C back-end and then passing that through a Z80 C compiler to generate code. LLVM performs more optimizations than sdcc and it looks like maybe LLVM->sdcc->z80 might generate better code. Another interesting possibility this opens up is using LLVM to compile other languages to C which could then be compiled to z80. This is exactly how Oleg's Oberon works.
Why go from LLVM->C rather than LLVM->z80? The reason is LLVM's back end tools are not suitable for generating code for 8-bit targets. A lot of effort would have to be invested to do that. The LLVM->C route is a shortcut and looks like it might be ok even for C->C translation. But I think the more interesting aspect would be other languages translated to C after optimization by LLVM.
[свернуть]
Alcoholics Anonymous, let me request a feature :-)
Can you improve the functionality of the convention call __z88dk_fastcall to pass not only one argument, but two too? The register that be used for passing the second argument will be determined in advance.
To reduce the complexity, I suggest yet to allow the second argument only of size 1 (or 2) bytes, and use C (or BC) to pass it. For the first argument, let everything is as it is now: L, HL, HL : DE
Yeah, it looks like a half-measure, but can you have a better idea? Or, you never want to pass arguments in this manner?
P.S. I have functions like Plot(char x, char y), Draw(char x, char y), etc, and I want to pass the arguments using registers.
I can have a look at it but it may take a while to get to it.... the to-do list is long :)Цитата:
Сообщение от Oleg N. Cher
Now for a function that uses two arguments, I use this way:
Код:/*--------------------------------- Cut here ---------------------------------*/
unsigned char Basic_ATTR_callee (unsigned char y, unsigned char x) __z88dk_callee {
__asm
POP HL
POP BC
PUSH HL
CALL 0x2583
CALL 0x2DD5
LD L,A
__endasm;
} //Basic_ATTR_callee
/*--------------------------------- Cut here ---------------------------------*/
unsigned char Basic_ATTR_fastcall (unsigned int yx) __z88dk_fastcall {
__asm
LD C,L
LD B,H
CALL 0x2583
CALL 0x2DD5
LD L,A
__endasm;
} //Basic_ATTR_fastcall
If the token ATTR_fastcall is defined, two unsigned char arguments x, y are packed to one unsigned int, and calls Basic_ATTR_fastcall. It's efficient for constant arguments, but may has some calculations in run-time for non-consts - the inevitable overhead of this method. So the solutions is rather indirect. And I thought, maybe it is possible to expand the scope of the __z88dk_callee to pass at least two 1-byte arguments in registers.Код://----------------------- ATTR (y, x: TextCoords): UBYTE -----------------------
extern unsigned char Basic_ATTR_callee (unsigned char y, unsigned char x) __z88dk_callee;
extern unsigned char Basic_ATTR_fastcall (unsigned int yx) __z88dk_fastcall;
#ifndef ATTR_fastcall
# define Basic_ATTR Basic_ATTR_callee
#else
# define Basic_ATTR(y,x) Basic_ATTR_fastcall(((x)<<8) + (y))
#endif
P.S. Excellent developers have the to-do list is long always ;-)
А у меня вопрос - можно ли использовать не поддерживаемые компиляторы си - хайтеч и иар? Разрешено ли их использование в коммерческих целях без лицензии ?
только в играх без магии
Когда-то переписывался с IAR на тему использования их компилятора для Z80, мне предложили его купить, выслали демо-версию со сроком работы 1 мес. Про хайтек не в курсе. Но скорее всего он так и помер коммерческим продуктом, никто его безплатным не делал.
Чем SDCC не устраивает? Вкуснейший компилятор, особенно в свете фич __z88dk_fastcall, __z88dk_callee, __preserves_regs. Или z88dk?
что там вкусного? баги двухлетней давности не могут устранить, а новые только плодятся. проекты собираются по 10 - 15 минут на 4х головой машине. от версии к версии один и тот же исходник перестают собираться и его каждый раз нужно править.Цитата:
Вкуснейший компилятор, особенно в свете фич __z88dk_fastcall, __z88dk_callee, __preserves_regs. Или z88dk?
что-то не очень вкусно, знаете ли.
Чтобы устраняли баги - надо их активно репортить. Да, некоторые зависают, бывает. Но это издержки разработки. В отличие от багов, которые уже никогда не исправят в хайтек и иар Си, это, знаете ли, очень приемлемо.
Вопросы раздельной компиляции мы уже обсудили. Руки отрывать за монолитный исходник. Более того, в SDCC можно воспользоваться старым аллокатором регистров (его оставили) --oldralloc, он шустрее. Такая длительная компиляция, как я понимаю, она из-за поиска оптимального размещения в регистрах, реализована, видимо, перебором.
"От версии к версии перестаёт собираться и надо править" - а что ж вы хотели, не всегда есть смысл тащить совместимость с отмершими вещами. Например, убрали обязательный фрейм PUSH IX : LD IX, 0 : ADD IX, SP для каждой функции, так что же, плакать из-за этого? Да я лучше порадуюсь и код перепишу, эффективнее будет.
Обращались ли вы IAR в последнее время? Они не упоминают свои Z80 инструменты на их веб-страницы больше.Цитата:
Сообщение от Oleg N. Cher
Hitech был куплен Microchip которого первым делом должен был убить всех компиляторов Hitech, не связанные с ПОС. До этого было сделано, Hitech дал разрешение на использование и распространение компилятор C, который работает на CP / M (не версия DOS, которая работает под управлением MS-DOS).
Скрытый текст
Did you contact IAR recently? They don't mention their z80 tools on their webpage anymore.
Hitech was bought by Microchip whose first order of business was to kill all Hitech compilers not related to the PIC. Before that was done, Hitech gave permission to use and distribute the C compiler that runs on CP/M (not the DOS version that runs under MSDOS).
[свернуть]
Дайте z88dk попробовать. Мы ликвидировали множество ошибок в SDCC и получили доступ к библиотекам SDCC z88dk в, которые написаны в машинном коде и гораздо более полным. Она может быть нацелена спектра непосредственно без махинаций с КРТ и программ будет быстрее и меньше по сравнению с нативным SDCC. Вы можете собрать любое количество исходных файлов (ASM или С среди них) в одну линию прямо к водопроводной или двоичном.Цитата:
Сообщение от Sayman
Скорость компиляции является медленным, согласился, но вы можете уменьшить оптимизацию при разработке, чтобы ускорить или настроить Makefile только перекомпилировать файлы, которые изменились.
Я бы не использовать старую ralloc в SDCC - есть много ошибок в там.
Скрытый текст
Give z88dk a try. We've eliminated many of the bugs in sdcc and given sdcc access to z88dk's libraries, which are written in machine code and are much more complete. It can target the spectrum directly without fiddling with the crt and programs will be faster and smaller compared to native sdcc. You can compile any number of source files (asm or c among them) in one line straight to tap or binary.
The compilation speed is slow, agreed, but you can turn down the optimization while developing to speed things up or set up a makefile to only recompile files that have changed.
I wouldn't use the old ralloc in sdcc -- there are many bugs in there.
[свернуть]