Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт мар 19, 2024 12:38

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 159 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8, 9, 10, 11  След.
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Сб янв 09, 2010 16:28 
Не в сети

Зарегистрирован: Пн окт 15, 2007 17:24
Сообщения: 164
Откуда: Бийск
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
mOleg писал(а):
данные, да не всегда, но все же это другой тип.

да, это всего лишь один из многих типов ДАННЫХ

mOleg писал(а):
Например, диапазон адресов может существенно отличаться от диапазона чисел, как количественно, так и качественно.
...
тем не менее адресная арифметика другая, например, адреса не имеет смысла умножать или делить друг на друга.
...
Операции над данными и адресами могут сильно отличаться, например, переполнение в АЛУ данных имеет смысл один, а в адресном - другой.
...
Не все операции имеют смысл по отношению к адресам,

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

mOleg писал(а):
уже даже операция вычитания адресов смысла не имеет особенного (нет, понятно, что так можно узнать сколько между адресами ячеек находоится, но в результат уже не будет адресом!

Вот-вот, оказывается, что аргументы операции могут быть данными одного типа, а результат - другого. Да и аргументы, вообще говоря, тоже могут принадлежать разным типам данных. Как тогда поступать с ними? Что где хранить?

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

_________________
And so forth ...


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

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


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

Зарегистрирован: Пн окт 15, 2007 17:24
Сообщения: 164
Откуда: Бийск
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
вопрос писал(а):
не так уж много, ведь такого же плана проблемы решены в типизированных или строго типизированных языках :?

подозреваю, что они довольно естественно решаются там, где не ВМ не основана на 0-операндной системе команд

_________________
And so forth ...


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

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

но это один из базовых типов, которых, собственно только два.

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

ну, давай думать, сколько в форте стеков:
1) стек возвратов
2) стек данных
3) стек словарей
4) стек для чисел с плавающей точкой
иногда добавляются:
5) локальный стек (аналогичный стеку данных)
6) стек параметров (для хранения счетчиков циклов и подобных вещей)
7) C-STACK для управления компиляцией
и т.д.
Замечу, что речь не обо мне.

Варнак писал(а):
mOleg писал(а): уже даже операция вычитания адресов смысла не имеет особенного (нет, понятно, что так можно узнать сколько между адресами ячеек находоится, но в результат уже не будет адресом!

Вот-вот, оказывается, что аргументы операции могут быть данными одного типа, а результат - другого. Да и аргументы, вообще говоря, тоже могут принадлежать разным типам данных. Как тогда поступать с ними? Что где хранить?

ну, в данном конкретном случае результат вычитания должен быть помещен на стек данных.

Варнак писал(а):
Т.е., даже независимо от эффективности и удобства для программиста, возникает много методологических проблем при попытке выделить отдельные стеки для данных различных типов и пока они не решены, я не стал бы браться за такое разделение.

Судя по всему, основные пока возникшие проблемы носят психологический характер.
За разделение я и не берусь пока, а обсуждаю (это Хищник спешит все воплотить).
Я же пока пользуюсь советом Броуди: "воздерживайтесь от кодирования столько времени, сколько сможете" 8)

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


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

Зарегистрирован: Пн окт 15, 2007 17:24
Сообщения: 164
Откуда: Бийск
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
mOleg писал(а):
ну, давай думать, сколько в форте стеков:
1) стек возвратов
2) стек данных
3) стек словарей
4) стек для чисел с плавающей точкой
иногда добавляются:
5) локальный стек (аналогичный стеку данных)
6) стек параметров (для хранения счетчиков циклов и подобных вещей)
7) C-STACK для управления компиляцией

первые три существенны для форта, остальное - от лукавого

_________________
And so forth ...


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

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

Да нет, не от лукавого. Это практика.

А вообще, тут надо думать в другом ключе.
Надо смотреть на то, как часто используются данные какого типа, и как часто над ними производятся действия, соответственно какие действия.
В отношении адресов, наиболее частые операции:
1) использование адреса для чтения данных
2) использование адреса для записи данных
3) перенос\копирование\заполнение (цепочечные, которые могут быть выражены через первые два действия)
4) увеличение\уменьшение рабочего адреса
5) индексация массивов (т.е. есть индекс и базовый адрес - находитса адрес записи для указанног индекса)
6) определение расстояния между адресами
???

Частота операций обращений к памяти при кешировании данных в стеке снижается. То есть количество операций обращения к памяти меньше количества операций преобразования данных.

Кроме того, операции на разных стеках могут производиться параллельно! то есть место для ускорения.

Появляется возможность контроля адресов (особенно, если не делать операций >A A> можно сделать исключение "недействительный адрес", которое будет возникать как только этот неверный адрес попадет на стек адресов. Понятно, что скорее всего останется обходной путь через стек возвратов: >R R>A но это уже "трюковой код" и он будет достаточно редким.

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


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

Зарегистрирован: Пн окт 15, 2007 17:24
Сообщения: 164
Откуда: Бийск
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
mOleg писал(а):
ну, в данном конкретном случае результат вычитания должен быть помещен на стек данных.

а результат операции сравнения двух чисел - на стек логических значений? :)

_________________
And so forth ...


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

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

;)
ну, это лишнее. Ведь этот результат используется сразу и становится очень быстро недействительным, хотя регистр под это дело обычно выделяется отдельный.

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


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

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


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

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

кстати, размышляя подобным образом можно вренуться к одному стеку, ну зачем выделять отдельный стек данных?
А вот нет же, оказывается, что имеется выигрыш от разделения потока данных от потока управления!
Хотя и не всем нравится ;)

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


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

Зарегистрирован: Пт дек 26, 2008 21:16
Сообщения: 412
Откуда: Великий Новгород
Благодарил (а): 9 раз.
Поблагодарили: 4 раз.
Хищник писал(а):
Для этого существует понятие "абстрагирование от аппаратуры". 16-разрядные системы переживают интересный период - они не настолько малы и компактны, как 8-разрядные, и не настолько производительны, чтобы догонять 32 разряда. Да и диапазон представления данных в 64К это маловато. Поэтому даже на MSP430 проще сделать 32-разрядную систему, которая скроет детали обработки длинных адресов.

Кроме первого предложения хочется оспорить все :D
У меня как раз складывается мнение что 8-разрядные системы скоро сильно сдадут свои исконные позиции 16-разрядным так как цены и экономичность ( в смысле питания) практически сравнялись.
Да действительно 32-разрядную систему использовать будет проще, но ресурсу она скушает на 16-разрядном ядре гораздо больше.
Мало того ведь самые дешёвые представители MSP430 длинные команды не поддерживают.
Вобщем идея отдельного стека для адресов мне как раз кажется очень перспективной.


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
_Harry писал(а):
У меня как раз складывается мнение что 8-разрядные системы скоро сильно сдадут свои исконные позиции 16-разрядным так как цены и экономичность ( в смысле питания) практически сравнялись.

А не может ли быть такого, что и возможность работы 16-разрядных систем с 32-разрядными данными сильно улучшатся в рамках тех же тенденций? :)
_Harry писал(а):
Да действительно 32-разрядную систему использовать будет проще, но ресурсу она скушает на 16-разрядном ядре гораздо больше.
Мало того ведь самые дешёвые представители MSP430 длинные команды не поддерживают.

Тут ведь есть вариант - не использовать такие МК для задач с высокими требованиями к производительности программ на Форте. И вариант, надо сказать, не такой уж страшный. Потому что если я вижу, что у чипа проблемы с поддержкой данных большого объема, то я при любом используемом языке десять раз подумаю, прежде чем его выбирать.

_Harry писал(а):
Вобщем идея отдельного стека для адресов мне как раз кажется очень перспективной.

А мне - абсолютно лишней. Потому что это требование писать с учетом стека адресов, а не возможность использования еще и такого подхода. Локальный стек, или стек с плавающей точкой - что есть, что нет. Если мы их не используем, то ничего и не меняется. А вот стек адресов напрочь ломает устоявшийся стиль программирования, и заставляет переучиваться, с прохождением по куче новых граблей.


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

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2168
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 41 раз.
Хищник писал(а):
Потому что это требование писать с учетом стека адресов, а не возможность использования еще и такого подхода.

Давайте попробуем в таком случае убрать и требование писать с учетом стека параметров.

_________________
С уважением, chess


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

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

А требования-то и нет. На Форте можно писать и без стека, на глобальных регистрах :) Только регистровые модели для Форта не получили такого распространения, как стековая. А стековая, в свою очередь, уже проработана, команды работы со стеком "въелись", они узнаваемы, можно находить примеры и пробовать их на самых разных трансляторах. А тут получится, что отлетает сразу огромный пласт программ.


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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 159 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8, 9, 10, 11  След.

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


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

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


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

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