Ни разу не долго. Если у тебя на входе пара 8-битовых аргументаСообщение от Sinus
и на выходе 8-битный результат, то пользуясь соглашениями hitech-c писать можно. Вот если возвращается структура и передаётся полсотни аргументов... да, сложно. Но "классический спектрумовский" метод, статическое выделение памяти, и такого не даёт.
Рецепт называется perl. И вообще, "оставьте программмирование программатиру".надо упростить труд программиста, а не усложнять его.
Никто может и не будет. А я был, есть и буду использовать.использовать C поголовно никто не будет (100%), спек для асма.
Ибо считаю, инструментик нужно по размеру выбирать, всё одним
не очень получается.
Никто не против передачи через регистры. Все двумя руками за.а на асме ничего лучше передачи через регистры никто не придумал.
Проблема:
* регистров мало и на все аргументы может не хватить;
* есть разные типы данных -- нужны определённые соглашения
по их передаче через регистры;
* если вы не фанат паскаля то должны слышать о фунциях с
переменным числом аргументов;
* нужно как-то возвращать значения, как-то определённым
образом;
* передача данных через статически выделенную область
памяти чревата неприятностями при использовании
рекурсивных и, как это сказать, повторно вызываемых,
функций...
HiTech-C решает эти проблемы как может. Самое главное -- он даёт возможность записав прототип функции на языке C однозначно определить порядок её вызова. Для любой функции можно сказать,
не роясь в документации, какие регистры нужно сохранять, а какие нет. И наконец -- появляется возможность благодаря перечисленному выше генерировать код из программы на языке C. Уже даже не важно каким компилятором.
Они идут вразрез может быть в твоём конкретном случае. Не более того.надо понимать, что идея и концепция это хорошо, но когда они идут вразрез с удобством, то такие идеи надо выкинуть.
Так B или BC? Это уже вопрос. А далее можно покритиковать. Практически любая функция подразумевает какие-либо вычисления, аргументом которых выступает собственно аргумент функции. Микропроцессор выполняет арифметические и логические операции над одним из регистров -- аккумулятором. Только над ним. И использовать этот регистр для передачи аргумента значит обязательно заставлять каждую функцию первым делом куда-то сохранять значение аккумулятора-аргумента до выполнения любых вычислений. Только если содержимое аккумулятора не являетсяитак, передача аргументов:
один байт - A
одно слово, адрес - HL
строка - указатель в HL
структура - указатель в IX
счетчик - B или BC
одним из операндом самой первой операции. Кроме того, вызов может доходить до функции-назначения через некоторые промежуточные функции. Где тоже производятся вычисления. Со всеми вытекающими последствиями...
Структура в IX. Большая, если не большая часть структур обрабатывается по большей части последовательно. При условии последовательного доступа на каждый байт структуры тратится
10 тактов (LD A, (HL); INC HL). При доступе через регистр IX в несколько раз больше. И тактов и байт. В целом набегает много.
По указанной же выше причине использование регистра HL -- единственного, кроме индексных регистров, 16-разрядного регистра над которым возможны арифметические операции, в качестве аргумента функции нежелательно. Ровно по той же, описанной выше причине. Я делаю исполючение только для OO-подпрограмм. При вызове виртуальной функции всё равно вычислять адреса функции нужно из таблицы функций, потому там указатель на объект и хранится.
Понимать это как раз не нужно. Ибо ex de, hl занимает 4 такта и один байт.остальные регистры по вкусу.
и надо конечно понимать, что если от передачи адреса на в HL а в DE процедура выиграет допустим 10 байт в размере и 100 тактов, то надо передавать адрес в DE.
Я предложил вариант. Ещё несколько лет назад (hitech-c).однако я не вижу прогресса. давайте завязывать с пустой болтовнёй, определятся наконец с вызовами и описаниями, открывать тему и прогрессировать.
Предполагаю, функции должны обязательно сопровождаться
прототипом для языка C, кроме случая когда их использование
из языка C не имеет смысла. Отходить от C в сторону голого
ассемблера я никакого смысла не вижу. Равно как и не вижу
смысла эконимить, да и экономии не вижу, в более других,
не совемстимых с C решениями. ДОЛЖЕН БЫТЬ ДОСТУПЕН
ИНТЕРФЕЙС С ЛЮБОЙ СРЕДОЙ ПРОГРАММИРОВАНИЯ. И точка.
Поэтому извраты вокруг ассемблера и ALASM в частности не
поддерживаю. C-интерфейс доступен из любого ассемблера,
и из C. Он, может быть, недоступен из других компиляторов.
Впрочем я уже писал, реальной конкуренции там нет, там вообще
чего-то работоспособного -- один IAR. Он или сам настраивается,
или писать обёртку на каждую функцию.
С чего бы это вдруг? Он совместимый и соответствующий, в писишной версии. В CP/M-овской нет. Так она и была ещё до ANSI.тогда такой C компилер надо выкинуть как не соответствующий ANSI.
Ответить с цитированием