Уважаемый Олег! Очень тотально ты приступил к делу, так что желаю тебе успехов!
Поскольку цикл FOR — это настоящая рабочая лошадка, а поэтому действительно заманчиво иметь очень эффективную реализацию, то не помешает рассмотреть ещё и такой вариант. По-моему, он хорошо ложится на внутреннюю структуру Ofront'а.
Итак, Ofront заводит внутреннюю переменную цикла _for__x, где x — некоторое число. Переменная нужна для того, чтобы вычислить B только единожды и хранить в ней.
Макет типичного цикла:
Код: "C"
{
INTEGER n, _for__x;
_for__x = конечное значение цикла;
n = начальное значение цикла;
while (n <= _for__x) {
/* Тело */
n += step; // Прирост шага
}
}
Вычислить количество повторений цикла. Если A и B — константы, то в compile-time.
Если чего-то из них не константа, то вычисляем кол-во повторений в присваивании переменной-счётчику _for__x.
Если цикл не повторяется ни разу или же повторяется один раз, учесть (можно отдать этот момент на откуп сишному компилеру).
Далее сгенерировать следующий код:
Код: "C"
n = начальное значение цикла;
_for__x = количество повторений цикла;
if (_for__x) {
do {
/* Тело */
n += step; _for__x--;
} while (_for__x);
}
Код: "ASM"
LD HL, _for__x
DEC (HL)
JR NZ, LoopStart$
Именно из-за этой конструкции я не предлагаю генерировать, например, это:
Код: "C"
n = начальное значение цикла;
_for__x = количество повторений цикла;
while (_for__x--) {
/* Тело */
n += step;
}
Но наверное второй вариант следует рассмотреть тоже.
Плюсы: условные и безусловные переходы дороги. Они имеют значительно более низкую эффективность даже в современных x86-64 — из-за ограниченного объёма кэша команд и возможного их распараллеливания рекомендуется применять линейные последовательности вычислений с минимумом переходов. Сложение не так дорого, но операции сравнения с нулём — очень дешёвы. В Z80 сравнение двух двухбайтовых чисел, со знаком или без, это целая эпопея с вычитанием (или сложением) регистровых пар и ёмкой засылкой значений из памяти в память. Если счётчик будет типа байт, сравнение его с нулём — одна из самых быстрых операций, которую можно проделать даже прямо в памяти, адресуя переменную через пару HL или индексные регистры, экономя использование других регистров. Если на нуль сравнивается регистровая пара — тоже не больно страшно, всего лишь загрузить регистр младшим значением и сделать OR со старшим. Вобщем, получается хорошо.
Что смущает. Ёмкость вычисления количества повторений цикла не в compile-time. Это как минимум взятие по модулю, но лучше всё-таки сделать такое вычисление один раз в начале цикла, чем n раз внутри него проверять на переполнение.
Трудности. Тип переменной-счётчика для Z80 оптимальнее всего будет задавать на основании вычисленного количества повторений (если известно точно, что их будет <= 255, берём байт. Если точно неизвестно, берём счётчик такого типа, чтобы хватило значений). Здесь неважно, что тип описывается как знаковый, в таком варианте использования он будет фактически без знака.
Ну а вот для Win32 лучше всего будет брать счётчик цикла всегда не меньше, чем INTEGER. И только для длинных циклов LONGINT. Эту проблему надо обдумать.
Идея. Можно даже 256 повторов хранить в одном байте, для этого нужно будет только лишь предусмотреть это в начале цикла. Надо чуть видоизменить код. Как — пока не придумал.
Оптимизация. Не заводить внутренний счётчик, если его значение будет совпадать с n.
Проблема. Предлагаемая реализация цикла нечувствительна к изменению счётчика цикла n внутри цикла. Он всегда будет повторяться единожды заданное при вхождении количество раз. Это может привести к неработоспособности тех программ, которые каждую итерацию цикла полагаются на WHILE n <= (Заранее вычисленное)B. Что, как ни крути, всё-таки жёстко задано в стандарте Оберона-2.
На самом деле я не считаю это серьёзной проблемой, потому что нечего жалеть построителей корявых циклов. Ведь если кому-то нужно чистое WHILE n <= B, то пусть так и пишет, и без всякого FOR.
Вобщем, такие вот мысли. Если я не сделал в рассуждениях явного ляпа, можно попробовать посчитать какой выигрыш будет для разного размера типов на Спектруме (в тактах), и какой — на Win32.
Но сейчас есть возможность продолжить, будем надеяться, плодотворно.