AA> Как в таких случаях говорят - не ставь телегу впереди лошади.
AA> А прямым текстом - эти макросы были написаны ещё тогда, AA> когда и такой абревиатуры авр никто и не слыхивал.
Я немного позанудствую.
Речь шла отнюдь не о портировании макросов.
15-Mar-05 21:50 Olga Nonova wrote to Leha Bishletov:ON>>> Грамотные ассемблерщики работают в макросах, библиотеку которых
------------------------------^^^^^^^^^^^^^^^^^^^ ON>>> каждый создал и отладил сам для себя. Чисто машинных команд в ON>>> исходниках практически не встречается. Поэтому, для перехода на
---------------------------------------------^^^^^^^^^^^^^^^^^^^^^^^ ON>>> другую платформу перелопачивать килобайты ассемблера вовсе не
------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ON>>> требуется.
------^^^^^^^^^^
LB>> Можно увидеть хотя бы фрагмент этих макросов? Особенно интересно, как
-------------------------------------^^^^ LB>> решается задача по контролю соответствия типов (на С это происходит LB>> автоматически). Еще было бы не плохо, если бы была возможность LB>> организовать т.н. "компилированый стек".
И вот в качестве примера макросов, сильно облегчающих переход на другую платформу (перевод ПРОГРАММЫ, а не этих макросов) выдано несколько макросов, которые, не спорю, облегчают написание и сопровождение программы, но перевод её на другую платформу... "облиште своi дiвочi мрii"
ON> MoveByte MACRO Byt1,Byt2 ON> lds R16,Byt1 ON> sts Byt2,R16 ON> ENDM Всё вроде бы нормально. На первый взгляд этот макрос (макрос, а не программа!) в пол-чиха портируется на любой макроассемблер. На второй - на MCS51 вдруг захочется уточнить - а между чем и чем (data/idata/xdata) этот макрос должен перегонять информацию. Имеется-то, извините, 9 комбинаций. Ну ладно, смело предположим, что мы нашли для MCS51 макроассемблер с операцией spaceof(var), возвращающей пространство размещения Byt1, Byt2 и через условную компиляцию слепили макрос, который делает всё, что надо. На третий - натыкаемся на процессор с одним-двумя аккумуляторами или там вообще с одним рабочим регистром, который портится при использовании легко спортированного МАКРОСА, копирующего память в память. А ПРОГРАММА, на минуточку так, писалась в расчёте на 32-роновый AVR и в 90% (ну пусть 30%, от этого не легче) мест в этих ронах в процессе работы макроса лежала спокойно необходимая для работы информация. И программу перелопачивать всю. А вот с Byt2 = Byt1; таких проблем не будет.
Единственное, на мой взгляд, что действительно перенесётся легко с процессора на процессор благодаря макросам - это "виртуализированные" вычисления. В смысле использования виртуальной машины. Заводим один-два 32-битных аккумулятора (у AVR - на РОН, у pic16 - в регистровом файле, у 68hc11 - в странице короткой адресации). И пишем себе _load varX _mul varX _store temp1 _load varY _mul varY _add temp1 _sqrt _cmp varR brsh куда_надо
Да, такое перенесётся легко после реализации такой же виртуальной машины. Но всё остальное - всё то, что использует не виртуальный вычислитель, а реальное ядро - макросы перенести помогут слабо. И чем эффективнее использует - тем тяжелее перенести (т.е. тем ближе к написанию новой программы глядя на старую как на справку по алгоритмам). А если ВСЯ программа сделана не для реального процессора, а для реализованного на нём виртуального - то как-то тогда не совсем понятно -
1) при чём тут асемблер _реального_ процессора и разговоры о _переносе_ _ассемблерной_ программы, а не о _реализации_ виртуальной машины на другой платформе 2) не лучше ли сразу было взять Forth или слепить с его (или не с его) помощью компилятор нужного задаче-ориентированного языка в "ассемблер" выбранной виртуальной машины.wbr,