Хочу сказать огромное спасибо этой теме! Прочитав перевод статьи Антона Эртла я всерьёз задумался о том, что именно может сделать автоматически оптимизатор Форта и нашёл неожиданное решение для Каллисто-2, основанное на комбинации шитого и подпрограммного кода. Интересно, был ли у кого-нибудь опыт подобного?
Если кому интересны подробности с набросками кода, вот цитата из моей темы Каллисто-2 в Контакте:
Цитата:
Изначально в Каллисто-2 был предусмотрен шитый код в области двоичных данных. Память программ же отводилась только для примитивов и служебной области — таблицы свёрток, преобразующей байт поля кода в адрес обработчика. Такой подход сильно нагружал область байтовых данных. Сегодня ночью ко мне пришло более совершенное решение, экономящее область данных и повышающее быстродействие Каллисто-2. Если кратко, то предлагается в памяти программ использовать процедурный код, а в памяти данных — старый добрый шитый код, как раньше.
Вот, как это будет устроено. Допустим, у нас есть слово высокого уровня COUNT:
: COUNT ↑ 1+ ↔ C@ ;
В таблице свёрток есть адрес обработчика этого слова, например ZCount. Через эту таблицу COUNT будет вызывать высокоуровневый код из области данных. Поэтому он будет обращаться к реализации Count в подпрограммном коде через преамбулу, КБП9 передаёт управление на NEXT:
ZCount: ПП Count КБП9
Count: ПП Dup 1 + ↔ БП Cat
Адрес Count используется для обращения к Count из подпрограммного кода в памяти программ. Такие же метки Dup и Cat используются для подпрограммной реализации примитивов ↑ и C@ например:
Cat: ПА ↔ КИПА В/О
Обращение к последнему слову C@ происходит через БП. Это обычная оптимизация более длинной и долгой фразы ПП Cat В/О. В теории даже от БП можно избавиться, размещая обработчики друг за другом. Простые обработчики слов 1+ и ↔ помещены прямо в код COUNT, в виде команд на языке МК-161.
Конечно же, для ↑ 1+ ↔ C@ существуют свои трёхшаговые «преамбулы» для вызова из шитого кода. Впрочем, адресный интерпретатор может при вызове обработчика сам делать КПП вместо КБП, самостоятельно делая NEXT после возврата. Над этим ещё подумаю, но в целом картина оптимистичная и существенно повышает быстродействие Каллисто.
Пока оптимизацию буду делать вручную, но сама возможность перехода на более быстрый и хорошо оптимизирующийся подпрограммный код, с сохранением исполнения шитого кода из области данных (основное требование гарвардской архитектуры 8051), обрадовал. Пользуясь случаем, поздравляю всех с 23 февраля.
Побольше вдохновляющих тем!