Новая версия ядра kf вырисовывается настолько интересной, что и в сам Форт (для PC) может внести некоторые изменения. Прежде всего, с 8-битной командой вместо 6-битной вместо 32 "не-литеральных" команд образуется 128. Это дает возможность не ужиматься в пределах только самого необходимого. Что получается из назревших команд: 1. Произвольный доступ к стеку данных, как по абсолютным адресам, так и по смещениям относительно вершины стекового кадра. Это шаг в сторону кода, генерируемого "классическими" компиляторами. Нужны параметры на стеке данных, образующие стековый кадр. В Форте он может быть эмулирован массивом, доступ к которому все равно пойдет по ! @, что заставляет тратить дополнительные такты на эмуляцию "стека, но не такого". При необходимости прочитать произвольное число можно использовать PICK, но как быть с необходимостью его записать туда? В ядре Форта такого слова за историю его развития не появилось. Второй момент - это независимая от программиста поддержка адресации. Например, если на стеке было 5 чисел, а подпрограмма создала локальные переменные x, y, z, то они расположатся в ячейках 5, 6, 7 (считая, что заняты ячейки 0 - 4). Теперь, если при вызове такой подпрограммы запомнить на отдельном стеке 5 (т.е. глубину на момент вызова), то у нас получаются автоматически рассчитываемые адреса FRAME+0, FRAME+1, FRAME+2, которые и будут соответствовать локальным переменным. Стековая нотация видится как ( Data, Offset -- ) и ( Offset -- Data ), наподобие ! @, тут нечего особенно изобретать. Для PC-версии непонятно (хотя почему бы нет?), а для embedded вполне благотворно повлияет на производительность. Раз есть стековый кадр, его необходимо удалять, для этого нужна версия команды RET.
2. Манипуляции с координатами пикселов и цветовыми компонентами. Это для графики. Автоинкремент X, Y, получение кода цвета ( R, G, B -- Color ). Сложно сказать, как здесь лучше организовать. Наложение компонентов - либо принудительно в заданные места, либо с помощью быстрого сдвига на 8/16/24 разрядов.
3. DDR. Два момента. Ее много. И она есть в прямом управлении форт-процессора (whiteTigr - просто монстр, проделал работу высшей категории сложности!). И поскольку это память другого типа, со своими особенностями, ее не стоит просто бесконтрольно кэшировать, как в PC. Тут, опять же, много вариантов, можно просто подключить контроллер в пространство ВВ (а память - в существующее адресное пространство), можно по запросу подгружать динамическую память в блочную статику ПЛИС ("ручной" кэш), можно, наконец, выделить еще одно адресное пространство со своими ! @.
4. В принципе, в системе команд стоит оставить место для плавающей точки. В embedded это не всегда требуется, да и честная реализация на IP-ядрах занимает многовато места. Но почему нет?
|