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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 110 ]  На страницу Пред.  1 ... 4, 5, 6, 7, 8  След.
Автор Сообщение
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Вт окт 04, 2011 23:50 
Не в сети

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Ср окт 05, 2011 00:27 
Не в сети
Administrator
Administrator
Аватара пользователя

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Ср окт 05, 2011 08:19 
Не в сети
Аватара пользователя

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

Конечно можно. Это как раз тот второй вариант о котором я говорил. Но можно расширить форт и без доработки ядра если внести
в язык на уровне ядра только минимум понятий(слов) относящийся к поддержке арифметических операций, а именно понятие переноса, знака и нуля. Затем пользуясь этими словами можно расширить разрядность до какой надо не затрагивая ядро.
Вот сходу для 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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Ср окт 05, 2011 11:01 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Хищник писал(а):
А при чем тут десятичные числа? Делаем 64 бита на ассемблере. Ну еще 128. И 256.

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Ср окт 05, 2011 13:57 
Не в сети
Administrator
Administrator
Аватара пользователя

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Ср окт 05, 2011 14:35 
Не в сети
Аватара пользователя

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Ср окт 05, 2011 20:19 
Не в сети
Administrator
Administrator
Аватара пользователя

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Ср окт 05, 2011 21:17 
Не в сети
Аватара пользователя

Зарегистрирован: Вт ноя 06, 2007 21:23
Сообщения: 227
Откуда: Екатеринбург
Благодарил (а): 4 раз.
Поблагодарили: 7 раз.
О дискуссия плавно перетекла в обсуждение эффективности использования ресурсов аппаратуры да еще и эффективным способом ))
Скажите а при чем здесь разрядность? некогда не любил вопросов про то, что вы считаете важным скорость обработки изображения или его качество - и то, и другое важно.
Тут что-то подобное... Только вот не для всех задач нужна разрядность больше чем в 16 бит )

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

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Чт окт 06, 2011 10:05 
Не в сети
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Чт окт 06, 2011 10:53 
Не в сети
Administrator
Administrator
Аватара пользователя

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Чт окт 06, 2011 12:19 
Не в сети
Аватара пользователя

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

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

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Чт окт 06, 2011 18:00 
Не в сети
Administrator
Administrator
Аватара пользователя

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Пт окт 07, 2011 08:47 
Не в сети
Аватара пользователя

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

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

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


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Пт окт 07, 2011 09:19 
Не в сети

Зарегистрирован: Вс апр 25, 2010 11:14
Сообщения: 200
Откуда: Москва
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
Везде кроме Форта BigInteger в стандартной библиотеке уже. И с разрядностью никто так не заморачивается.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: RFS, замечания от Ethereal
СообщениеДобавлено: Пт окт 07, 2011 18:06 
Не в сети

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


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

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


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

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


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

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