Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Хищник писал(а): Оно с точки зрения логики выглядит неоднозначно, только и всего. Дело не в том, что "правильно" или "неправильно" (и с чьей точки зрения), а в том, что сказав "А", нельзя потом говорить "ни в коем случае не А". В этом проблема многих непрофессиональных исследователей, которые любят жаловаться, что их кто-то давит авторитетом, и главная причина их критики - ревность носителей этого самого авторитета. А я, к примеру, где-то в обсуждении хоть какую-то свою мысль проталкивал? Всего-то просил уточнить позицию и приводил примеры, которые с моей точки зрения следуют из высказанного. Это вызывает проблемы? Логика бывает разная. 'Выглядит', это не эквивалентно 'является'. Кто говорит "A"? Я не говорю. Позицию уточнить - это можно. Для поддержки арифметики большой разрядности, которая непосредственно не поддерживается процессором, определяем понятие переноса на верхнем уровне языка. При этом арифметику скажем двойной разрядности можно определить и на нижнем уровне, так как это нужно сейчас и в самом быстром варианте. А арифметика большей разрядности чем двойная сейчас не нужна(мне). Но это не значит, что она не будет нужна другим. Вот для этих других и выносим на верхний уровень средства для ее написания. Да даже и я смогу написать ее на верхнем уровне быстрее чем на ассемблере. Причем проигрыш по быстродействию будет относительно небольшим. Хищник писал(а): Я не прилагаю нигде. И не предлагаю свою позицию. Я указал на замеченные противоречия в предложенном не мной. Не недостатки (которые можно списать на мою субъективность), а именно противоречия, выражающиеся в постановках задач и предложении свойств, оказывающих разное влияние, в том числе и попросту противоречивое по определению. И какая реакция? Сунуть голову в песок, чтобы критика не разрушала только-только начавшую вырисовываться благостную картину? Я не про вас. Противоречий нет, есть субъективный (узкий) взгляд на ситуацию. От этого и критика.
[quote="Хищник"]Оно с точки зрения логики выглядит неоднозначно, только и всего. Дело не в том, что "правильно" или "неправильно" (и с чьей точки зрения), а в том, что сказав "А", нельзя потом говорить "ни в коем случае не А". В этом проблема многих непрофессиональных исследователей, которые любят жаловаться, что их кто-то давит авторитетом, и главная причина их критики - ревность носителей этого самого авторитета. А я, к примеру, где-то в обсуждении хоть какую-то свою мысль проталкивал? Всего-то просил уточнить позицию и приводил примеры, которые с моей точки зрения следуют из высказанного. Это вызывает проблемы?[/quote] Логика бывает разная. 'Выглядит', это не эквивалентно 'является'. Кто говорит "A"? Я не говорю. Позицию уточнить - это можно. Для поддержки арифметики большой разрядности, которая непосредственно не поддерживается процессором, определяем понятие переноса на верхнем уровне языка. При этом арифметику скажем двойной разрядности можно определить и на нижнем уровне, так как это нужно сейчас и в самом быстром варианте. А арифметика большей разрядности чем двойная сейчас не нужна(мне). Но это не значит, что она не будет нужна другим. Вот для этих других и выносим на верхний уровень средства для ее написания. Да даже и я смогу написать ее на верхнем уровне быстрее чем на ассемблере. Причем проигрыш по быстродействию будет относительно небольшим. [quote="Хищник"]Я не прилагаю нигде. И не предлагаю свою позицию. Я указал на замеченные противоречия в предложенном не мной. Не недостатки (которые можно списать на мою субъективность), а именно противоречия, выражающиеся в постановках задач и предложении свойств, оказывающих разное влияние, в том числе и попросту противоречивое по определению. И какая реакция? Сунуть голову в песок, чтобы критика не разрушала только-только начавшую вырисовываться благостную картину?[/quote] Я не про вас. Противоречий нет, есть субъективный (узкий) взгляд на ситуацию. От этого и критика.
|
|
|
|
Добавлено: Пт окт 14, 2011 15:44 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
chess писал(а): Хищник писал(а): Вот не надо упираться в том, что уже давно выглядит неоднозначно.
Для кого выглядит? Для вас? Для меня нет. Оно с точки зрения логики выглядит неоднозначно, только и всего. Дело не в том, что "правильно" или "неправильно" (и с чьей точки зрения), а в том, что сказав "А", нельзя потом говорить "ни в коем случае не А". В этом проблема многих непрофессиональных исследователей, которые любят жаловаться, что их кто-то давит авторитетом, и главная причина их критики - ревность носителей этого самого авторитета. А я, к примеру, где-то в обсуждении хоть какую-то свою мысль проталкивал? Всего-то просил уточнить позицию и приводил примеры, которые с моей точки зрения следуют из высказанного. Это вызывает проблемы? chess писал(а): Если вы их не видели, то по-вашему их и быть не может. 'Правильно', но только для вас. "Доказываются позитивные утверждения". Почему все (!) должны срываться с места и переделывать реализации, и только из-за того, что кто-то придумал пользователей, которым якобы что-то надо, но на предложение предъявить этих пользователей встает на дыбы? chess писал(а): Теория это плод изучения многих фактов. Поэтому начать нужно с нее, может и не понадобится накапливать факты-то. Понадобится или не понадобится, а также как соотносятся теория и эксперимент, подробно описано в трудах Бэкона и Декарта. Изучается в вузовском курсе философии (для инженеров тоже). Тут нечего изобретать, нужен только опыт, получаемый в реально работающем коллективе. chess писал(а): Вы прилагаете усилия там где надо вам, а там где не надо будут прилагать после и другие. Я не прилагаю нигде. И не предлагаю свою позицию. Я указал на замеченные противоречия в предложенном не мной. Не недостатки (которые можно списать на мою субъективность), а именно противоречия, выражающиеся в постановках задач и предложении свойств, оказывающих разное влияние, в том числе и попросту противоречивое по определению. И какая реакция? Сунуть голову в песок, чтобы критика не разрушала только-только начавшую вырисовываться благостную картину?
[quote="chess"]Хищник писал(а): Вот не надо упираться в том, что уже давно выглядит неоднозначно.
Для кого выглядит? Для вас? Для меня нет.[/quote] Оно с точки зрения логики выглядит неоднозначно, только и всего. Дело не в том, что "правильно" или "неправильно" (и с чьей точки зрения), а в том, что сказав "А", нельзя потом говорить "ни в коем случае не А". В этом проблема многих непрофессиональных исследователей, которые любят жаловаться, что их кто-то давит авторитетом, и главная причина их критики - ревность носителей этого самого авторитета. А я, к примеру, где-то в обсуждении хоть какую-то свою мысль проталкивал? Всего-то просил уточнить позицию и приводил примеры, которые с моей точки зрения следуют из высказанного. Это вызывает проблемы? [quote="chess"]Если вы их не видели, то по-вашему их и быть не может. 'Правильно', но только для вас.[/quote] "Доказываются позитивные утверждения". Почему все (!) должны срываться с места и переделывать реализации, и только из-за того, что кто-то придумал пользователей, которым якобы что-то надо, но на предложение предъявить этих пользователей встает на дыбы? [quote="chess"]Теория это плод изучения многих фактов. Поэтому начать нужно с нее, может и не понадобится накапливать факты-то.[/quote] Понадобится или не понадобится, а также как соотносятся теория и эксперимент, подробно описано в трудах Бэкона и Декарта. Изучается в вузовском курсе философии (для инженеров тоже). Тут нечего изобретать, нужен только опыт, получаемый в реально работающем коллективе. [quote="chess"]Вы прилагаете усилия там где надо вам, а там где не надо будут прилагать после и другие.[/quote] Я не прилагаю нигде. И не предлагаю свою позицию. Я указал на замеченные противоречия в предложенном не мной. Не недостатки (которые можно списать на мою субъективность), а именно противоречия, выражающиеся в постановках задач и предложении свойств, оказывающих разное влияние, в том числе и попросту противоречивое по определению. И какая реакция? Сунуть голову в песок, чтобы критика не разрушала только-только начавшую вырисовываться благостную картину?
|
|
|
|
Добавлено: Сб окт 08, 2011 23:55 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Хищник писал(а): Вот не надо упираться в том, что уже давно выглядит неоднозначно. Для кого выглядит? Для вас? Для меня нет. Хищник писал(а): Какая еще "логика развития"? Хищник писал(а): Зачем в очередной раз придумывать каких-то пользователей, которых никто не видел, и какие-то "определеенные классы задач", которые никто не решал? Если вы их не видели, то по-вашему их и быть не может. 'Правильно', но только для вас. Хищник писал(а): Что до теории без накопления фактов, то это либо для сверхгения, прозревшего пласт знаний, и лихорадочно записывающего узнанное, либо для студента, мечтающего о мировой славе, которому факты просто мешают, и он поступает с ними как кошка, "закапывающая" отходы жизнедеятельности в углу под креслом. Ну в углу же! Авось не найдут. Ну не делают так. А когда делают, оно просто протаскивает свои изначальные методологические просчеты все дальше и дальше. Хотя решения-то часто не сводятся к каким-то суперподходам, а просто к достижению внутренней согласованности работы. Теория это плод изучения многих фактов. Поэтому начать нужно с нее, может и не понадобится накапливать факты-то. Хищник писал(а): Метаться нецелесообразно, уж если прилагаем в одном месте усилия по улучшению быстродействия, то не надо в другом ее ухудшать. Вы прилагаете усилия там где надо вам, а там где не надо будут прилагать после и другие. Хищник писал(а): А если надо обеспечить совместимость, то откуда вообще может взяться имя регистра в конкретной архитектуре? конкретная архитектура может быть описана абстрактно.
[quote="Хищник"]Вот не надо упираться в том, что уже давно выглядит неоднозначно.[/quote] Для кого выглядит? Для вас? Для меня нет.[quote="Хищник"]Какая еще "логика развития"? [/quote] [quote="Хищник"]Зачем в очередной раз придумывать каких-то пользователей, которых никто не видел, и какие-то "определеенные классы задач", которые никто не решал?[/quote] Если вы их не видели, то по-вашему их и быть не может. 'Правильно', но только для вас. [quote="Хищник"]Что до теории без накопления фактов, то это либо для сверхгения, прозревшего пласт знаний, и лихорадочно записывающего узнанное, либо для студента, мечтающего о мировой славе, которому факты просто мешают, и он поступает с ними как кошка, "закапывающая" отходы жизнедеятельности в углу под креслом. Ну в углу же! Авось не найдут. Ну не делают так. А когда делают, оно просто протаскивает свои изначальные методологические просчеты все дальше и дальше. Хотя решения-то часто не сводятся к каким-то суперподходам, а просто к достижению внутренней согласованности работы.[/quote] Теория это плод изучения многих фактов. Поэтому начать нужно с нее, может и не понадобится накапливать факты-то.[quote="Хищник"]Метаться нецелесообразно, уж если прилагаем в одном месте усилия по улучшению быстродействия, то не надо в другом ее ухудшать.[/quote] Вы прилагаете усилия там где надо вам, а там где не надо будут прилагать после и другие. [quote="Хищник"]А если надо обеспечить совместимость, то откуда вообще может взяться имя регистра в конкретной архитектуре?[/quote] конкретная архитектура может быть описана абстрактно.
|
|
|
|
Добавлено: Сб окт 08, 2011 10:44 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
вопрос писал(а): вывод в общем напрашивается, но он неприятен - форт должен стандартизировать требование документирования различных возможностей Согласен с выводом, но не особо согласен с его неприятностью. Кстати, я такое уже предлагал.
[quote="вопрос"]вывод в общем напрашивается, но он неприятен - форт должен стандартизировать требование документирования различных возможностей[/quote] Согласен с выводом, но не особо согласен с его неприятностью. Кстати, я такое уже предлагал.
|
|
|
|
Добавлено: Сб окт 08, 2011 00:54 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
chess писал(а): Это логика развития. Не знаем, но предполагаем варианты. Следование этой логике часто гораздо полезнее для результата, чем накопление фактов. Вот не надо упираться в том, что уже давно выглядит неоднозначно. Какая еще "логика развития"? Ситуация совершенно конкретная. Зачем в очередной раз придумывать каких-то пользователей, которых никто не видел, и какие-то "определеенные классы задач", которые никто не решал? Что до теории без накопления фактов, то это либо для сверхгения, прозревшего пласт знаний, и лихорадочно записывающего узнанное, либо для студента, мечтающего о мировой славе, которому факты просто мешают, и он поступает с ними как кошка, "закапывающая" отходы жизнедеятельности в углу под креслом. Ну в углу же! Авось не найдут. Ну не делают так. А когда делают, оно просто протаскивает свои изначальные методологические просчеты все дальше и дальше. Хотя решения-то часто не сводятся к каким-то суперподходам, а просто к достижению внутренней согласованности работы. chess писал(а): Что касается стека возвратов. Виртуальная машина форта двухстековая. Один из стеков - стек возвратов. Это не означает, что в железе в обязательном порядке такой стек есть. >R R> означают, что параметр базовой разрядности со стека параметров переносится на стек возвратов или наоборот. А вот как понять, зачем число переносится на стек возвратов? Чтобы потом передать управление (и тогда оно должно иметь разрядность адреса), или это временный перенос со стека данных (и тогда может потребоваться занять больше одной ячейки стека возвратов). Это так, штрих, я не к тому, что надо срочно разобраться со стеком возвратов. Просто иллюстрация к тому, что предлагаемое может иметь и другие последствия, кроме явно подразумеваемых. Хорошо, когда ожидаемые преимущества не застилают глаза, и человек радуется не тому, что он сразу сделал классно, а уже тому, что он работает, творит и разбирается в ситуации все глубже и глубже. chess писал(а): Что касается предложений по оценке 1. 2., то по 1. не вижу смысла оценивать, так как (по-моему) специфицирование вершины стека не должно входить в стандарт. По 2. если не включать 'ассемблерный' набор слов в обязательный список слов форта, то имеет смысл поддержку переноса включить в обязательный список по причине малых издержек как в части объема кода, так и по вносимым задержкам времени исполнения. Ага, по стеку возвратов зато много написано Обращаю внимание, что указанные пункты имеют разные наборы преимуществ и недостатков. С точки зрения последовательного улучшения каких-то характеристик они что-то не очень совместимы, правда? А это уже странно смотрится. Метаться нецелесообразно, уж если прилагаем в одном месте усилия по улучшению быстродействия, то не надо в другом ее ухудшать. А если надо обеспечить совместимость, то откуда вообще может взяться имя регистра в конкретной архитектуре?
[quote="chess"]Это логика развития. Не знаем, но предполагаем варианты. Следование этой логике часто гораздо полезнее для результата, чем накопление фактов.[/quote] Вот не надо упираться в том, что уже давно выглядит неоднозначно. Какая еще "логика развития"? Ситуация совершенно конкретная. Зачем в очередной раз придумывать каких-то пользователей, которых никто не видел, и какие-то "определеенные классы задач", которые никто не решал? Что до теории без накопления фактов, то это либо для сверхгения, прозревшего пласт знаний, и лихорадочно записывающего узнанное, либо для студента, мечтающего о мировой славе, которому факты просто мешают, и он поступает с ними как кошка, "закапывающая" отходы жизнедеятельности в углу под креслом. Ну в углу же! Авось не найдут. Ну не делают так. А когда делают, оно просто протаскивает свои изначальные методологические просчеты все дальше и дальше. Хотя решения-то часто не сводятся к каким-то суперподходам, а просто к достижению внутренней согласованности работы. [quote="chess"]Что касается стека возвратов. Виртуальная машина форта двухстековая. Один из стеков - стек возвратов. Это не означает, что в железе в обязательном порядке такой стек есть. >R R> означают, что параметр базовой разрядности со стека параметров переносится на стек возвратов или наоборот.[/quote] А вот как понять, зачем число переносится на стек возвратов? Чтобы потом передать управление (и тогда оно должно иметь разрядность адреса), или это временный перенос со стека данных (и тогда может потребоваться занять больше одной ячейки стека возвратов). Это так, штрих, я не к тому, что надо срочно разобраться со стеком возвратов. Просто иллюстрация к тому, что предлагаемое может иметь и другие последствия, кроме явно подразумеваемых. Хорошо, когда ожидаемые преимущества не застилают глаза, и человек радуется не тому, что он сразу сделал классно, а уже тому, что он работает, творит и разбирается в ситуации все глубже и глубже. [quote="chess"]Что касается предложений по оценке 1. 2., то по 1. не вижу смысла оценивать, так как (по-моему) специфицирование вершины стека не должно входить в стандарт. По 2. если не включать 'ассемблерный' набор слов в обязательный список слов форта, то имеет смысл поддержку переноса включить в обязательный список по причине малых издержек как в части объема кода, так и по вносимым задержкам времени исполнения.[/quote] Ага, по стеку возвратов зато много написано :D Обращаю внимание, что указанные пункты имеют разные наборы преимуществ и недостатков. С точки зрения последовательного улучшения каких-то характеристик они что-то не очень совместимы, правда? А это уже странно смотрится. Метаться нецелесообразно, уж если прилагаем в одном месте усилия по улучшению быстродействия, то не надо в другом ее ухудшать. А если надо обеспечить совместимость, то откуда вообще может взяться имя регистра в конкретной архитектуре?
|
|
|
|
Добавлено: Сб окт 08, 2011 00:52 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Ну, что ж, вот моё ответ Ethereal после прочтения этой темы - действительно, проблема существует и мы все не совсем уверены как её решать
- наличие/отсуствие/реализация в процессоре тех или иных действий (той или иной арифметики) не может быть ограничена - её многообразие обьективно
- концептуальная трудность такова - болльшинство языков ограничиваются собственными действиями, никак не соотносясь с ассемблером и потому переносимы (скажем, при переходе на процессор без СП плавающая точка эмулируется)
- форт не может игнорировать проблему ввиду того, что фортеры любят прозрачность и открытость компилятора, т.о. форт тут не может походить на фортран, скажем
- вывод в общем напрашивается, но он неприятен - форт должен стандартизировать требование документирования различных возможностей, в том числе внутренние слова для предоставления информации, если, например, файл документации к транслятору потерян; кстати, в гораздо более закрытом фортране есть система внутренней диагостики
последнее я предложил рассмотреть как возможность в своей теме про минимальные библиотекитам я называю их "информирующие"
Ну, что ж, вот моё ответ Ethereal после прочтения этой темы [list=a][*]действительно, проблема существует и мы все не совсем уверены как её решать[*]наличие/отсуствие/реализация в процессоре тех или иных действий (той или иной арифметики) не может быть ограничена - её многообразие обьективно [*]концептуальная трудность такова - болльшинство языков ограничиваются собственными действиями, никак не соотносясь с ассемблером и потому переносимы (скажем, при переходе на процессор без СП плавающая точка эмулируется)[*]форт не может игнорировать проблему ввиду того, что фортеры любят прозрачность и открытость компилятора, т.о. форт тут не может походить на фортран, скажем[*]вывод в общем напрашивается, но он неприятен - форт должен стандартизировать требование документирования различных возможностей, в том числе внутренние слова для предоставления информации, если, например, файл документации к транслятору потерян; кстати, в гораздо более закрытом фортране есть система внутренней диагостики[/list] последнее я предложил рассмотреть как возможность в своей [url=http://fforum.winglion.ru/viewtopic.php?f=9&t=2762&start=0]теме про минимальные библиотеки[/url] там я называю их "информирующие"
|
|
|
|
Добавлено: Пт окт 07, 2011 18:06 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Везде кроме Форта BigInteger в стандартной библиотеке уже. И с разрядностью никто так не заморачивается.
Везде кроме Форта BigInteger в стандартной библиотеке уже. И с разрядностью никто так не заморачивается.
|
|
|
|
Добавлено: Пт окт 07, 2011 09:19 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Хищник писал(а): Интересная логика Людей, может, и нет, но насчет их способностей мы порассуждаем? И все для того, чтобы поставить галочку "произведено развитие Форта"? При этом я тут же могу указать, что стек возвратов в принципе не обязан хранить такие же числа, что и стек данных. Обобщения-то надо делать на основе объективной оценки сложившейся ситуации, тогда действительно будет полезно. А сейчас получается "возьмем доширак, чтобы сэкономить, и черной икры, потому что вкусно". Предлагаю оценить плюсы и минусы рассмотренных выше решений: 1. Размещение вершины стека в регистре 2. Обеспечение доступа к флагу переноса Параметры оценки можно и самостоятельно поискать, а в случае чего я расскажу свою версию этого списка. Это логика развития. Не знаем, но предполагаем варианты. Следование этой логике часто гораздо полезнее для результата, чем накопление фактов. Что касается стека возвратов. Виртуальная машина форта двухстековая. Один из стеков - стек возвратов. Это не означает, что в железе в обязательном порядке такой стек есть. >R R> означают, что параметр базовой разрядности со стека параметров переносится на стек возвратов или наоборот. Исторически это пошло от того, что кроме адресов возврата на стек возвратов помещались параметры подпрограмм, например, перед входом в процедуру обработки прерывания да и в других случаях. При этом стек возвратов не обязательно имел разрядность, равную разрядности параметров. Ну может его разрядность была кратна 8-и или 4-м. В любом случае поддерживалась переброска параметров произвольной разрядности на этот стек из регистров или из памяти. В настоящее время этого можно не придерживаться, так как возможны другие варианты хранения и передачи параметров. Поэтому второй стек может быть реализован в памяти или вообще опущен или стеков может быть больше 2-х. Что касается предложений по оценке 1. 2., то по 1. не вижу смысла оценивать, так как (по-моему) специфицирование вершины стека не должно входить в стандарт. По 2. если не включать 'ассемблерный' набор слов в обязательный список слов форта, то имеет смысл поддержку переноса включить в обязательный список по причине малых издержек как в части объема кода, так и по вносимым задержкам времени исполнения.
[quote="Хищник"]Интересная логика Людей, может, и нет, но насчет их способностей мы порассуждаем? И все для того, чтобы поставить галочку "произведено развитие Форта"? При этом я тут же могу указать, что стек возвратов в принципе не обязан хранить такие же числа, что и стек данных. Обобщения-то надо делать на основе объективной оценки сложившейся ситуации, тогда действительно будет полезно. А сейчас получается "возьмем доширак, чтобы сэкономить, и черной икры, потому что вкусно". Предлагаю оценить плюсы и минусы рассмотренных выше решений: 1. Размещение вершины стека в регистре 2. Обеспечение доступа к флагу переноса Параметры оценки можно и самостоятельно поискать, а в случае чего я расскажу свою версию этого списка.[/quote] Это логика развития. Не знаем, но предполагаем варианты. Следование этой логике часто гораздо полезнее для результата, чем накопление фактов. Что касается стека возвратов. Виртуальная машина форта двухстековая. Один из стеков - стек возвратов. Это не означает, что в железе в обязательном порядке такой стек есть. >R R> означают, что параметр базовой разрядности со стека параметров переносится на стек возвратов или наоборот. Исторически это пошло от того, что кроме адресов возврата на стек возвратов помещались параметры подпрограмм, например, перед входом в процедуру обработки прерывания да и в других случаях. При этом стек возвратов не обязательно имел разрядность, равную разрядности параметров. Ну может его разрядность была кратна 8-и или 4-м. В любом случае поддерживалась переброска параметров произвольной разрядности на этот стек из регистров или из памяти. В настоящее время этого можно не придерживаться, так как возможны другие варианты хранения и передачи параметров. Поэтому второй стек может быть реализован в памяти или вообще опущен или стеков может быть больше 2-х. Что касается предложений по оценке 1. 2., то по 1. не вижу смысла оценивать, так как (по-моему) специфицирование вершины стека не должно входить в стандарт. По 2. если не включать 'ассемблерный' набор слов в обязательный список слов форта, то имеет смысл поддержку переноса включить в обязательный список по причине малых издержек как в части объема кода, так и по вносимым задержкам времени исполнения.
|
|
|
|
Добавлено: Пт окт 07, 2011 08:47 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Интересная логика Людей, может, и нет, но насчет их способностей мы порассуждаем? И все для того, чтобы поставить галочку "произведено развитие Форта"? При этом я тут же могу указать, что стек возвратов в принципе не обязан хранить такие же числа, что и стек данных. Обобщения-то надо делать на основе объективной оценки сложившейся ситуации, тогда действительно будет полезно. А сейчас получается "возьмем доширак, чтобы сэкономить, и черной икры, потому что вкусно". Предлагаю оценить плюсы и минусы рассмотренных выше решений: 1. Размещение вершины стека в регистре 2. Обеспечение доступа к флагу переноса Параметры оценки можно и самостоятельно поискать, а в случае чего я расскажу свою версию этого списка.
Интересная логика :) Людей, может, и нет, но насчет их способностей мы порассуждаем? :)) И все для того, чтобы поставить галочку "произведено развитие Форта"? При этом я тут же могу указать, что стек возвратов в принципе не обязан хранить такие же числа, что и стек данных. Обобщения-то надо делать на основе объективной оценки сложившейся ситуации, тогда действительно будет полезно. А сейчас получается "возьмем доширак, чтобы сэкономить, и черной икры, потому что вкусно". Предлагаю оценить плюсы и минусы рассмотренных выше решений: 1. Размещение вершины стека в регистре 2. Обеспечение доступа к флагу переноса Параметры оценки можно и самостоятельно поискать, а в случае чего я расскажу свою версию этого списка.
|
|
|
|
Добавлено: Чт окт 06, 2011 18:00 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Хищник писал(а): А можно конкретнее? Что это за такие люди, которым нужна большая разрядность, но которые наотрез отказываются прочитать про бит переноса? Точно ли ради них нужно всех переполошить, и не проще ли забить на их закидоны болт М32? Что именно (ненаписанные библиотеки, которые больше никто не сможет повторить, потерянные заказы на трансляторы) потеряют люди, не учитывающие в стандарте вынос бита переноса на верхний уровень? Не знаю, может их и нет. Но зачем им читать про бит переноса - они и так знают что это такое, только не для конкретного процессора, а как понятие арифметики двоичных чисел. Ну вот нет понятия о переносе для конкретного процессора, а есть слово FCARRY, оставляющее 1 если есть перенос, тогда они в состоянии написать: Код: : d+ ( d1 d2 -- d3 ) ROT + >R + FCARRY R> + ; и тп. Таким образом появляется возможность расширять форт в направлении получения операций с большей разрядностью не прибегая к коррекции его исходников.
[quote="Хищник"]А можно конкретнее? Что это за такие люди, которым нужна большая разрядность, но которые наотрез отказываются прочитать про бит переноса? Точно ли ради них нужно всех переполошить, и не проще ли забить на их закидоны болт М32? Что именно (ненаписанные библиотеки, которые больше никто не сможет повторить, потерянные заказы на трансляторы) потеряют люди, не учитывающие в стандарте вынос бита переноса на верхний уровень?[/quote] Не знаю, может их и нет. Но зачем им читать про бит переноса - они и так знают что это такое, только не для конкретного процессора, а как понятие арифметики двоичных чисел. Ну вот нет понятия о переносе для конкретного процессора, а есть слово FCARRY, оставляющее 1 если есть перенос, тогда они в состоянии написать: [code]: d+ ( d1 d2 -- d3 ) ROT + >R + FCARRY R> + ;[/code] и тп. Таким образом появляется возможность расширять форт в направлении получения операций с большей разрядностью не прибегая к коррекции его исходников.
|
|
|
|
Добавлено: Чт окт 06, 2011 12:19 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
А можно конкретнее? Что это за такие люди, которым нужна большая разрядность, но которые наотрез отказываются прочитать про бит переноса? Точно ли ради них нужно всех переполошить, и не проще ли забить на их закидоны болт М32? Что именно (ненаписанные библиотеки, которые больше никто не сможет повторить, потерянные заказы на трансляторы) потеряют люди, не учитывающие в стандарте вынос бита переноса на верхний уровень?
А можно конкретнее? Что это за такие люди, которым нужна большая разрядность, но которые наотрез отказываются прочитать про бит переноса? Точно ли ради них нужно всех переполошить, и не проще ли забить на их закидоны болт М32? Что именно (ненаписанные библиотеки, которые больше никто не сможет повторить, потерянные заказы на трансляторы) потеряют люди, не учитывающие в стандарте вынос бита переноса на верхний уровень?
|
|
|
|
Добавлено: Чт окт 06, 2011 10:53 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Хищник писал(а): Во-первых, разрядность - далеко не главная проблема при разработке переносимого ПО. Во-вторых, для ее решения есть такой замечательный транслятор, как СвойФорт. Это верно. Собственно в МоемФорте, в котором под рукой встроенный ассемблер такого рода задачи решаются просто и эффективно, но есть же и те кто не знает инструкций процессора(таких много), но которые знают как устроена арифметика.
[quote="Хищник"]Во-первых, разрядность - далеко не главная проблема при разработке переносимого ПО. Во-вторых, для ее решения есть такой замечательный транслятор, как СвойФорт. [/quote] Это верно. Собственно в МоемФорте, в котором под рукой встроенный ассемблер такого рода задачи решаются просто и эффективно, но есть же и те кто не знает инструкций процессора(таких много), но которые знают как устроена арифметика.
|
|
|
|
Добавлено: Чт окт 06, 2011 10:05 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
О дискуссия плавно перетекла в обсуждение эффективности использования ресурсов аппаратуры да еще и эффективным способом )) Скажите а при чем здесь разрядность? некогда не любил вопросов про то, что вы считаете важным скорость обработки изображения или его качество - и то, и другое важно. Тут что-то подобное... Только вот не для всех задач нужна разрядность больше чем в 16 бит )
О возможностях процессора : Мне нравится например в purebasic стоит при компиляции оптимизироваь код под такой-то процессор или сгенерировать оптимизированный код под все процессоры.
О доступе к памяти: Современная аппаратура любит доступ к адресам выровненой по определенной границе, желательно чтоб совпадала с половиной от ширины или полной ширирной шины даннных
Мое мнение таково - современная програма должна учитывать особености аппаратуры по полной. Это оставит код компактным, и скорость исполнения программ не будет притчей во языцах.
О дискуссия плавно перетекла в обсуждение эффективности использования ресурсов аппаратуры да еще и эффективным способом )) Скажите а при чем здесь разрядность? некогда не любил вопросов про то, что вы считаете важным скорость обработки изображения или его качество - и то, и другое важно. Тут что-то подобное... Только вот не для всех задач нужна разрядность больше чем в 16 бит )
О возможностях процессора : Мне нравится например в purebasic стоит при компиляции оптимизироваь код под такой-то процессор или сгенерировать оптимизированный код под все процессоры.
О доступе к памяти: Современная аппаратура любит доступ к адресам выровненой по определенной границе, желательно чтоб совпадала с половиной от ширины или полной ширирной шины даннных
Мое мнение таково - современная програма должна учитывать особености аппаратуры по полной. Это оставит код компактным, и скорость исполнения программ не будет притчей во языцах.
|
|
|
|
Добавлено: Ср окт 05, 2011 21:17 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
Во-первых, разрядность - далеко не главная проблема при разработке переносимого ПО. Во-вторых, для ее решения есть такой замечательный транслятор, как СвойФорт.
Во-первых, разрядность - далеко не главная проблема при разработке переносимого ПО. Во-вторых, для ее решения есть такой замечательный транслятор, как СвойФорт. :)
|
|
|
|
Добавлено: Ср окт 05, 2011 20:19 |
|
|
|
|
|
Заголовок сообщения: |
Re: RFS, замечания от Ethereal |
|
|
chess писал(а): Просто из двух фортов, один из которых на уровне языка поддерживает перенос, а другой нет, я бы предпочел первый. В нем было бы проще совмещать ПО, написанно для разных платформ. Не всегда ведь производительность связки процессор - ПО является критичным фактором.
[quote="chess"]Просто из двух фортов, один из которых на уровне языка поддерживает перенос, а другой нет, я бы предпочел первый. В нем было бы проще совмещать ПО, написанно для разных платформ. Не всегда ведь производительность связки процессор - ПО является критичным фактором.[/quote]
|
|
|
|
Добавлено: Ср окт 05, 2011 14:35 |
|
|
|
|