Forth http://fforum.winglion.ru/ |
|
обсуждение наброска стандарта http://fforum.winglion.ru/viewtopic.php?f=36&t=2242 |
Страница 3 из 5 |
Автор: | mOleg [ Вт авг 11, 2009 21:47 ] |
Заголовок сообщения: | |
то есть я считаю, что для начала нужно согласовать структуру документа, потом завести для каждого раздела документа отдельную тему и разделы обсуждать там, если, конечно, есть желающие серьезно заниматься данной задачей |
Автор: | Hishnik [ Вт авг 11, 2009 21:57 ] |
Заголовок сообщения: | |
mOleg писал(а): Вообще пока что в данном наброске главное структура, а заполнение пока больше очень схемотичное, главное чтобы было понятно где что должно находиться и что за чем следовать. Так с базовой модели форт-машины и надо начинать, в том числе и с определения ее назначения, требований и ограничений. Тогда будет и понятно, сложно реализовать предлагаемые слова или нет, надо минимизировать ядро, или нет. mOleg писал(а): есть желающие серьезно заниматься данной задачей
"Серьезно заниматься" - это внести элемент серьезности? |
Автор: | mOleg [ Вт авг 11, 2009 22:07 ] |
Заголовок сообщения: | |
Хищник писал(а): Так с базовой модели форт-машины и надо начинать, в том числе и с определения ее назначения, требований и ограничений. ваши предложения? кстати, назначение вобщем-то общее (то есть и большие машины, и микроконтроллеры и т.п.), впрочем можно, конечно, поступить как ANSI и зафиксировать только одну архитектуру с сопутствующей кучей несовместимостей и проблем. Хищник писал(а): "Серьезно заниматься" - это внести элемент серьезности?
серьезно, это не флудить, даже если хочется, а вносить свои предложения с обоснованиями их, вобщем помогать а не вредить;) |
Автор: | Hishnik [ Вт авг 11, 2009 22:24 ] |
Заголовок сообщения: | |
mOleg писал(а): кстати, назначение вобщем-то общее (то есть и большие машины, и микроконтроллеры и т.п.), впрочем можно, конечно, поступить как ANSI и зафиксировать только одну архитектуру с сопутствующей кучей несовместимостей и проблем. Тогда из этого вытекает целый ряд соображений: 1) Ориентация на совместимость (а не, скажем, производительность). 2) Запуск на 8-16-32 разрядных процессорах (при какой разрядности форт-системы?) 3) Фон-неймановская или гарвардская модель памяти (в том смысле, что работать должно на обоих, в том числе для гарвардской с read-only пространством кода, либо вписывать это в ограничения). 4) Набор периферии в общем-то не гарантируется. В частности, не гарантируется наличие таймера для организации переключения задач. 5) Если процессор - стековый, доступ к стеку может быть сильно ограничен. Так что PICK ROLL TUCK и прочие BLUP SHMYAK и PLUH подлежат самому тщательному рассмотрению. 6) Стек возвратов - операции минимизировать, а лучше вообще забыть. Никто не гарантирует, что разрядность адреса равна разрядности данных (для ряда МК это так, для FPGA желательно с целью экономии ресурсов). Так что >R R> легко может обрезать разряды, если число туда сброшено временно для доступа к нижележащим ячейкам. Это далеко не полный перечень соображений. mOleg писал(а): серьезно, это не флудить, даже если хочется, а вносить свои предложения с обоснованиями их, вобщем помогать а не вредить
"И все было хорошо, пока Хищник не стал задавать вопросы, рушащие прекрасный образ" |
Автор: | mOleg [ Вт авг 11, 2009 23:01 ] |
Заголовок сообщения: | |
Хищник писал(а): Тогда из этого вытекает целый ряд соображений: само собой Хищник писал(а): 1) Ориентация на совместимость (а не, скажем, производительность). не обязательно. Я бы даже посторался обойти проблемы оптимизации и быстродействия. А так, да совместимость на первом месте. Хищник писал(а): 2) Запуск на 8-16-32 разрядных процессорах (при какой разрядности форт-системы?) я бы выбрад другой диапазон разрядностей: 12-16-18-24-28-32 (и выше) меньше 12 бит разрядность для форт-процессора минимальна Хищник писал(а): 3) Фон-неймановская или гарвардская модель памяти (в том смысле, что работать должно на обоих, в том числе для гарвардской с read-only пространством кода, либо вписывать это в ограничения). да, соответственно, но это больше проблема кодогенерации, а это уже "второй" уровень языка по моей классификации, и там вариантов больше. Хищник писал(а): 4) Набор периферии в общем-то не гарантируется. В частности, не гарантируется наличие таймера для организации переключения задач. само собой, это все слабо связано с Форт-системой и может меняться сильно очень. Это опять же второй и третий уровни. Хищник писал(а): 5) Если процессор - стековый, доступ к стеку может быть сильно ограничен. Так что PICK ROLL TUCK и прочие BLUP SHMYAK и PLUH подлежат самому тщательному рассмотрению. да, тоже само собой должна быть эта проблема Хищник писал(а): 6) Стек возвратов - операции минимизировать, а лучше вообще забыть. Никто не гарантирует, что разрядность адреса равна разрядности данных (для ряда МК это так, для FPGA желательно с целью экономии ресурсов). Так что >R R> легко может обрезать разряды, если число туда сброшено временно для доступа к нижележащим ячейкам. не согласен. Проблема решаема, и решений несколько. Хищник писал(а): "И все было хорошо, пока Хищник не стал задавать вопросы, рушащие прекрасный образ"
пока что ничего такого Хищник не сказал, чтобы начался "рушиться прекрасный образ" |
Автор: | Hishnik [ Ср авг 12, 2009 12:35 ] |
Заголовок сообщения: | |
mOleg писал(а): не обязательно. Я бы даже посторался обойти проблемы оптимизации и быстродействия. А так, да совместимость на первом месте. Стараться - это декларация. А при возникновении ситуации "или-или" должен быть четкий критерий выбора одной из альтернатив (и всегда одной и той же). Иначе половина решений будет совместимой, а половина - быстродействующей, в результате получится ни то, ни се. mOleg писал(а): Хищник писал(а): 2) Запуск на 8-16-32 разрядных процессорах (при какой разрядности форт-системы?) я бы выбрад другой диапазон разрядностей: 12-16-18-24-28-32 (и выше) меньше 12 бит разрядность для форт-процессора минимальна 8, 16 и 32 массово выпускаются, и их надо либо учитывать, либо проигнорировать, о чем прямо и написать. Будет ли возможность работать с форт-процессорами нестандартной разрядности - станет понятно при реализации стандарта. mOleg писал(а): Хищник писал(а): 3) Фон-неймановская или гарвардская модель памяти (в том смысле, что работать должно на обоих, в том числе для гарвардской с read-only пространством кода, либо вписывать это в ограничения). да, соответственно, но это больше проблема кодогенерации, а это уже "второй" уровень языка по моей классификации, и там вариантов больше. Это может оказаться и проблемой ядра, в которое попадут обязательные для реализации слова, требующие read-write памяти кода (а система на МК может быть с флешем, программируемым только "снаружи" и большой неинициализированной DDR). mOleg писал(а): Хищник писал(а):
6) Стек возвратов - операции минимизировать, а лучше вообще забыть. Никто не гарантирует, что разрядность адреса равна разрядности данных (для ряда МК это так, для FPGA желательно с целью экономии ресурсов). Так что >R R> легко может обрезать разряды, если число туда сброшено временно для доступа к нижележащим ячейкам. не согласен. Проблема решаема, и решений несколько. Самое простое решение проблемы - не создавать ее на пустом месте. Если стек возвратов можно урезать с получением ощутимых преимуществ, будет большой соблазн его урезать. А если это не позволяет какой-то стандарт - тем хуже для стандарта. |
Автор: | вопрос [ Ср авг 12, 2009 13:16 ] |
Заголовок сообщения: | |
Цитата: Я бы даже посторался обойти проблемы оптимизации и быстродействия. В качестве возможного расширения лучше бы всё-таки предусмотреть (потом станет поятно, что не лишнее...)
|
Автор: | mOleg [ Ср авг 12, 2009 18:03 ] |
Заголовок сообщения: | |
Хищник писал(а): mOleg писал(а):не обязательно. Я бы даже посторался обойти проблемы оптимизации и быстродействия. А так, да совместимость на первом месте. Стараться - это декларация. А при возникновении ситуации "или-или" должен быть четкий критерий выбора одной из альтернатив (и всегда одной и той же). Иначе половина решений будет совместимой, а половина - быстродействующей, в результате получится ни то, ни се. Ну, скорее всего полностью от этой проблемы не уйти. И все же важнее совместимость, так как оптимизация скорости может достигаться различными методами. Я бы вернулся к этому вопросу после того, как будет создана "обобщенная модель" форт-процессора. Хищник писал(а): mOleg писал(а):Хищник писал(а): 2) Запуск на 8-16-32 разрядных процессорах (при какой разрядности форт-системы?) я бы выбрад другой диапазон разрядностей: 12-16-18-24-28-32 (и выше) меньше 12 бит разрядность для форт-процессора минимальна 8, 16 и 32 массово выпускаются, и их надо либо учитывать, либо проигнорировать, о чем прямо и написать. Будет ли возможность работать с форт-процессорами нестандартной разрядности - станет понятно при реализации стандарта. Ну, тут такие соображения у меня 1) форт-процессоры уже создавались под перечисленные разрядности, по крайней мере есть и 18 и 21 и 24 битные 2) меньше 12 бит разрядность адресов для Форта, не то, чтобы невозможна, скорее нецелесообразна (слишком мало памяти) 3) смотреть надо вперед, а реалии таковы, что 8 бит уходит даже в микроконтроллерах потихоньку в историю Так вот, с точки зрения стандарта, я уверен, не стоит вообще никак фиксировать разрядность данных\адресов, а лишь дать возможность их получать простыми методами в явном виде: слово CELL для этого уже есть, предлагаю добавить ADDR и UNIT Хищник писал(а): mOleg писал(а):Хищник писал(а): 3) Фон-неймановская или гарвардская модель памяти (в том смысле, что работать должно на обоих, в том числе для гарвардской с read-only пространством кода, либо вписывать это в ограничения). да, соответственно, но это больше проблема кодогенерации, а это уже "второй" уровень языка по моей классификации, и там вариантов больше. Это может оказаться и проблемой ядра, в которое попадут обязательные для реализации слова, требующие read-write памяти кода (а система на МК может быть с флешем, программируемым только "снаружи" и большой неинициализированной DDR). да, конечно. Эти вопросы должны быть таки зафиксированы на уровне ФМ и ФВМ и логично отнести к первому уровню языка. Но, именно кодогенерация - это второй. То есть одно дело модель работы и организация вычислительной среды, и совсем другое - кодогенерация. Хищник писал(а): mOleg писал(а):Хищник писал(а):
6) Стек возвратов - операции минимизировать, а лучше вообще забыть. Никто не гарантирует, что разрядность адреса равна разрядности данных (для ряда МК это так, для FPGA желательно с целью экономии ресурсов). Так что >R R> легко может обрезать разряды, если число туда сброшено временно для доступа к нижележащим ячейкам. не согласен. Проблема решаема, и решений несколько. Самое простое решение проблемы - не создавать ее на пустом месте. Если стек возвратов можно урезать с получением ощутимых преимуществ, будет большой соблазн его урезать. А если это не позволяет какой-то стандарт - тем хуже для стандарта. ну, вот, я могу сходу предложить два решения: 1) разрядность стеков должна быть = CELL, если адресное пространство меньше, старшие разряды в стеке возвратов игнорировать 2) ввести спец команды для пересылки данных между стеками, таким образом, чтобы адреса копировались с помощью A>R а данные >R, при этом данные могут на стеках занимать разное количество ячеек, к примеру, >R на стек возвратов может копировать два числа, а A>R 1 , а может быть и наоборот. Собственно, второе решение мне больше нравится |
Автор: | mOleg [ Ср авг 12, 2009 18:04 ] |
Заголовок сообщения: | |
вопрос писал(а): Я бы даже посторался обойти проблемы оптимизации и быстродействия.
В качестве возможного расширения лучше бы всё-таки предусмотреть (потом станет поятно, что не лишнее...) Кто там сказал?: "Сначала пусть заработает, оптимизируйте потом!" |
Автор: | вопрос [ Ср авг 12, 2009 19:29 ] |
Заголовок сообщения: | |
Цитата: Кто там сказал?: "Сначала пусть заработает, оптимизируйте потом!"
Не я , я такое не говорил - ну стандарт это не то, что работает, стандарт, это то, что _предусматривает_ ! В конце концов не реализацию же осуществить нужно, место для правил зарезервировать |
Автор: | mOleg [ Ср авг 12, 2009 22:42 ] |
Заголовок сообщения: | |
в тексте изменения. Добавлен рисунок Базовой модели Форт-Машины всвязи с появлением рисунка текст в указанном разделе явно надо переписывать. |
Автор: | mOleg [ Ср авг 19, 2009 01:37 ] |
Заголовок сообщения: | |
вынес обсуждение в отдельный топик, т.к. оригинальная тема разбита на множество сообщений в попытке создания гипертекстового документа |
Автор: | avl [ Ср авг 19, 2009 09:32 ] |
Заголовок сообщения: | |
mOleg писал(а): 2. для следующих моделей памяти:
- плоская - гарвардская - сегментная - индексная динамическая А давайте будем называть не "плоская", а логически точнее — "линейная" ... я-аа знаю, что так принято, но бывает "пара сапог" а бывает "пара кирпичей" ... |
Автор: | вопрос [ Ср авг 19, 2009 11:41 ] |
Заголовок сообщения: | |
Цитата: Освобождение ресурсов (например, откат DP в случае ошибок компиляции) Может быть, это называется "восстановление после ошибок?'
|
Автор: | garbler [ Ср авг 19, 2009 14:04 ] |
Заголовок сообщения: | |
вопрос писал(а): Цитата: Освобождение ресурсов (например, откат DP в случае ошибок компиляции) Может быть, это называется "восстановление после ошибок?'нет, т.к. в общем виде никаких ошибок может не быть, а для MARKER это вообще легитимное поведение |
Страница 3 из 5 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |