АА> ! Вместо процедур клары PEEK, POKE
АА> ! можно использовать
АА> !
АА> ! MoveMemory(Long adrto,long adrFrom,long
АА> ! sz),bool,proc,pascal,name('RtlMoveMemory')
АА> !
АА> ! 1-параметр адрес куда записывается
АА> ! 2-параметр адрес куда пишется
АА> ! 3-размер копируемых данных
АА> !
АА> ! Александр Бирюков
АА> Очень интересно! А ты не пробовал посмотреть эту ф-ю на ассемблерном уровне?
АА> Это одна asm-команда копирования строки (через запись адресов и длины в
АА> регистры) или они побайтно копируют? Для меня это очень актуально (надо
АА> поднять скорость приложения, а оно по большей части именно память с места на
АА> место копирует).
АА> И как у этой ф-ии с совместимостью между версиями? И как она представлена в
АА> разных режимах линковки (Local/Stand..)?
Делать замену операторов PEEK()/POKE() имеет смысл только для структур или массивов. Так как для стандартных типов BYTE-LONG, компилятор заменяет эти операторы на одну-две асм-инструкции.
И если уж делать их замену, то лучше вместо предложенной API-шной функции использовать аналогичную из ядра Клариона — _memcpy:
CopyMem(LONG _AddrTo,LONG _AddrFrom,UNSIGNED _Size), |
LONG,PROC,NAME('_memcpy')
Дело в том, что данная процедура написана довольно грамотно и не содержит ничего лишнего, что могло бы замедлить ее работу. Вплоть до того, что там вначале несколькими операторами определяется возможность использования оператора MOVSW вместо побайтового копирования оператором MOVSB. И уже «хвостик» копируется побайтно. А структуры размером до 20 байт вообще копируются простыми операторами MOV, что еще быстрее. Кроме того, эта процедура вызывается через NEAR при любом режиме сборки приложения, что намного быстрее дальних вызовов API-шных процедур через FAR, особенно при их использовании в циклах. И еще один плюс по быстродействию в ее пользу — она, как и все Кларионовские процедуры, принимает параметры через регистры, что быстрее чем стек.
Насчет совместимости между версиями — она существует еще с досовой версии.
Только одно замечание:
В этой процедуре нет проверки на нулевые адреса, что может вызвать GPF. Так-то, желательно перед передачей в эту процедуру адресов проверить их на валидность. Это, естественно, не касается адресов статических переменных, объявленных в программе.
В догонку, сейчас посмотрел, как реализована предложенная процедура RtlMoveMemory(). Практически аналогична _memcpy, только отсутствует оптимизация для длин меньше 20 байт.
И также нет проверки на валидность адреса! Так что, не только Кларион этим страдает! Здесь, я думаю, «ноги растут» из общего «предка» — С. Да — компактен, быстр. Но за счет снижения надежности!