о недостатках байткод ФВМ

mOleg

для начала рассмотрим, как выглядит код команды next трех типов ФВМ:

Код:

прямой шитый код:

  CODE NEXT
             MOV temp, [IP]
             LEA IP, CELL [IP]
             MOV addr, [temp]
             JMP addr 
   END-CODE

кому не ясно:
IP - указатель на текущую команду,
temp - просто временная переменная
addr - указатель на начало определения которое должно быть выполнено

Код:

 
косвенный шитый код:
  CODE NEXT
             MOV temp, [IP]
             LEA  IP, CELL [IP]
             MOV addr. [temp]
             JMP [addr]
  END-CODE

на одну операцию чтения из памяти вроде как больше получается, на самом деле вроде как, потому что для высокоуровневых определений прямой шитый код всеравно эту операцию выполняет

Код:

 
ну и байткод:
  CODE NEXT
             MOV btemp,  [IP]
             INC IP
             MOV addr, [btemp*4+btable]
             JMP [addr]
   END-CODE

где btemp - переменная байтовой ширины так что скорее MOVZX, а btable адрес таблицы адресов

таким образом на первый взгляд байткодовая ФВМ ни чем не отличается от ФВМ с косвенным шитым кодом ( если я не прав - поправьте )

mOleg

Смотрим дальше, код команды CALL и EXIT для косвенного шитого кода будет выглядеть так:

Код:

  CODE CALL
             RPUSH IP
             MOV IP, addr+cfl
            NEXT
   END-CODE

  CODE EXIT
             RPOP IP
            NEXT
   END-CODE

для байткод ФВМ:

Код:

   CODE CALL
              MOV addr, [IP]
              LEA IP, CELL [IP]
              RPUSH IP
              MOV IP, addr
            NEXT
   END-CODE

   CODE EXIT 
               RPOP IP
              NEXT
    END-CODE

обратите внимание на тот факт, что вызов уже занимает не CELL байт а CELL+1

опять же поправьте меня, если я ошибся.

Mihail

Некоторая поправка:

Код:

прямой шитый код:

  CODE NEXT
             MOV temp, [IP]
             LEA IP, CELL [IP]
             JMP [temp]
   END-CODE

oleg писал(а):

Смотрим дальше, код команды CALL и EXIT для косвенного шитого кода будет выглядеть так:

Код:

  CODE CALL
             RPUSH IP
             MOV IP, addr+cfl
            NEXT
   END-CODE

Это не команда CALL , а команда NEST. Это не каманда вызава подпрограммы,
а содержимое CFA вызываемой.

oleg писал(а):

для байткод ФВМ:

Код:

   CODE CALL
              MOV addr, [IP]
              LEA IP, CELL [IP]
              RPUSH IP
              MOV IP, addr
            NEXT
   END-CODE

Это уже именно CALL , а NEST не нужен, как в подпрограммном шитом коде.
Тут возникает вопрос: чем он лучше подпрограммного?

Мне нравится реализация ВФМ в http://devbiol.zoo.uwo.ca/~kvt/relf01.zip
там команда CALL обозначается младшим битом шитого кода, при этом
адреса шитого кода выровнены до четности.

mOleg

Mihail писал(а):

Некоторая поправка:
Код:

прямой шитый код:

Код:

  CODE NEXT
             MOV temp, [IP]
             LEA IP, CELL [IP]
             JMP [temp]
   END-CODE

правка не совсем верна, дело в том, что addr используется как CALL так и CREATE DOES> словами.
либо же в начале слова для таких слов должен стоять ассемблерная команда CALL, что может несколько затормозить систему.

Mihail писал(а):

Это не команда CALL , а команда NEST. Это не команда вызова подпрограммы,
а содержимое CFA вызываемой.

Именно! но это и есть (call) - то есть сохранение адреса возврата и установка нового ip.

Mihail писал(а):

Это уже именно CALL , а NEST не нужен, как в подпрограммном шитом коде.
Тут возникает вопрос: чем он лучше подпрограммного?

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

По моему мнению реализовывать байт-код ФВМ стоит реализовывать лишь для эмуляции форт-процессора с подобной организацией.

С точки же зрения оптимального интерпретатора, мне кажется более выгодно стелать таблицу не на 256 вхождений, а на 65536, по крайней мере для больших машин, или использовать косвенный шитый код для маленьких машин.

У байт-код систем большие накладные расходы на вызов высокоуровневых слов.
У word-код системы будут меньшие накладные расходы и по времени исполнения, и по размеру кода. Да и интерпретатор будет чуточку проще.

к тому же такой подход позволяет изолировать код, лежащий в основе ФВМ от адресного пространства, доступного интерпретатору.

Воот

Hishnik

Я уж просто по итогам irc допишу, что проблема - малое число доступных команд, а не сам принцип кодирования адреса в некоторое таблице. В этом случае и байт-код, и ворд-код, и даже дубльворд-код (а хоть бы и 9- или 18-битный код) будут реализовываться примерно одинаково.

mOleg

Хищник писал(а):

Я уж просто по итогам irc допишу, что проблема - малое число доступных команд, а не сам принцип кодирования адреса в некоторое таблице. В этом случае и байт-код, и ворд-код, и даже дубльворд-код (а хоть бы и 9- или 18-битный код) будут реализовываться примерно одинаково.

Именно так!
принцип, однако же интересен тем( особенно для больших таблиц) что слова могут быть представлены своим номером в таблице, а не реальным адресом( в этом плане даже лучше, чем с косвенным шитым кодом получается) и код
1)без изменений может быть портирован на другие платформы
2) может быть сохранен а потом загружен, и при этом не нужны никакие изменения
3) можно достаточно просто менять те или иные функции, не меняя кода

то есть мне не нравится не сам принцып, а слишком маленькая таблица.

WingLion

Если вспомнить префиксы, то в байт-коде префикс - это временное переключение таблицы, и проблема малости количества кодов частично решается... Можно даже префикс перехода с байткода на ворд-код сделать

mOleg

WingLion писал(а):

Если вспомнить префиксы, то в байт-коде префикс - это временное переключение таблицы, и проблема малости количества кодов частично решается... Можно даже префикс перехода с байткода на ворд-код сделать

но при этом будут дополнительные тормоза. к тому же опять же усложнение получится

Hishnik

mOleg писал(а):

но при этом будут дополнительные тормоза. к тому же опять же усложнение получится

Если развлекаться, то по полной

Ну и тормоза, ну и что? Они и так будут с лазанием в память. Байт-код можно попытаться применить, если есть желание ужать программу так, чтобы из нее пошли все соки

Тут уж производительность будет так, с любопытным выражением мордочки выглядывать из-за спины...

mOleg

Хищник писал(а):

Если развлекаться, то по полной Ну и тормоза, ну и что? Они и так будут с лазанием в память. Байт-код можно попытаться применить, если есть желание ужать программу так, чтобы из нее пошли все соки Тут уж производительность будет так, с любопытным выражением мордочки выглядывать из-за спины...

Не, ну конечно, если так, то пожалуйста!

Мне все же кажется, что все должно быть не в ущерб остальному

добро зловеще завывая... Гм

Kopa

Похоже близко к обсуждаемой теме.

Low Level Virtual Machine (LLVM) is:

A compilation strategy designed to enable effective program optimization across the entire lifetime of a program. LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time and offline (i.e., after software is installed), while remaining transparent to developers and maintaining compatibility with existing build scripts.

A virtual instruction set - LLVM is a low-level object code representation that uses simple RISC-like instructions, but provides rich, language-independent, type information and dataflow (SSA) information about operands. This combination enables sophisticated transformations on object code, while remaining light-weight enough to be attached to the executable. This combination is key to allowing link-time, run-time, and offline transformations

http://llvm.org/

P.S. Куда поместить данную ссылку не придумал.

chess

О байт-коде.
Давно осмысленное понятие.
Например, у классиков(Баранов С.Н., Ноздрунов Н.Р.) эта разновидность шитого кода называется свернутым шитым кодом.
Этот код может быть как прямым, так и косвенным, отличается тем, что вместо прямых адресов подпрограмм и кодов в нем используются их свертки, которые вообще говоря короче этих адресов. За счет усложнения доступа
к подпрограммам в действии NEXT(через использование таблицы сверток или спецфункции, преобразующей свертку в соответствующий адрес) можно добиться экономии памяти или возможности использовать больший диапазон адресов для размещения кода.
От себя могу добавить, что пытался загнать форт-примитивы в байт-код(для сжатия объема выходного кода), но по ходу дела выяснил, что реализация слов для структур управления( IF, ELSE, THEN и других со ссылками вперед) выпадает из общего ряда, а также то, что использование байт-кода снижает быстродействие конечного кода бросил этим заниматься. В конечном итоге сейчас выходной код представляет набор чистых подпрограмм и код главного слова со ссылками на адреса подпрограмм, а структуры управления реализованы оптимизированными по быстродействию и объему как линейные вставки кода, как внутри подпрограмм, так и внутри кода главного слова.

mOleg

chess писал(а):

От себя могу добавить, что пытался загнать форт-примитивы в байт-код(для сжатия объема выходного кода), но по ходу дела выяснил, что реализация слов для структур управления( IF, ELSE, THEN и других со ссылками вперед) выпадает из общего ряда, а также то, что использование байт-кода снижает быстродействие конечного кода бросил этим заниматься. В конечном итоге сейчас выходной код представляет набор чистых подпрограмм и код главного слова со ссылками на адреса подпрограмм, а структуры управления реализованы оптимизированными по быстродействию и объему как линейные вставки кода, как внутри подпрограмм, так и внутри кода главного слова.

Это то, о чем я и говорил.
Но в плане скорости быстродействие можно повысить, если адреса переходов будут представляться своими смещениями, а таблица адресов будет рассчитана на 65536 вхождений. Эта схема не будет работать быстрее, чем схема с косвенным шитым кодом, но будет копактнее, а так же проще.
Единственное неудобство заключается в том, что слова @ ! будут получать адреса в виде
смещение имя ( раньше были варианты с смещение + сегмент ) то есть поглащать не два параметра а три.

KPG

Какое то обсуждение
Формат байт-кода. Наиболее быстрые реализации интерпретаторов байт-кода.

P.S. По обсуждению пока не сделал никаких выводов т.к. возможно необходимо соответствующее осмысление и проработка каких то вариантов и теоретических
аспектов, но ссылку на всякий случай приведу для оценки полезности обсуждения и тема интересная.

о недостатках байткод ФВМ

Кто сейчас на конференции