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 Знаю, что даже этого недостаточно, однако, если все, что со звездочками выкинуть, то и останется то, без чего не обойтись. |
Автор: | 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/ |