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

...
Google Search
Forth-FAQ Spy Grafic

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




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - RFS, замечания от Ethereal
Автор Сообщение
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Хищник писал(а):
Оно с точки зрения логики выглядит неоднозначно, только и всего. Дело не в том, что "правильно" или "неправильно" (и с чьей точки зрения), а в том, что сказав "А", нельзя потом говорить "ни в коем случае не А". В этом проблема многих непрофессиональных исследователей, которые любят жаловаться, что их кто-то давит авторитетом, и главная причина их критики - ревность носителей этого самого авторитета. А я, к примеру, где-то в обсуждении хоть какую-то свою мысль проталкивал? Всего-то просил уточнить позицию и приводил примеры, которые с моей точки зрения следуют из высказанного. Это вызывает проблемы?

Логика бывает разная. 'Выглядит', это не эквивалентно 'является'. Кто говорит "A"? Я не говорю. Позицию уточнить - это можно. Для поддержки арифметики большой разрядности, которая непосредственно не поддерживается процессором, определяем понятие переноса на верхнем уровне языка. При этом арифметику
скажем двойной разрядности можно определить и на нижнем уровне, так как это нужно сейчас и в самом быстром варианте. А арифметика большей разрядности чем двойная сейчас не нужна(мне). Но это не значит, что она не будет нужна другим. Вот для этих других и выносим на верхний уровень средства для ее написания. Да даже и я смогу написать ее на верхнем уровне быстрее чем на ассемблере. Причем проигрыш по быстродействию будет относительно небольшим.
Хищник писал(а):
Я не прилагаю нигде. И не предлагаю свою позицию. Я указал на замеченные противоречия в предложенном не мной. Не недостатки (которые можно списать на мою субъективность), а именно противоречия, выражающиеся в постановках задач и предложении свойств, оказывающих разное влияние, в том числе и попросту противоречивое по определению. И какая реакция? Сунуть голову в песок, чтобы критика не разрушала только-только начавшую вырисовываться благостную картину?

Я не про вас. Противоречий нет, есть субъективный (узкий) взгляд на ситуацию. От этого и критика.
Сообщение Добавлено: Пт окт 14, 2011 15:44
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
chess писал(а):
Хищник писал(а):
Вот не надо упираться в том, что уже давно выглядит неоднозначно.

Для кого выглядит? Для вас? Для меня нет.

Оно с точки зрения логики выглядит неоднозначно, только и всего. Дело не в том, что "правильно" или "неправильно" (и с чьей точки зрения), а в том, что сказав "А", нельзя потом говорить "ни в коем случае не А". В этом проблема многих непрофессиональных исследователей, которые любят жаловаться, что их кто-то давит авторитетом, и главная причина их критики - ревность носителей этого самого авторитета. А я, к примеру, где-то в обсуждении хоть какую-то свою мысль проталкивал? Всего-то просил уточнить позицию и приводил примеры, которые с моей точки зрения следуют из высказанного. Это вызывает проблемы?
chess писал(а):
Если вы их не видели, то по-вашему их и быть не может. 'Правильно', но только для вас.

"Доказываются позитивные утверждения". Почему все (!) должны срываться с места и переделывать реализации, и только из-за того, что кто-то придумал пользователей, которым якобы что-то надо, но на предложение предъявить этих пользователей встает на дыбы?
chess писал(а):
Теория это плод изучения многих фактов. Поэтому начать нужно с нее, может и не понадобится накапливать факты-то.

Понадобится или не понадобится, а также как соотносятся теория и эксперимент, подробно описано в трудах Бэкона и Декарта. Изучается в вузовском курсе философии (для инженеров тоже). Тут нечего изобретать, нужен только опыт, получаемый в реально работающем коллективе.
chess писал(а):
Вы прилагаете усилия там где надо вам, а там где не надо будут прилагать после и другие.

Я не прилагаю нигде. И не предлагаю свою позицию. Я указал на замеченные противоречия в предложенном не мной. Не недостатки (которые можно списать на мою субъективность), а именно противоречия, выражающиеся в постановках задач и предложении свойств, оказывающих разное влияние, в том числе и попросту противоречивое по определению. И какая реакция? Сунуть голову в песок, чтобы критика не разрушала только-только начавшую вырисовываться благостную картину?
Сообщение Добавлено: Сб окт 08, 2011 23:55
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Хищник писал(а):
Вот не надо упираться в том, что уже давно выглядит неоднозначно.

Для кого выглядит? Для вас? Для меня нет.
Хищник писал(а):
Какая еще "логика развития"?

Хищник писал(а):
Зачем в очередной раз придумывать каких-то пользователей, которых никто не видел, и какие-то "определеенные классы задач", которые никто не решал?

Если вы их не видели, то по-вашему их и быть не может. 'Правильно', но только для вас.
Хищник писал(а):
Что до теории без накопления фактов, то это либо для сверхгения, прозревшего пласт знаний, и лихорадочно записывающего узнанное, либо для студента, мечтающего о мировой славе, которому факты просто мешают, и он поступает с ними как кошка, "закапывающая" отходы жизнедеятельности в углу под креслом. Ну в углу же! Авось не найдут. Ну не делают так. А когда делают, оно просто протаскивает свои изначальные методологические просчеты все дальше и дальше. Хотя решения-то часто не сводятся к каким-то суперподходам, а просто к достижению внутренней согласованности работы.

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

Вы прилагаете усилия там где надо вам, а там где не надо будут прилагать после и другие.
Хищник писал(а):
А если надо обеспечить совместимость, то откуда вообще может взяться имя регистра в конкретной архитектуре?
конкретная архитектура может быть описана абстрактно.
Сообщение Добавлено: Сб окт 08, 2011 10:44
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
вопрос писал(а):
вывод в общем напрашивается, но он неприятен - форт должен стандартизировать требование документирования различных возможностей

Согласен с выводом, но не особо согласен с его неприятностью. Кстати, я такое уже предлагал.
Сообщение Добавлено: Сб окт 08, 2011 00:54
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
chess писал(а):
Это логика развития. Не знаем, но предполагаем варианты.
Следование этой логике часто гораздо полезнее для результата, чем накопление фактов.

Вот не надо упираться в том, что уже давно выглядит неоднозначно. Какая еще "логика развития"? Ситуация совершенно конкретная. Зачем в очередной раз придумывать каких-то пользователей, которых никто не видел, и какие-то "определеенные классы задач", которые никто не решал? Что до теории без накопления фактов, то это либо для сверхгения, прозревшего пласт знаний, и лихорадочно записывающего узнанное, либо для студента, мечтающего о мировой славе, которому факты просто мешают, и он поступает с ними как кошка, "закапывающая" отходы жизнедеятельности в углу под креслом. Ну в углу же! Авось не найдут. Ну не делают так. А когда делают, оно просто протаскивает свои изначальные методологические просчеты все дальше и дальше. Хотя решения-то часто не сводятся к каким-то суперподходам, а просто к достижению внутренней согласованности работы.
chess писал(а):
Что касается стека возвратов. Виртуальная машина форта двухстековая.
Один из стеков - стек возвратов. Это не означает, что в железе в обязательном порядке такой стек есть.
>R R> означают, что параметр базовой разрядности со стека параметров переносится на стек возвратов или наоборот.

А вот как понять, зачем число переносится на стек возвратов? Чтобы потом передать управление (и тогда оно должно иметь разрядность адреса), или это временный перенос со стека данных (и тогда может потребоваться занять больше одной ячейки стека возвратов). Это так, штрих, я не к тому, что надо срочно разобраться со стеком возвратов. Просто иллюстрация к тому, что предлагаемое может иметь и другие последствия, кроме явно подразумеваемых. Хорошо, когда ожидаемые преимущества не застилают глаза, и человек радуется не тому, что он сразу сделал классно, а уже тому, что он работает, творит и разбирается в ситуации все глубже и глубже.
chess писал(а):
Что касается предложений по оценке 1. 2.,
то по 1. не вижу смысла оценивать, так как (по-моему) специфицирование вершины стека не должно входить в стандарт.
По 2. если не включать 'ассемблерный' набор слов в обязательный список слов форта, то имеет смысл поддержку переноса
включить в обязательный список по причине малых издержек как в части объема кода, так и по вносимым задержкам времени исполнения.

Ага, по стеку возвратов зато много написано :D
Обращаю внимание, что указанные пункты имеют разные наборы преимуществ и недостатков. С точки зрения последовательного улучшения каких-то характеристик они что-то не очень совместимы, правда? А это уже странно смотрится. Метаться нецелесообразно, уж если прилагаем в одном месте усилия по улучшению быстродействия, то не надо в другом ее ухудшать. А если надо обеспечить совместимость, то откуда вообще может взяться имя регистра в конкретной архитектуре?
Сообщение Добавлено: Сб окт 08, 2011 00:52
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Ну, что ж, вот моё ответ Ethereal после прочтения этой темы
  1. действительно, проблема существует и мы все не совсем уверены как её решать
  2. наличие/отсуствие/реализация в процессоре тех или иных действий (той или иной арифметики) не может быть ограничена - её многообразие обьективно
  3. концептуальная трудность такова - болльшинство языков ограничиваются собственными действиями, никак не соотносясь с ассемблером и потому переносимы (скажем, при переходе на процессор без СП плавающая точка эмулируется)
  4. форт не может игнорировать проблему ввиду того, что фортеры любят прозрачность и открытость компилятора, т.о. форт тут не может походить на фортран, скажем
  5. вывод в общем напрашивается, но он неприятен - форт должен стандартизировать требование документирования различных возможностей, в том числе внутренние слова для предоставления информации, если, например, файл документации к транслятору потерян; кстати, в гораздо более закрытом фортране есть система внутренней диагостики
последнее я предложил рассмотреть как возможность в своей теме про минимальные библиотеки
там я называю их "информирующие"
Сообщение Добавлено: Пт окт 07, 2011 18:06
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Везде кроме Форта BigInteger в стандартной библиотеке уже. И с разрядностью никто так не заморачивается.
Сообщение Добавлено: Пт окт 07, 2011 09:19
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Хищник писал(а):
Интересная логика Людей, может, и нет, но насчет их способностей мы порассуждаем? И все для того, чтобы поставить галочку "произведено развитие Форта"? При этом я тут же могу указать, что стек возвратов в принципе не обязан хранить такие же числа, что и стек данных. Обобщения-то надо делать на основе объективной оценки сложившейся ситуации, тогда действительно будет полезно. А сейчас получается "возьмем доширак, чтобы сэкономить, и черной икры, потому что вкусно".
Предлагаю оценить плюсы и минусы рассмотренных выше решений:
1. Размещение вершины стека в регистре
2. Обеспечение доступа к флагу переноса
Параметры оценки можно и самостоятельно поискать, а в случае чего я расскажу свою версию этого списка.

Это логика развития. Не знаем, но предполагаем варианты.
Следование этой логике часто гораздо полезнее для результата, чем накопление фактов.
Что касается стека возвратов. Виртуальная машина форта двухстековая.
Один из стеков - стек возвратов. Это не означает, что в железе в обязательном порядке такой стек есть.
>R R> означают, что параметр базовой разрядности со стека параметров переносится на стек возвратов или наоборот.
Исторически это пошло от того, что кроме адресов возврата на стек возвратов помещались параметры подпрограмм, например,
перед входом в процедуру обработки прерывания да и в других случаях. При этом стек возвратов не обязательно имел
разрядность, равную разрядности параметров. Ну может его разрядность была кратна 8-и или 4-м. В любом случае
поддерживалась переброска параметров произвольной разрядности на этот стек из регистров или из памяти.
В настоящее время этого можно не придерживаться, так как возможны другие варианты хранения и передачи параметров.
Поэтому второй стек может быть реализован в памяти или вообще опущен или стеков может быть больше 2-х.
Что касается предложений по оценке 1. 2.,
то по 1. не вижу смысла оценивать, так как (по-моему) специфицирование вершины стека не должно входить в стандарт.
По 2. если не включать 'ассемблерный' набор слов в обязательный список слов форта, то имеет смысл поддержку переноса
включить в обязательный список по причине малых издержек как в части объема кода, так и по вносимым задержкам времени исполнения.
Сообщение Добавлено: Пт окт 07, 2011 08:47
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Интересная логика :) Людей, может, и нет, но насчет их способностей мы порассуждаем? :)) И все для того, чтобы поставить галочку "произведено развитие Форта"? При этом я тут же могу указать, что стек возвратов в принципе не обязан хранить такие же числа, что и стек данных. Обобщения-то надо делать на основе объективной оценки сложившейся ситуации, тогда действительно будет полезно. А сейчас получается "возьмем доширак, чтобы сэкономить, и черной икры, потому что вкусно".
Предлагаю оценить плюсы и минусы рассмотренных выше решений:
1. Размещение вершины стека в регистре
2. Обеспечение доступа к флагу переноса
Параметры оценки можно и самостоятельно поискать, а в случае чего я расскажу свою версию этого списка.
Сообщение Добавлено: Чт окт 06, 2011 18:00
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Хищник писал(а):
А можно конкретнее? Что это за такие люди, которым нужна большая разрядность, но которые наотрез отказываются прочитать про бит переноса? Точно ли ради них нужно всех переполошить, и не проще ли забить на их закидоны болт М32? Что именно (ненаписанные библиотеки, которые больше никто не сможет повторить, потерянные заказы на трансляторы) потеряют люди, не учитывающие в стандарте вынос бита переноса на верхний уровень?

Не знаю, может их и нет. Но зачем им читать про бит переноса - они и так знают что это такое, только не для конкретного процессора, а как понятие арифметики двоичных чисел.
Ну вот нет понятия о переносе для конкретного процессора, а есть слово FCARRY, оставляющее 1 если есть перенос, тогда они в состоянии написать:
Код:
: d+ ( d1 d2 -- d3 )
ROT + >R + FCARRY R> + ;

и тп. Таким образом появляется возможность расширять форт в направлении получения операций с большей разрядностью не прибегая к коррекции его исходников.
Сообщение Добавлено: Чт окт 06, 2011 12:19
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
А можно конкретнее? Что это за такие люди, которым нужна большая разрядность, но которые наотрез отказываются прочитать про бит переноса? Точно ли ради них нужно всех переполошить, и не проще ли забить на их закидоны болт М32? Что именно (ненаписанные библиотеки, которые больше никто не сможет повторить, потерянные заказы на трансляторы) потеряют люди, не учитывающие в стандарте вынос бита переноса на верхний уровень?
Сообщение Добавлено: Чт окт 06, 2011 10:53
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Хищник писал(а):
Во-первых, разрядность - далеко не главная проблема при разработке переносимого ПО. Во-вторых, для ее решения есть такой замечательный транслятор, как СвойФорт.

Это верно. Собственно в МоемФорте, в котором под рукой встроенный ассемблер такого рода задачи решаются просто и эффективно, но есть же и те кто не знает инструкций процессора(таких много), но которые знают как устроена арифметика.
Сообщение Добавлено: Чт окт 06, 2011 10:05
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
О дискуссия плавно перетекла в обсуждение эффективности использования ресурсов аппаратуры да еще и эффективным способом ))
Скажите а при чем здесь разрядность? некогда не любил вопросов про то, что вы считаете важным скорость обработки изображения или его качество - и то, и другое важно.
Тут что-то подобное... Только вот не для всех задач нужна разрядность больше чем в 16 бит )

О возможностях процессора :
Мне нравится например в purebasic стоит при компиляции оптимизироваь код под такой-то процессор или сгенерировать оптимизированный код под все процессоры.

О доступе к памяти:
Современная аппаратура любит доступ к адресам выровненой по определенной границе, желательно чтоб совпадала с половиной от ширины или полной ширирной шины даннных

Мое мнение таково - современная програма должна учитывать особености аппаратуры по полной. Это оставит код компактным, и скорость исполнения программ не будет притчей во языцах.
Сообщение Добавлено: Ср окт 05, 2011 21:17
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
Во-первых, разрядность - далеко не главная проблема при разработке переносимого ПО. Во-вторых, для ее решения есть такой замечательный транслятор, как СвойФорт. :)
Сообщение Добавлено: Ср окт 05, 2011 20:19
  Заголовок сообщения:  Re: RFS, замечания от Ethereal  Ответить с цитатой
chess писал(а):
Просто из двух фортов, один из которых на уровне языка поддерживает перенос, а другой нет, я бы предпочел первый. В нем было бы проще совмещать ПО, написанно для разных платформ. Не всегда ведь производительность связки процессор - ПО является критичным фактором.
Сообщение Добавлено: Ср окт 05, 2011 14:35

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


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