Forth :: Просмотр темы - обсуждение наброска стандарта

'1. Команды DROP SWAP DUP OVER AND XOR OR ADD 2/ LIT работающие с числами могут
не работать с адресными ссылками,

mOleg писал(а):'1. Команды DROP SWAP DUP OVER AND XOR OR ADD 2/ LIT работающие с числами могут
не работать с адресными ссылками,

нехорошо это однако...
а если надо переход по таблице устроить, а с адресом ни AND, ни ADD не работает?..

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

mOleg писал(а):

Так надо так и заявлять, что адреса, попадая на стек данных нулями(единицами) добиваются,
и после этого все операции работают, a в обратную сторону truncated... и все...

А заявление, что "могут не работать" - дико сбивает с толку...

интересно, можно ли пресмотреть в стандарте возможность отдельного стека для адресов - возни с его организацией, конечно, выше крыши, но зато возни с форматами меньше

Так надо так и заявлять, что адреса, попадая на стек данных нулями(единицами) добиваются,
и после этого все операции работают, a в обратную сторону truncated... и все...

Всего 17 команд.
?????? что пропустил ?????

А в каком наборе будет INTERPRET или EVALUATE?

Majestio писал(а):

Если рассматривать создание Форт-среды по данному стандарту

Т.е. минимальный набор именно эти 17 определений, однако, набор хотя и достаточный, но не слишком удобный, т.е. на низком уровне стандартно должно быть реализовано около 100 определений.
Причем, все они достаточно просты в реализации.
.

И еще попутно вопрос... Если рассматривать создание Форт-среды по данному стандарту с нуля, не с Форта 3.х. Какую часть стандарта придется писать в машиных командах (или на другом языке, с последующей компиляцией), а какую уже можно будет продолжать на самом Форте? И будет ли впоследствии замена предыдущего кода (написанного на машинном языке) кодом на Форте? Если "да", то до какого предела?

Автор:	WingLion [ Чт дек 17, 2009 22:11 ]
Заголовок сообщения:	обсуждение наброска стандарта
обсуждение наброска стандарта вынесено в отдельную тему mOleg писал(а): '1. Команды DROP SWAP DUP OVER AND XOR OR ADD 2/ LIT работающие с числами могут не работать с адресными ссылками, нехорошо это однако... а если надо переход по таблице устроить, а с адресом ни AND, ни ADD не работает?..

Автор:	mOleg [ Чт дек 17, 2009 22:20 ]
Заголовок сообщения:
WingLion писал(а): mOleg писал(а):'1. Команды DROP SWAP DUP OVER AND XOR OR ADD 2/ LIT работающие с числами могут не работать с адресными ссылками, нехорошо это однако... а если надо переход по таблице устроить, а с адресом ни AND, ни ADD не работает?.. почему же? проблемы возникают только в случае, если адреса больше разрядности данных. если адрес двойной(и более) длины, а младшая часть адреса лежит сверху, то можно и ADD и AND (это как страничная адресация, получится).

Автор:	WingLion [ Чт дек 17, 2009 22:25 ]
Заголовок сообщения:
mOleg писал(а): почему же? проблемы возникают только в случае, если адреса больше разрядности данных. если адрес двойной(и более) длины, а младшая часть адреса лежит сверху, то можно и ADD и AND (это как страничная адресация, получится). Так надо так и заявлять, что адреса, попадая на стек данных нулями(единицами) добиваются, и после этого все операции работают, a в обратную сторону truncated... и все... А заявление, что "могут не работать" - дико сбивает с толку...

Автор:	вопрос [ Чт дек 17, 2009 22:49 ]
Заголовок сообщения:
WingLion писал(а): mOleg писал(а): почему же? проблемы возникают только в случае, если адреса больше разрядности данных. если адрес двойной(и более) длины, а младшая часть адреса лежит сверху, то можно и ADD и AND (это как страничная адресация, получится). Так надо так и заявлять, что адреса, попадая на стек данных нулями(единицами) добиваются, и после этого все операции работают, a в обратную сторону truncated... и все... А заявление, что "могут не работать" - дико сбивает с толку... интересно, можно ли пресмотреть в стандарте возможность отдельного стека для адресов - возни с его организацией, конечно, выше крыши, но зато возни с форматами меньше

Автор:	mOleg [ Чт дек 17, 2009 22:55 ]
Заголовок сообщения:
вопрос писал(а): интересно, можно ли пресмотреть в стандарте возможность отдельного стека для адресов - возни с его организацией, конечно, выше крыши, но зато возни с форматами меньше вообще насчет стека адресов идея интересная, НО, это уже не Форт, и придется прорабатывать новый сбалансированный набор команд. Короче, в стандарте этому стеку не место - надо сначала написать систему, у которой был бы такой адресный стек, написать кучу кода, чтобы понять, стоит ли овчинка выделки и т.д. Не забывай, что обычно регистров в процессорах не хватает или хватает впритык для организации двух стеков...

Forth http://fforum.winglion.ru/

обсуждение наброска стандарта http://fforum.winglion.ru/viewtopic.php?f=36&t=2943	Страница 1 из 6

Автор:	mOleg [ Чт дек 17, 2009 22:58 ]
Заголовок сообщения:
WingLion писал(а): Так надо так и заявлять, что адреса, попадая на стек данных нулями(единицами) добиваются, и после этого все операции работают, a в обратную сторону truncated... и все... вобщем да, но по сути эти моменты должны быть описаны где-то в параграфе 3 или 4 что касалось "могут не работать" то имелось ввиду, что работать не так, а не вообще не работать.

Автор:	WingLion [ Пт дек 18, 2009 07:32 ]
Заголовок сообщения:
вопрос писал(а): интересно, можно ли пресмотреть в стандарте возможность отдельного стека для адресов - возни с его организацией, конечно, выше крыши, но зато возни с форматами меньше в стандарте имеет смысл предусмотреть возможность иметь несколько дополнительных стеков, механизмы обмена между стеками, операции на стеках и т.п. и т.д. варианты: float-point стек - де-факто уже есть в x86 системах. стек для организации циклов - встречается. Но это, имхо, стоит делать в виде расширения к стандарту, а не валить все в одно место.

Автор:	mOleg [ Вт янв 05, 2010 12:07 ]
Заголовок сообщения:
добавление в 5. Первый уровень языка - ФВМ

Автор:	Majestio [ Вс май 26, 2013 18:00 ]
Заголовок сообщения:	Re:
mOleg писал(а): Всего 17 команд. ?????? что пропустил ????? А в каком наборе будет INTERPRET или EVALUATE?

Автор:	mOleg [ Вс май 26, 2013 18:20 ]
Заголовок сообщения:	Re: набросок стандарта от mOleg
Majestio писал(а): А в каком наборе будет INTERPRET или EVALUATE? только "должно быть", тут. А так второй

Автор:	Majestio [ Вс май 26, 2013 18:23 ]
Заголовок сообщения:	Re: набросок стандарта от mOleg
Ок. Понял.

Автор:	Majestio [ Вс май 26, 2013 18:31 ]
Заголовок сообщения:	Re: набросок стандарта от mOleg
И еще попутно вопрос... Если рассматривать создание Форт-среды по данному стандарту с нуля, не с Форта 3.х. Какую часть стандарта придется писать в машиных командах (или на другом языке, с последующей компиляцией), а какую уже можно будет продолжать на самом Форте? И будет ли впоследствии замена предыдущего кода (написанного на машинном языке) кодом на Форте? Если "да", то до какого предела?

Автор:	Hishnik [ Вс май 26, 2013 18:44 ]
Заголовок сообщения:	Re: набросок стандарта от mOleg
Если речь идет о создании компилятора в машинный код, фрагменты этого кода для разных платформ должны быть в наличии. Чем существеннее различия в архитектурах процессора, тем больше соблазна разделить эту разработку на несколько независимых. Форт, по сути, может представлять собой набор независимых реализаций для каждой из интересующих целевых платформ, которые бинарной совместимостью и не обладают. Специализация и универсальность, как обычно, почти полностью противоположны.

Автор:	KPG [ Вс май 26, 2013 20:08 ]
Заголовок сообщения:	Re: набросок стандарта от mOleg
mOleg писал(а): Majestio писал(а): Если рассматривать создание Форт-среды по данному стандарту Т.е. минимальный набор именно эти 17 определений, однако, набор хотя и достаточный, но не слишком удобный, т.е. на низком уровне стандартно должно быть реализовано около 100 определений. Причем, все они достаточно просты в реализации. . Если при раскрутке Форт системы используется, в той или иной степени, техника оптимизации определений под целевую архитектуру, то и эти следующие "простые" определения не обязательно реализовывать на ассемблере. Особенно это может касаться определений, которые, например, проводят процесс компиляции и в непосредственной дальнейшей работе результирующего кода не задействованы при этом. Их может оказаться выгодным, в целях уменьшения размера кода, вообще не подвергать оптимизации для целевого CPU во встроенной Форт системе. Реализации Форт слов, в разных Форт системах, бывает сильно отличаются и характеризуется принятыми проектными решениями и ограничениями целевого CPU. P.S. В SPF4, например, встроен макро-оптимизатор и код многих Форт слов, при самосборке, вполне адекватен предполагаемому результату. Можно посмотреть и сравнить что получается на выходе и при желании доработать макрооптимизатор.

Страница 1 из 6	Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/

Автор:	in4 [ Вс май 26, 2013 20:19 ]
Заголовок сообщения:	Re: набросок стандарта от mOleg
Majestio писал(а): И еще попутно вопрос... Если рассматривать создание Форт-среды по данному стандарту с нуля, не с Форта 3.х. Какую часть стандарта придется писать в машиных командах (или на другом языке, с последующей компиляцией), а какую уже можно будет продолжать на самом Форте? И будет ли впоследствии замена предыдущего кода (написанного на машинном языке) кодом на Форте? Если "да", то до какого предела? Минимум - 3 команды ... Если есть запись в память и возможность из нее выполнять код. У меня для раскрутки пришлось сделать меньше десятка команд и несколько переменных. Потом компилятор Forth-на-Forth-е (ну, на самом деле colorForth), который работает одновременно с интерпретатором. Когда в 64Кб откомпилировалась третья система, стало неудобно отлаживать... Пошел искать инструменты получше. До сих пор ищу... Периодически, правда, порываюсь сам сделать...