Forth
http://fforum.winglion.ru/

RFS, замечания от Ethereal
http://fforum.winglion.ru/viewtopic.php?f=36&t=2764
Страница 7 из 8

Автор:  вопрос [ Вт окт 04, 2011 23:50 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Цитата:
Ее надо именно наращивать? Просто доработать ядро при необходимости нельзя?
Есть даже книжица на тему "как работать с числами произвольной величины, используя деление-умножение в столбик, там шла, в частности, речь о том. что невыгодно работать именно с десятичными числами, т.к. разрядность регистров процессора располагает к работе с числами большей значности

Автор:  Hishnik [ Ср окт 05, 2011 00:27 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

вопрос писал(а):
Есть даже книжица на тему "как работать с числами произвольной величины, используя деление-умножение в столбик, там шла, в частности, речь о том. что невыгодно работать именно с десятичными числами, т.к. разрядность регистров процессора располагает к работе с числами большей значности

А при чем тут десятичные числа? Делаем 64 бита на ассемблере. Ну еще 128. И 256. Так проще, поскольку по аналогии с уже существующим кодом.

Автор:  chess [ Ср окт 05, 2011 08:19 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Хищник писал(а):
Ее надо именно наращивать? Просто доработать ядро при необходимости нельзя?

Конечно можно. Это как раз тот второй вариант о котором я говорил. Но можно расширить форт и без доработки ядра если внести
в язык на уровне ядра только минимум понятий(слов) относящийся к поддержке арифметических операций, а именно понятие переноса, знака и нуля. Затем пользуясь этими словами можно расширить разрядность до какой надо не затрагивая ядро.
Вот сходу для x86-32(не ручаюсь за корректность - важна идея):
Код:
: flags DUP AH=F ;
: FCARRY flags 0x100 AND 0<> ;
: FSIGN  flags 0x8000 AND 0<> ;
: FZERO  flags 0x4000 AND 0= ;

FCARRY .
FSIGN  .
FZERO  .

лог.
Код:
CODE flags
5D181F 8945FC           MOV     FC [EBP] , EAX
5D1822 8D6DFC           LEA     EBP , FC [EBP]
5D1825 9F               LAHF
5D1826 C3               RET     NEAR
END-CODE

Автор:  вопрос [ Ср окт 05, 2011 11:01 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Хищник писал(а):
А при чем тут десятичные числа? Делаем 64 бита на ассемблере. Ну еще 128. И 256.

Цитата:
Затем пользуясь этими словами можно расширить разрядность до какой надо

Автор:  Hishnik [ Ср окт 05, 2011 13:57 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

А если "пользуясь этими словами" - неэффективно? Дело ведь не в том, что есть какие-то "правильные" взгляды, а в наличии обоснованной оценки решений. В этом случае эффективнее на ассемблере. Потому что сделать несложно, а эффект явный и с множеством проявлений.

Автор:  chess [ Ср окт 05, 2011 14:35 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

chess писал(а):
Просто из двух фортов, один из которых на уровне языка поддерживает перенос, а другой нет, я бы предпочел первый. В нем было бы проще совмещать ПО, написанно для разных платформ. Не всегда ведь производительность связки процессор - ПО является критичным фактором.

Автор:  Hishnik [ Ср окт 05, 2011 20:19 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Во-первых, разрядность - далеко не главная проблема при разработке переносимого ПО. Во-вторых, для ее решения есть такой замечательный транслятор, как СвойФорт. :)

Автор:  Alexander [ Ср окт 05, 2011 21:17 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

О дискуссия плавно перетекла в обсуждение эффективности использования ресурсов аппаратуры да еще и эффективным способом ))
Скажите а при чем здесь разрядность? некогда не любил вопросов про то, что вы считаете важным скорость обработки изображения или его качество - и то, и другое важно.
Тут что-то подобное... Только вот не для всех задач нужна разрядность больше чем в 16 бит )

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

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

Мое мнение таково - современная програма должна учитывать особености аппаратуры по полной. Это оставит код компактным, и скорость исполнения программ не будет притчей во языцах.

Автор:  chess [ Чт окт 06, 2011 10:05 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Хищник писал(а):
Во-первых, разрядность - далеко не главная проблема при разработке переносимого ПО. Во-вторых, для ее решения есть такой замечательный транслятор, как СвойФорт.

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

Автор:  Hishnik [ Чт окт 06, 2011 10:53 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

А можно конкретнее? Что это за такие люди, которым нужна большая разрядность, но которые наотрез отказываются прочитать про бит переноса? Точно ли ради них нужно всех переполошить, и не проще ли забить на их закидоны болт М32? Что именно (ненаписанные библиотеки, которые больше никто не сможет повторить, потерянные заказы на трансляторы) потеряют люди, не учитывающие в стандарте вынос бита переноса на верхний уровень?

Автор:  chess [ Чт окт 06, 2011 12:19 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Хищник писал(а):
А можно конкретнее? Что это за такие люди, которым нужна большая разрядность, но которые наотрез отказываются прочитать про бит переноса? Точно ли ради них нужно всех переполошить, и не проще ли забить на их закидоны болт М32? Что именно (ненаписанные библиотеки, которые больше никто не сможет повторить, потерянные заказы на трансляторы) потеряют люди, не учитывающие в стандарте вынос бита переноса на верхний уровень?

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

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

Автор:  Hishnik [ Чт окт 06, 2011 18:00 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Интересная логика :) Людей, может, и нет, но насчет их способностей мы порассуждаем? :)) И все для того, чтобы поставить галочку "произведено развитие Форта"? При этом я тут же могу указать, что стек возвратов в принципе не обязан хранить такие же числа, что и стек данных. Обобщения-то надо делать на основе объективной оценки сложившейся ситуации, тогда действительно будет полезно. А сейчас получается "возьмем доширак, чтобы сэкономить, и черной икры, потому что вкусно".
Предлагаю оценить плюсы и минусы рассмотренных выше решений:
1. Размещение вершины стека в регистре
2. Обеспечение доступа к флагу переноса
Параметры оценки можно и самостоятельно поискать, а в случае чего я расскажу свою версию этого списка.

Автор:  chess [ Пт окт 07, 2011 08:47 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

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

Это логика развития. Не знаем, но предполагаем варианты.
Следование этой логике часто гораздо полезнее для результата, чем накопление фактов.
Что касается стека возвратов. Виртуальная машина форта двухстековая.
Один из стеков - стек возвратов. Это не означает, что в железе в обязательном порядке такой стек есть.
>R R> означают, что параметр базовой разрядности со стека параметров переносится на стек возвратов или наоборот.
Исторически это пошло от того, что кроме адресов возврата на стек возвратов помещались параметры подпрограмм, например,
перед входом в процедуру обработки прерывания да и в других случаях. При этом стек возвратов не обязательно имел
разрядность, равную разрядности параметров. Ну может его разрядность была кратна 8-и или 4-м. В любом случае
поддерживалась переброска параметров произвольной разрядности на этот стек из регистров или из памяти.
В настоящее время этого можно не придерживаться, так как возможны другие варианты хранения и передачи параметров.
Поэтому второй стек может быть реализован в памяти или вообще опущен или стеков может быть больше 2-х.
Что касается предложений по оценке 1. 2.,
то по 1. не вижу смысла оценивать, так как (по-моему) специфицирование вершины стека не должно входить в стандарт.
По 2. если не включать 'ассемблерный' набор слов в обязательный список слов форта, то имеет смысл поддержку переноса
включить в обязательный список по причине малых издержек как в части объема кода, так и по вносимым задержкам времени исполнения.

Автор:  Antender [ Пт окт 07, 2011 09:19 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Везде кроме Форта BigInteger в стандартной библиотеке уже. И с разрядностью никто так не заморачивается.

Автор:  вопрос [ Пт окт 07, 2011 18:06 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Ну, что ж, вот моё ответ Ethereal после прочтения этой темы
  1. действительно, проблема существует и мы все не совсем уверены как её решать
  2. наличие/отсуствие/реализация в процессоре тех или иных действий (той или иной арифметики) не может быть ограничена - её многообразие обьективно
  3. концептуальная трудность такова - болльшинство языков ограничиваются собственными действиями, никак не соотносясь с ассемблером и потому переносимы (скажем, при переходе на процессор без СП плавающая точка эмулируется)
  4. форт не может игнорировать проблему ввиду того, что фортеры любят прозрачность и открытость компилятора, т.о. форт тут не может походить на фортран, скажем
  5. вывод в общем напрашивается, но он неприятен - форт должен стандартизировать требование документирования различных возможностей, в том числе внутренние слова для предоставления информации, если, например, файл документации к транслятору потерян; кстати, в гораздо более закрытом фортране есть система внутренней диагостики
последнее я предложил рассмотреть как возможность в своей теме про минимальные библиотеки
там я называю их "информирующие"

Страница 7 из 8 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/