Вон Михаил свой оптимизатор таки забросил.

особой разницы нет, придется с собой таскать еще один компилятор. это огромный минус.

Ну и тогда уж, до кучи. Вот мы сейчас смотрим на LLVM с целью написания back-endа для процессорного ядра QuarkR.

Изначально в Каллисто-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 после возврата. Над этим ещё подумаю, но в целом картина оптимистичная и существенно повышает быстродействие Каллисто.