Кодогенерацию в универсальном компиляторе гораздо сложнее сделать чем специализированном
Кодогенерацию в универсальном компиляторе гораздо сложнее сделать чем специализированном
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Как, кстати, получить доступ к локальным переменным функции в SDCC со стороны ассемблера ?
Последний раз редактировалось Smalovsky; 08.03.2016 в 17:00.
¡Un momento, señor fiscal!
По честному - никак.Сообщение от Smalovsky
С включённым оптимизатором (по умолчанию), sdcc может размещать локальные переменные в регистрах и/или на стеке.
Т.е. оптимизатор сам решает какие локальные переменные, он разместит в регистрах, а какие положит на стек.
(Обычно берутся не более 4 байт в регистры, а остальное всё на стеке. Но этот порядок, естественно, может меняться в будущих версиях.)
Если пишите, нечто очень критичное по скорости (игру), то рекомендую не использовать локальные переменные вообще.
Просто пишите static перед всеми переменными. Тогда sdcc будет генерить код для "локальных переменных" , который будет работать гораздо быстрее.
Но минусы есть:
- про рекурсию можно забыть
- прога будет хавать памяти чуть поболее,
(т.к. все локальные переменные будут висеть в сегменте данных, а не динамически распределятся на стеке)
V6Z80P - Back for Good
Смысл функции в инкапсуляции того, что она делает внутри, и выдвигании наружу только интерфейса вызова. То есть то, что ф-ция скрывает механизмы и детали её реализации, гарантирует безболезненную её доработку и т.п. И иметь доступ к локальным переменным ф-ции в этом смысле не есть правильно. Если вызываешь кусок на асме, оформь его как другую ф-цию и вызывай из первой сишной, передавая локальные переменные ей как параметры. Это и будет правильно.
P.S. Регистровых параметров в SDCC нет, знаю. z88dk тогда.
z88dk заменяет задний конец SDCC с его собственным. Выход SDCC переводится в стандартный Zilog нотации, а затем собрана z80asm, ассемблере z88dk в. Все ассемблере в проекте написано для z80asm.
Вот некоторые из SDCC выход при использовании через z88dk, где вы можете увидеть стандартные обозначения для индексированной адресации регистра:
Скрытый текст
z88dk replaces sdcc's back end with its own. sdcc's output is translated to standard zilog notation and then is assembled by z80asm, z88dk's assembler. All assembly language in a project is written for z80asm.
Here's some output from sdcc when used through z88dk where you can see standard notation for indexed register addressing:
[свернуть]
Код:ld hl,0x0006 push hl push bc call __divsint_callee ex de,hl ld hl,0x0001 add hl,sp ld (ix-2),l ld (ix-1),h
Там ничто не мешает никому делать то же самое для любого другого сборщика, но вы должны иметь достаточно способный ассемблер действовать в качестве замены. Ассемблер должен иметь связывающую способность и она должна реализовать секции кода. Есть только несколько свободных Z80 монтажников, доступных, которые реализуют эти возможности. (Sjasm не является одним из них)
Скрытый текст
There is nothing stopping anyone from doing the same for any other assembler but you have to have a sufficiently capable assembler to act as replacement. The assembler needs to have linking ability and it must implement code sections. There are only a handful of free z80 assemblers available that implement these capabilities. (sjasm is not one of them)
[свернуть]
Когда SDCC используется через z88dk, он получает доступ к библиотекам z88dk ассемблере в. Ассемблере снова близко к пользователю.Не припоминаю чтобы к сдцц можно было бы прикрутить тот же sjasm для генерации z80 кода. Опять таки, довольно справедливое замечание про решётку. Похоже, что асм от сдцц вообще десятичные числа не воспринимает, точнее воспринимает но, только с этой пресловутой решёточкой. сдцц, как и z88dk, базируется на древнем цпм компиляторе small-c. Только вот z88dk по части асма более близок к пользователю, а в sdcc всё сильно извратили. К слову говоря о бесплатности и "лучшести" - не совсем близкие значения. Может для всяких pic`ов и подобных он и лучший, но для z80 не фонтан, откровенно говоря.
Скрытый текст
When sdcc is used through z88dk, it gains access to z88dk's assembly language libraries. The assembly language is again close to the user.
[свернуть]
Вы не можете судить на основе выборки из очень короткой подпрограммы, написанной на C. Вам нужно больше и большие примеры, чтобы сделать общие выводы. SDCC иногда не генерирует код, но нам удалось улучшить, что, когда SDCC используется через z88dk. Вот результаты некоторых тестов мы запускаем с использованием больших программ и стандартных эталонных тестов:Даже твои тесты показывают, что sdcc уступает древнему и бесплатному htc (кстати, ты табличку так и не подправил).
Скрытый текст
You can't judge based on a sample of a very short subroutine written in C. You need more and larger examples to draw general conclusions. sdcc does sometimes generate bad code but we have managed to improve on that when sdcc is used through z88dk. Here are the results of some tests we've run using large programs and standard benchmarks:
[свернуть]
* Dhrystone 2.1 (common integer benchmark)
z88dk+sdcc: 7136 bytes, 310.29 dhrystones / second
sdcc: 7223 bytes, 250.12 dhrystones / second
htc 7.50: 7040 bytes, 265.11 dhrystones / second
Almost the same size, htc is 17% slower.
* Whetstone 1.2 (common floating point benchmark)
z88dk+sdcc: 5914 bytes, 4.351 kwips
sdcc: 14463 bytes, 1.418 kwips
htc 7.50: 6872 bytes, crashes ( htc 3.50 for cpm 6.276 kwips )
С плавающей запятой часто выходит из строя и генерирует неправильные ответы с 7.50 HTC. Я не знаю, если HTC 7.80 зафиксировано, что. Время вместо взято из 3.50 для HTC имп и быстрее, чем z88dk + SDCC. Это потому, что z88dk реализует 48-битный с плавающей точкой, тогда как реализует HTC 32-битной плавающей точкой.
Скрытый текст
Floating point frequently crashes and generates wrong answers with htc 7.50. I don't know if htc 7.80 fixed that. The time is instead taken from htc 3.50 for cpm and is faster than z88dk+sdcc. This is because z88dk implements a 48-bit float whereas htc implements a 32-bit float.
[свернуть]
* Pi (tests long integer arithmetic)
z88dk+sdcc: 6165 bytes, 15 min 47 sec
sdcc: 6805 bytes, 37 mins 3 sec
htc 7.50: 6332 bytes, 23 mins 0 sec
Есть несколько вариантов для z88dk + SDCC, самый быстрый из которых 5 мин 40 сек и 7500 байтов. Это в четыре раза быстрее, чем HTC.
Скрытый текст
There are several variations for z88dk+sdcc, the fastest of which is 5 mins 40 sec and 7500 bytes. That's four times faster than htc.
[свернуть]
* clisp (large program 1279 lines, lisp interpretter many longs) compiled for cpm
z88dk+sdcc: 30155 bytes
sdcc: missing library functions
htc 7.50: 32186 bytes
* startrek (large program 2153 lines, some float math) compiled for cpm
z88dk+sdcc: 32053 bytes
sdcc: missing library functions
htc 7.50: 41038 bytes
* eliza (352 lines, uses several stdio functions on input and output sides) compiled for cpm
z88dk+sdcc: 8324 bytes
sdcc: missing library functions
htc 7.50: 15193 bytes
Это всё понятно и хорошо выглядит "на картинках". мне не понятно, зачем применять такие извращённые методы сборки, как совмещение двух разных компиляторов? если уж на то пошло, почему просто не дизасемблировать тот же htc 3.09 for cp/m, который бесплатный и не применить кодогенерацию по его образу и подобию+свои оптимизации. Сильно не удобно, если честно, использовать длинные конструкции для сборки одного кода из двух разных компиляторов, пусть и в обном bat файле. Запоминать гору ключей, библиотек. Это всё заморочки не нужные. Куда проще взять эмулятор cpm для windows, взять бесплатный htc и спокойно мелким батником это собирать. Хотя и make хорошо прикручивается.
Опять таки, сидел ставил эксперименты по тематике ray casting`а понял, что sdcc всё ровно выдаёт более тяжёлый код, даже на фоне старого htc. А уж применять замудрённые конструкции из z88dk и sdcc в одном флаконе, я даже и думать не собирался. сделайте нормальную кодогенерацию z88dk без применения жёстких танцев с бубном, тогда и интерес появится. Кстати, во всех этих извратных манипуляциях и библиотеках, поддержки спринтера так и нет.
а смысл? проще использовать эмулятор cp/m и ничего не дизассемблировать, даже можно собрать эмулятор с образом, переадресацию аргументов сделать и будет 1 файл, хотя смысла особого нет.
очень хочется иметь всё тот же htc, но именно виндовый, чтобы каталоги понимал, нормальные пути и файлы генерил с точностью до байта, а не до 128 байт как cp/m`ный. Если бы его разобрать и создать компилятор под винду с уровенм качества кода как у htc, было бы здорово. но sdcc как и z88dk пока не дотягивают. Кроме того, у асма для htc есть серия ошибок и не доработок как, например, нет поддержки недокументированных регистров типа ixh, ixl и подобных, нет макросов, нет разных прочих интресных и удобных конструкций. Можно было бы применять htc 7.80, но он для ms-dos`а, т.е. его употребление ещё более геморное, т.к. требует запуска dosbox`а.
Ну так речь о части той же функции на ассемблере, с тем же автором, никаких инкапсуляций не нарушается. Смысл вставки в ускорении этой функции, и неправильно - городить для этого лишний вызов. Оптимизацию, конечно, надо блокировать, в идеале - только для данной функции (помнится, на песюках в лохматые времена компилятор, встретив ассемблерную вставку, нафиг отключал оптимизацию всего модуля и перезапускал компиляцию, не знаю как выкручиваются сейчас)
Прихожу без разрешения, сею смерть и разрушение...
можно несколько inline функций сделать, которые будут разные регистры устанавливать, это если речь идет о функционале а не оптимизации
ldA, ldBC, ldBCDE итд
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
