Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 03:44

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 11, 2009 21:47 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
то есть я считаю, что для начала нужно согласовать структуру документа, потом завести для каждого раздела документа отдельную тему и разделы обсуждать там, если, конечно, есть желающие серьезно заниматься данной задачей

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 11, 2009 21:57 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
mOleg писал(а):
Вообще пока что в данном наброске главное структура, а заполнение пока больше очень схемотичное, главное чтобы было понятно где что должно находиться и что за чем следовать.

Так с базовой модели форт-машины и надо начинать, в том числе и с определения ее назначения, требований и ограничений. Тогда будет и понятно, сложно реализовать предлагаемые слова или нет, надо минимизировать ядро, или нет.
mOleg писал(а):
есть желающие серьезно заниматься данной задачей

"Серьезно заниматься" - это внести элемент серьезности? :)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 11, 2009 22:07 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Хищник писал(а):
Так с базовой модели форт-машины и надо начинать, в том числе и с определения ее назначения, требований и ограничений.

ваши предложения?

кстати, назначение вобщем-то общее (то есть и большие машины, и микроконтроллеры и т.п.), впрочем можно, конечно, поступить как ANSI и зафиксировать только одну архитектуру с сопутствующей кучей несовместимостей и проблем.

Хищник писал(а):
"Серьезно заниматься" - это внести элемент серьезности?

серьезно, это не флудить, даже если хочется, а вносить свои предложения с обоснованиями их, вобщем помогать а не вредить;)

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 11, 2009 22:24 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
mOleg писал(а):
кстати, назначение вобщем-то общее (то есть и большие машины, и микроконтроллеры и т.п.), впрочем можно, конечно, поступить как ANSI и зафиксировать только одну архитектуру с сопутствующей кучей несовместимостей и проблем.

Тогда из этого вытекает целый ряд соображений:
1) Ориентация на совместимость (а не, скажем, производительность).
2) Запуск на 8-16-32 разрядных процессорах (при какой разрядности форт-системы?)
3) Фон-неймановская или гарвардская модель памяти (в том смысле, что работать должно на обоих, в том числе для гарвардской с read-only пространством кода, либо вписывать это в ограничения).
4) Набор периферии в общем-то не гарантируется. В частности, не гарантируется наличие таймера для организации переключения задач.
5) Если процессор - стековый, доступ к стеку может быть сильно ограничен. Так что PICK ROLL TUCK и прочие BLUP SHMYAK и PLUH подлежат самому тщательному рассмотрению.
6) Стек возвратов - операции минимизировать, а лучше вообще забыть. Никто не гарантирует, что разрядность адреса равна разрядности данных (для ряда МК это так, для FPGA желательно с целью экономии ресурсов). Так что >R R> легко может обрезать разряды, если число туда сброшено временно для доступа к нижележащим ячейкам.
Это далеко не полный перечень соображений.
mOleg писал(а):
серьезно, это не флудить, даже если хочется, а вносить свои предложения с обоснованиями их, вобщем помогать а не вредить

"И все было хорошо, пока Хищник не стал задавать вопросы, рушащие прекрасный образ" :))


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вт авг 11, 2009 23:01 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Хищник писал(а):
Тогда из этого вытекает целый ряд соображений:

само собой

Хищник писал(а):
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> легко может обрезать разряды, если число туда сброшено временно для доступа к нижележащим ячейкам.

не согласен. Проблема решаема, и решений несколько.

Хищник писал(а):
"И все было хорошо, пока Хищник не стал задавать вопросы, рушащие прекрасный образ"

пока что ничего такого Хищник не сказал, чтобы начался "рушиться прекрасный образ"

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 12, 2009 12:35 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
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 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Цитата:
Я бы даже посторался обойти проблемы оптимизации и быстродействия.
В качестве возможного расширения лучше бы всё-таки предусмотреть (потом станет поятно, что не лишнее...)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 12, 2009 18:03 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Хищник писал(а):
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 , а может быть и наоборот.

Собственно, второе решение мне больше нравится

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 12, 2009 18:04 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
вопрос писал(а):
Я бы даже посторался обойти проблемы оптимизации и быстродействия.
В качестве возможного расширения лучше бы всё-таки предусмотреть (потом станет поятно, что не лишнее...)

Кто там сказал?: "Сначала пусть заработает, оптимизируйте потом!"

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 12, 2009 19:29 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Цитата:
Кто там сказал?: "Сначала пусть заработает, оптимизируйте потом!"

Не я , я такое не говорил - ну стандарт это не то, что работает, стандарт, это то, что _предусматривает_ !
В конце концов не реализацию же осуществить нужно, место для правил зарезервировать


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 12, 2009 22:42 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
в тексте изменения. Добавлен рисунок Базовой модели Форт-Машины
всвязи с появлением рисунка текст в указанном разделе явно надо переписывать.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 19, 2009 01:37 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
вынес обсуждение в отдельный топик, т.к. оригинальная тема разбита на множество сообщений в попытке создания гипертекстового документа

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 19, 2009 09:32 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 18, 2006 08:55
Сообщения: 30
Откуда: Мелмак, Гидра Кентавра
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
mOleg писал(а):
2. для следующих моделей памяти:
- плоская
- гарвардская
- сегментная
- индексная динамическая


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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 19, 2009 11:41 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Цитата:
Освобождение ресурсов (например, откат DP в случае ошибок компиляции)
Может быть, это называется "восстановление после ошибок?'


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср авг 19, 2009 14:04 
Не в сети
Аватара пользователя

Зарегистрирован: Вт сен 11, 2007 11:07
Сообщения: 187
Благодарил (а): 0 раз.
Поблагодарили: 1 раз.
вопрос писал(а):
Цитата:
Освобождение ресурсов (например, откат DP в случае ошибок компиляции)
Может быть, это называется "восстановление после ошибок?'

нет, т.к. в общем виде никаких ошибок может не быть, а для MARKER это вообще легитимное поведение


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу Пред.  1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 12


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB