Forth
http://fforum.winglion.ru/

Хард-подход к стандарту на Форт
http://fforum.winglion.ru/viewtopic.php?f=36&t=1913		 Страница 1 из 7
Автор:  chess [ Сб янв 31, 2009 09:44 ]
Заголовок сообщения:  Хард-подход к стандарту на Форт
Слова ядра Форт-системы попросту будут именами инструкций Форт-процессора. Только этот процессор будем считать
не виртуальным, а реальным(тот который реально можно реализовать в кремнии). Сразу поэтому можно отбросить часть слов форт-системы, которые сейчас принято помещать в ядро(например MOVE). Они могут быть только последовательностью нескольких инструкций - в ядре таким словам не место.
Тут только надо определиться с набором инструкций этого форт-процессора - а начать, следовательно, с архитектуры этого форт-процессора(одноядерной). По идее более правильно перейти от фон-Неймановской архитектуры к Гарвардской,
либо вести два варианта одновременно.
Все остальные слова форт-системы подключать внешними библиотеками.
Автор:  VoidVolker [ Сб янв 31, 2009 11:56 ]
Заголовок сообщения: 
chess писал(а):
- а начать, следовательно, с архитектуры этого форт-процессора(одноядерной).

И обязательно с оглядкой на многоядерную и многопроецссорную архитектуру. И еще нужен межпроцессорный интерфейс.
Автор:  WingLion [ Сб янв 31, 2009 12:33 ]
Заголовок сообщения: 
chess писал(а):
Слова ядра Форт-системы попросту будут именами инструкций Форт-процессора.


Жаль, что с такой постановкой мало кто согласится, но я был бы за однозначно!

chess писал(а):
Сразу поэтому можно отбросить часть слов форт-системы, которые сейчас принято помещать в ядро(например MOVE).


Выкидывать MOVE из уже существующей реализации? - Это как-то неправильно все же.
Взгляните на старые процессоры.
Z80 - имеет команды LDIR и LDDR, которые фактически являются аналогами MOVE и <MOVE.
x86 имеет префикс REP: реализующий повтор для команд пересылки блоков данных и заполнения блоков.

И почему Форт-Процессор должен лишаться подобной удобной конструкции? Потому что "якобы сложно"?
Так ведь совсем не сложно же!


chess писал(а):
Тут только надо определиться с набором инструкций этого форт-процессора


С этим, как выясняется, есть "щукораколебедевая проблема".
Уже куча тем на форуме про "минимальные наборы" для форт-процессоров.

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


chess писал(а):
а начать, следовательно, с архитектуры этого форт-процессора(одноядерной).


VoidVolker писал(а):
И обязательно с оглядкой на многоядерную и многопроецссорную архитектуру. И еще нужен межпроцессорный интерфейс.


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

chess писал(а):
По идее более правильно перейти от фон-Неймановской архитектуры к Гарвардской,
либо вести два варианта одновременно.

Идеи бывают разные. Например, есть идея оставить разработчику свободу выбора, какую архитектуру использовать.
Какая из них (идей) правильная, а какая нет? - Я бы поостерегся давать категоричный ответ, хотя, для себя уже все решил.
Автор:  Alexander [ Сб янв 31, 2009 12:36 ]
Заголовок сообщения: 
Ремарка: Я думаю команды сложения тоже можно удалить ;) ведь есть исключающие или
Автор:  WingLion [ Сб янв 31, 2009 14:12 ]
Заголовок сообщения: 
Флуд из темы оторван, прошу высказываться более по теме...
Автор:  VoidVolker [ Сб янв 31, 2009 22:05 ]
Заголовок сообщения: 
WingLion писал(а):
Жаль, что с такой постановкой мало кто согласится

WingLion писал(а):
Если же копнуть еще глубже, то надо думать и про системы ввода/вывода, ибо без них и форт не форт,
и получится, что изначально надо целый форт-компьютер придумать.(Опять же, лично я не против, но за будет мало кто, так мне кажется.)

Я уже за! :)
Автор:  mOleg [ Сб янв 31, 2009 22:08 ]
Заголовок сообщения: 
WingLion писал(а):
chess писал(а):Слова ядра Форт-системы попросту будут именами инструкций Форт-процессора.
Жаль, что с такой постановкой мало кто согласится, но я был бы за однозначно!

почему же?
в моем видении это как раз "первый уровень языка" раздел: 5.1 - Базовый обязательный набор примитивов
но на этот уровень нет смысла выносить все возможные слова, реализуемые в коде, потому что можно скатиться к WORD в примитиве проца, и пр.
Автор:  WingLion [ Сб янв 31, 2009 22:16 ]
Заголовок сообщения: 
И сколько времени будем бодаться на тему, какой набор примитивов базовый и обязательный?

Я вот, уже "скатился" до MOVE и ничуть не жалею.

WingLion писал(а):
Тут, я думаю, проблему надо решать чуть по-другому. Надо зафиксировать набор слов чуть более высокого уровня, которые на этом процессоре надо реализовать, а дальше разработчик сам решит, какой набор команд процессора ему удобнее. Тот же MOVE тогда можно реализовывать и подпрограммно несколькими инструкциями, и одной командой форт-процессора, кому как хочется.
Автор:  Hishnik [ Сб янв 31, 2009 22:23 ]
Заголовок сообщения: 
WingLion писал(а):
И сколько времени будем бодаться на тему, какой набор примитивов базовый и обязательный?

А чего бодаться-то? Появился форт-процессор - вот и предмет для обсуждения. А то можно еще план заселения Марса пообсуждать... только на что это повлияет?
Автор:  WingLion [ Сб янв 31, 2009 22:33 ]
Заголовок сообщения: 
Так ведь появился-то он не один, и у каждого свои фичи, а их-то в стандарт вносить будет совсем неправильно.

И о совместимости разных реализаций форт-процессоров тоже можно помечтать, поплакать над погибшей мечтой и забыть.
Автор:  mOleg [ Сб янв 31, 2009 22:40 ]
Заголовок сообщения: 
WingLion писал(а):
Так ведь появился-то он не один, и у каждого свои фичи, а их-то в стандарт вносить будет совсем неправильно.
И о совместимости разных реализаций форт-процессоров тоже можно помечтать, поплакать над погибшей мечтой и забыть.

ну почему же?
есть общий набор, без которого обходиться сложно, его и надо стандартизировать!
тот же DUP например :)
Автор:  WingLion [ Сб янв 31, 2009 22:54 ]
Заголовок сообщения:  
0 - NOP
1 - LIT
2 - CALL
3 - RET 
4 - IF 
5 - DUP
 *DUP ( dd --> dd dd)
 *OVER ( dd1 dd2 --> dd1 dd2 dd1)
 *TRUE ( dd --> dd FFFF)
 *FALSE ( dd --> dd 0)
 *ONE ( dd --> dd 1)
6 - DROP
 *DROP ( dd2 dd1 --> dd2)
 *ADD ( dd2 dd1 --> dd2+dd1)
 *SUB ( dd2 dd1 --> dd2-dd1)
 *MUL ( dd2 dd1 --> dd2*dd1)
 *AND ( dd2 dd1 --> dd2 and dd1)
 *OR ( dd2 dd1 --> dd2 or dd1)
 *XOR ( dd2 dd1 --> dd2 xor dd1)
7 - SWAP
 *SWAP (dd2 dd1 --> dd1 dd2)
 *INC (dd2 dd1 --> dd2 dd1+1)
 *DEC (dd2 dd1 --> dd2 dd1-1)
 *NEG (dd2 dd1 --> dd2 -dd1)
8 - @
9 - !
10 - >R
11 - R>
12 - *MOVE


Знаю, что даже этого недостаточно, однако, если все, что со звездочками выкинуть, то и останется то, без чего не обойтись.
Автор:  WingLion [ Сб янв 31, 2009 23:02 ]
Заголовок сообщения: 
Предложение следующее.
1. Для начала, обозначаем все, "без чего не обойтись" при условии, что без этого никто не обойдется.
2. Затем обозначаем все, "без чего не обойтись" конкретным реализациям и фиксируем мнемоники, чтобы при появлении подобных операций в других реализациях они назывались бы одинаково, а не вразнобой.
3. Определяемся, без чего не обойтись собственно Форту и определяем это через слова из п.1
4. Если не удается, смотрим, что мешает или чего не хватает, корректируем, возвращаемся к п.1 пока не получится "NormalForth"
Автор:  mOleg [ Сб янв 31, 2009 23:08 ]
Заголовок сообщения: 
не все звездочки на мой взгляд правильно поставлены, по крайней мере: DUP OVER DROP ADD AND XOR OR SWAP
оставить нужно. А предлагаемый набор мною следующий:

DROP - удалить верхнее значение с вершины стека данных
DUP - поместить копию верхнего значения стека данных на вершину стека данных
SWAP - поменять местами два значения на вершине стека данных
OVER - положить копию второго значения, лежащего в стеке данных, на вершину стека данных

AR> - переместить адресную ссылку с вершины стека возвратов на вершину стека данных
A>R - переместить адресную ссылку с вершины стека данных на вершину стека возвратов

EXIT - снять верхнее значение с вершины стека данных и записать его в IP
CALL - текущее значение IP сохранить на вершину стека возвратов, совершить переход на адрес, сохраненный в коде за опкодом команды. Верхнее значение стека возвратов должно указывать после выполнения операции на адрес, следующий за адресной ссылкой перехода.

?BRANCH – перейти на адресную ссылку, находящуюся в коде за опкодом команды, в случае если значение на вершине стека данных отличается хоть в одном бите от нуля, иначе обойти адресную ссылку, и передать управление на код, находящийся за ней.

AND - произвести логическую операцию «и» над двумя числами, находящимися на вершине стека данных, результат операции вернуть туда же.
XOR - произвести логическую операцию «исключающее или» над двумя числами, находящимися на вершине стека данных, результат операции вернуть туда же.
OR - произвести логическую операцию «или» над двумя числами, находящимися на вершине стека данных, результат операции вернуть туда же.
ADD - произвести сложение двух чисел, находящихся на вершине стека данных, результат сложения оставить на вершине стека данных, в случае переполнения установить флаг переполнения
2/ - арифметический сдвиг числа, лежащего на вершине стека данных на один бит вправо

@ - или FETCH – извлечь значение из памяти по адресу, находящемуся на вершине стека данных, результат операции поместить на место адреса
! - или STORE – сохранить значение в память по указанному адресу. Адрес лежит на вершине стека данных, значение под ним, после совершения операции оба удаляются.
LIT - положить значение, лежащее в коде за LIT на вершину стека данных.
Автор:  Hishnik [ Сб янв 31, 2009 23:12 ]
Заголовок сообщения: 
mOleg писал(а):
?BRANCH – перейти на адресную ссылку, находящуюся в коде за опкодом команды, в случае если значение на вершине стека данных отличается хоть в одном бите от нуля, иначе обойти адресную ссылку, и передать управление на код, находящийся за ней.

Естественнее для железа делать переход, если на стеке 0. Тогда это IF. Арифметика неоднозначна - она ведь может выражаться через какие-то простые вещи, а то и вообще не требоваться. SWAP стоит отдельным пунктом в стековых манипуляциях, поскольку модифицирует две ячейки стека сразу.
Страница 1 из 7 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/