Forth http://fforum.winglion.ru/ |
|
обсуждение наброска стандарта http://fforum.winglion.ru/viewtopic.php?f=36&t=2943 |
Страница 1 из 6 |
Автор: | 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 ] |
Заголовок сообщения: | |
вопрос писал(а): интересно, можно ли пресмотреть в стандарте возможность отдельного стека для адресов - возни с его организацией, конечно, выше крыши, но зато возни с форматами меньше
вообще насчет стека адресов идея интересная, НО, это уже не Форт, и придется прорабатывать новый сбалансированный набор команд. Короче, в стандарте этому стеку не место - надо сначала написать систему, у которой был бы такой адресный стек, написать кучу кода, чтобы понять, стоит ли овчинка выделки и т.д. Не забывай, что обычно регистров в процессорах не хватает или хватает впритык для организации двух стеков... |
Автор: | 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, например, встроен макро-оптимизатор и код многих Форт слов, при самосборке, вполне адекватен предполагаемому результату. Можно посмотреть и сравнить что получается на выходе и при желании доработать макрооптимизатор. |
Автор: | in4 [ Вс май 26, 2013 20:19 ] |
Заголовок сообщения: | Re: набросок стандарта от mOleg |
Majestio писал(а): И еще попутно вопрос... Если рассматривать создание Форт-среды по данному стандарту с нуля, не с Форта 3.х. Какую часть стандарта придется писать в машиных командах (или на другом языке, с последующей компиляцией), а какую уже можно будет продолжать на самом Форте? И будет ли впоследствии замена предыдущего кода (написанного на машинном языке) кодом на Форте? Если "да", то до какого предела? Минимум - 3 команды ... Если есть запись в память и возможность из нее выполнять код.У меня для раскрутки пришлось сделать меньше десятка команд и несколько переменных. Потом компилятор Forth-на-Forth-е (ну, на самом деле colorForth), который работает одновременно с интерпретатором. Когда в 64Кб откомпилировалась третья система, стало неудобно отлаживать... Пошел искать инструменты получше. До сих пор ищу... Периодически, правда, порываюсь сам сделать... |
Страница 1 из 6 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |