Error404 писал:
z88dk может ещё конкуренцию составить. А так SDCC очень неплохой компилятор. Не я один считаю, что SDCC крут.Общепринятый.
Alex Rider, я уже давно исправил функцию. А неправильный вариант можно считать демой. ))
Error404 писал:
z88dk может ещё конкуренцию составить. А так SDCC очень неплохой компилятор. Не я один считаю, что SDCC крут.Общепринятый.
Alex Rider, я уже давно исправил функцию. А неправильный вариант можно считать демой. ))
Последний раз редактировалось Smalovsky; 12.09.2016 в 23:18.
¡Un momento, señor fiscal!
один аргумент забирать можно ПРОЩЕ!Сообщение от 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
С уважением,
Gris / Red Triangle.
_____________________________________
ZX-EVO/TS-Labs config/NGS/HDD/SD-card
Amiga A1200/Blizzard 1230@50/32/60GB
Amiga A1200/Apollo 1260@66/32/60GB
UnAmiga (C5) AGA GM7123 VideoDAC
Ух ты, а я и не знал о такой фишке. Значит, __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 - именно регистровой передачи параметров. Ещё два момента, которые упорно обходят и не реализовывают - это:
- помещение процедур и переменных в отдельные сегменты (аналог 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 в конце концов.
Скрытый текст
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 "...". Скомпилированая программа вылетает с сообщением о неправильном цвете чернил. Хотя если функции в одном файле с главной функцией программы - то всё работает.
Почему так происходит?
¡Un momento, señor fiscal!
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Недостаточно информации. Кажи код.
Код тут не причём. Я в главной функции закомментировал вызовы функций. Результат - программа не работает. Если закомментировать 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'у, а то они быстро найдут дополнительную аудиторию для своей газеты.))
¡Un momento, señor fiscal!
Я всегда удивлялся, зачем люди придумывают себе такие сложности. Хотя до простоты нужно идти часто ещё дальше. В данном случае люди спотыкаются об генерацию tap, конвертирование ihx в bin, вот этот самый crt0 - нужен или нет? Smalovsky, возьмите EmuZWin и пройдите программу по шагам, там это легко. Задайте в PC стартовый адрес своего машкода, откройте дебаггер и прошагайте по F7/F8 весь код, и ошибка непременно найдётся.
Скрытый текст
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, это очень вероятный выигрыш, но я не слишком энтузиазма по поводу других случаев по причинам, указанным выше.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
