Сообщение от
Eltaron
Так проверял. Было б это не так, этот пример бы не работал
Смотрите, Eltaron:
Код:
;HelloWorld.c:15: Basic_BORDER(4);
ld a,#0x04
push af
inc sp
call _BORDER
inc sp
;HelloWorld.c:16: Basic_PAPER(0);
ld a,#0x00
push af
inc sp
call _PAPER
inc sp
Если бы всё было так, как Вы утверждаете, то SDCC сгенерировал бы что-то вроде:
Код:
;HelloWorld.c:15: Basic_BORDER(4);
ld a,#0x04
call _BORDER
;HelloWorld.c:16: Basic_PAPER(0);
ld a,#0x00
call _PAPER
Вот если бы Вы сказали, что есть ключик, который включает безстековую передачу однобайтового параметра, с убиранием кода, генерирующего фрейм [push af : inc sp : call ... : inc sp], тогда другое дело, и Ваше утверждение было бы 100% корректно и имело бы больше смысла и пользы для нас. А Вы призываете пользоваться тем фактом, что параметр попадает в стек именно через регистр A. Это наведённый эффект, и если способ передачи параметров в SDCC изменят (а кодогенерация SDCC активно дорабатывается), например, начнут передавать через другой регистр, то у Вас всё перестанет работать. Я-то могу конечно убрать внутри процедур BORDER, PAPER и др. доставание параметров из фрейма в аккумулятор, но это такая мелочь, на которой много не выиграешь. А вот проблемы в будущем возникнуть могут. Предпочитаю кулхацкерству надёжное программирование. Хотя могу добавить включаемую ифдефом опцию, которая будет “оптимизировать” такие процедуры. Но она будет по умолчанию отключена.
P.S. Настоящий прогресс у нас начнётся, когда кто-то из команды, занимающейся кодогенерацией SDCC, действительно добавит такой ключик. А заодно и превратит “ld a,#0x00” в “xor a” (или “sub a”) – (там, где это даст выигрыш). Или найдётся человек, который пропихнёт такие предложения Филиппу Краузе. Дело за малым. Не сидеть и мечтать об идеальном кодогенераторе, а что-нибудь для этого сделать, хотя бы маленький шаг.
Ответить с цитированием
