OberonCore

Сообщаю о недокументированном подводном камне, который может быть неочевиден.

Сегодня мои ребята долго возились с одной проблемой и не могли понять её причин.
В итоге они с удивлением обнаружили, что SYSTEM.MOVE портит данные, если области источника и приёмника пересекаются (т.е. использовать её для сдвига данных нельзя).

Этого можно было ожидать, но, формально говоря, в документации сие ограничение не отражено.

Это ТОЧНО было в обсужденьи в стародавние времена на КД!
По-моему, даже чуть ли не я сам тогда с этим (в соплях и с дикими воплями) прибегал и жаловался... :о)
Вот, в связи с этим, ещё раз вспоминается благое намерение прошерстить ту первую тему про КП и вычленить ляпы, "подводные камни" и советы, что бы по кругу не ходить.....

В документации материал дан сухо и кратко. Так что M[a1..a1+n-1] := M[a0..a0+n-1] возможно и подразумевало, что копирование идет с возр. адресами. Копировать пересекающиеся блоки можно, если адрес приёмника меньше адреса источника.

Формально говоря, отражено.

В стандартной библиотеке Си есть функции блочного копирования memcpy и memmove.
memcpy немного эффективнее, но имеет тот же недостаток, что и SYSTEM.MOVE.
По этой причине Керниган и Пайк в "Практике программирования" рекомендовали пользоваться исключительно memmove. (Для Си вообще характерны рекомендации не пользоваться отдельными старыми стандартными функциями. Например, функцией gets, в т.ч. и как объектом хакерских атак.)

Предложение: попросить OM AG переписать SYSTEM.MOVE в духе memmove.

Не стоит. Если хочется, можно свою процедуру написать.
Все процедуры из SYSTEM компилируются в 1-2 команды (MOVE в 3).
К тому же некоторые используют MOVE вместо отсутствующей FILL.

Можно и без процедуры (нужны только две кодовые процедуры на одну инструкцию):

Я, конечно, дико извиняюсь, но откуда вам доподлинно известно, что ДО вашего кода флаг D был сброшен? :о)

Доподлинно про ББ не известно, согласен. Предположения такие: это стандарт для WinApi функций, а мы имеем ввиду BB под винду. Поскольку среде так или иначе приходится вызывать WinApi время от времени, в ней должны придерживаться этих же правил.

Я однажды долго не мог понять, почему это прога вылетает и клял MS. А в итоге выяснилось, что я в одном месте флаг поставил в 1, и обратно не сбросил. А потом использовал WinApi ф-ю, которая сама пользовалась strlen. И в нем был ба-бах, от того, что DF=1.

Как раз в ББ известно.

А мне инетерсно - откуда?
Я просто первое, что говорю людям, начинающим программировать (а, тем более - встроенные системы) - "используйте принцип стека! - оставляйте после себя всё так, как было до вас!"

Например, "темплейт" работы с разделяемой переменной (доступной и из обработчика прерывания) следующий:

uint8_t flags = FLAGS_REG;
cli(); // запрет прерываний
... // творим
FLAGS_REG = flags; // А НЕ sti(); !!!

то же касается и других флагов регистра флагов и состояний...
Думаю и в других местах также и тот же принцип...
Тем более, когда в системе есть обратные вызовы и сложная зависимость между библиотеками...

Илит на счёт D - какая-то формальная договорённость существует и оформлена?

вот-вот. история похожа на работу с указателями. если конструкция неявно требует наличия других для нормальной работы значит она черезчур низкоуровнева. то есть - не элемент.

Формальной нет, но фактически код генерируется в расчете на D=0.

Раскройте контекст... Я в затрудненьи.