Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт авг 17, 2018 13:09

...
Google Search
Forth-FAQ Spy Grafic

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




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

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2113
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 40 раз.
white_TigR писал(а):
А не правильнее ли будет, в таком случае, на этом же встроеном ассемблере и писать весь кусок кода, вместо мешанины форта и асма?

Я встроенный ассемблер делал именно для того чтобы писать на форте и ассме одновременно.
Тут слова 1+ и им подобные просто открываются с новой стороны, но таких слов мало - легко запомнить.
В форте тоже для многих слов есть свои особенности их применения, что тоже надо помнить.
А так, да, вместо куска 1+ L1 JC можно записать A++ L1 JC ( здесь A++ даст короткий код INC EAX, что эквивалентно 1 + ) .

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


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6375
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
chess писал(а):
А так, да, вместо куска 1+ L1 JC можно записать A++ L1 JC ( здесь A++ даст короткий код INC EAX, что эквивалентно 1 + ) .

Это в случае, когда eax содержит вершину стека. Что приводит к еще большей мешанине нюансов и особых случаев.


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

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

Если вершина стека находилась бы, например, в ebx, то было бы B++(причем определения : B++ INC EBX ; в словаре форта нет, а есть что-то типа : R++ INC R ; (это грубое приближение, конечно) и тд. Нюансов нет - есть постоянная картина аппаратной поддержки форт-вм. Знать эту картину конечно надо, это да. Но это все статика и она без проблем укладывается в долговременную память программиста, как например, без проблем туда же укладывается программная модель процессора у программирующего на ассме.

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


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6375
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
chess писал(а):
Нюансов нет - есть постоянная картина аппаратной поддержки форт-вм. Знать эту картину конечно надо, это да. Но это все статика и она без проблем укладывается в долговременную память программиста, как например, без проблем туда же укладывается программная модель процессора у программирующего на ассме.

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


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

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

Само собой. Я об сказал сразу, говоря о постоянной картине аппаратной поддержки форт-вм.
Хищник писал(а):
Что исключает, к примеру, какие-то эксперименты с регистрами.

Эксперименты с регистрами при этом возможны при соблюдении отскока. К примеру, как один из возможных способов для x86 для этого, использование инструкций PUSHAD и POPAD, которые кроме этого также дают возможность параллельно вести работу на ассме и форте.
Хищник писал(а):
А вообще стек в памяти - наиболее простая для понимания реализация, и ничего отслеживать не надо.

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

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


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6375
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
chess писал(а):
Само собой. Я об сказал сразу, говоря о постоянной картине аппаратной поддержки форт-вм.

Тогда получается, что в стандарте на Форте (см. тему и раздел) надо зафиксировать, что вершина стека находится в eax? То есть прощайте, прочие архитектуры?
chess писал(а):
Да это так, но все таки стек в памяти дает некоторое проседание по производительности.

Если эффект проверяется на тестах, делаемых под впечатлением от находки, прирост производительности может оказаться сильно завышен. Глубина стека при выполнении программ меняется постоянно, поэтому помещение вершины в регистр не так уж заметно уменьшает число операций с памятью.
chess писал(а):
Стеки в памяти заводить в любом количестве можно и имея основной стек с аппаратной поддержкой. Одно другому не мешает.

Вот только стандартизации это мешает.


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

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

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

Для х86 это не впечатления, а результат практических проверок, которые и привели к тому, что практически все форт-системы имеют
вершину стека в регистре.
Хищник писал(а):
Вот только стандартизации это мешает.

Какой стандартизации? Той что есть или той что нет. Если той что есть, то не мешает. А той что нет вообще ничего не мешает. :)

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


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6375
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
chess писал(а):
Стандарт не должен привязывать форт-вм к конкретной платформе.
Тем не менее для реализации форт-вм на конкретной платформе такая привязка д.б. зафиксирована.

И как можно понять вот эти два предложения вместе? Получается, что вообще оно не привязано, но как только сделали, то надо сразу привязать? :) И смысл? Уж или оно никак не влияет на поведение системы, и тогда в стандарте незачем и отмечать. В конце концов, мало ли какие еще эффективные реализации будут найдены. Или оно влияет, и тут надо сделать выбор. Либо функция implementation defined, либо это просто неудачная попытка реализации, про которую надо забыть.
chess писал(а):
Для х86 это не впечатления, а результат практических проверок, которые и привели к тому, что практически все форт-системы имеют
вершину стека в регистре.

Впечатления-впечатления ;) Слово "практика" частенько используется необоснованно. Практика - это не просто "сделали и вроде работает". Это когда сделали, проверили, забыли (а оно все равно работает), потом еще кто-то пришел к тем же выводам, и у него тоже заработало. А до кучи еще попробовали сделать не так, и сразу стало хуже. И еще кто-то независимо пришел к тем же выводам. Вот это уже ближе к практике. А личные предпочтения человека, заинтересованного в том, чтобы нравящееся ему решение похвалили - еще далеко не практика.
chess писал(а):
Какой стандартизации? Той что есть или той что нет. Если той что есть, то не мешает. А той что нет вообще ничего не мешает.

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


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

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2113
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 40 раз.
Хищник писал(а):
И как можно понять вот эти два предложения вместе? Получается, что вообще оно не привязано, но как только сделали, то надо сразу привязать? И смысл? Уж или оно никак не влияет на поведение системы, и тогда в стандарте незачем и отмечать. В конце концов, мало ли какие еще эффективные реализации будут найдены. Или оно влияет, и тут надо сделать выбор. Либо функция implementation defined, либо это просто неудачная попытка реализации, про которую надо забыть.
В стандарте незачем отмечать.
Хищник писал(а):
Впечатления-впечатления Слово "практика" частенько используется необоснованно. Практика - это не просто "сделали и вроде работает". Это когда сделали, проверили, забыли (а оно все равно работает), потом еще кто-то пришел к тем же выводам, и у него тоже заработало. А до кучи еще попробовали сделать не так, и сразу стало хуже. И еще кто-то независимо пришел к тем же выводам. Вот это уже ближе к практике. А личные предпочтения человека, заинтересованного в том, чтобы нравящееся ему решение похвалили - еще далеко не практика.
Коммерческие фирмы, которые особо отмечают производительность своих форт-систем по сравнению с конкурентами провели работу по выбору и отладке реализации форт-вм на предмет именно быстродействия. Это практика. Причем здесь личные предпочтения.

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


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6375
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
chess писал(а):
Коммерческие фирмы, которые особо отмечают производительность своих форт-систем по сравнению с конкурентами провели работу по выбору и отладке реализации форт-вм на предмет именно быстродействия. Это практика. Причем здесь личные предпочтения.

А что, разве код, создаваемый Фортом, отличается особо высокой производительностью? Ну ладно, есть там разные пункты среди features, и размещение часто используемых переменных в регистрах из общих соображений выглядит привлекательным. Но вот чтобы какая-то система вырвалась вперед именно по той причине, что у нее вершина стека в eax? Да пусть даже комплекс мер по ассемблерной оптимизации кода. Тут надо очень четко разграничить, будет ли это все менять поведение самого Форта. Если нет, то зачем вообще упоминать-то? А если да, то стоит ли эта разносортица небольшого повышения производительности?


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

Зарегистрирован: Чт июл 20, 2006 11:31
Сообщения: 2113
Откуда: Екб
Благодарил (а): 0 раз.
Поблагодарили: 40 раз.
Хищник писал(а):
А что, разве код, создаваемый Фортом, отличается особо высокой производительностью? Ну ладно, есть там разные пункты среди features, и размещение часто используемых переменных в регистрах из общих соображений выглядит привлекательным. Но вот чтобы какая-то система вырвалась вперед именно по той причине, что у нее вершина стека в eax? Да пусть даже комплекс мер по ассемблерной оптимизации кода. Тут надо очень четко разграничить, будет ли это все менять поведение самого Форта. Если нет, то зачем вообще упоминать-то? А если да, то стоит ли эта разносортица небольшого повышения производительности?

В результате без вершины стека в регистре не обошлись. Оптимальность как всегда достигается комплексно, и каждая деталь вносит свой вклад в конечный результат, причем вносит именно в комплексе с другими деталями, а не по отдельности.

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


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6375
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
chess писал(а):
В результате без вершины стека в регистре не обошлись. Оптимальность как всегда достигается комплексно, и каждая деталь вносит свой вклад в конечный результат, причем вносит именно в комплексе с другими деталями, а не по отдельности.

Я предлагаю все-таки вернуться к началу дискуссии. Речь шла о том, что какие-то слова Форта могут иметь более компактную или быструю реализацию, отличаясь нюансами. Возник вопрос, что делать с такими словами. В данном случае имеет место развитие обсуждения, перетекшее в то, надо ли фиксировать особенности реалищации самой форт-машины. Именно в этом ключе я и предлагаю рассматривать данный вопрос. Дело не в том, кто именно применил или не применил какое-то решение. Является ли оно абсолютно необходимым? Может ли получиться так, что кто-то все же сделает свой вариант Форта без лишних украшательств, и это будет все-таки Фортом, причем достаточно эффективным в рамках определенного применения? Вот именно этому процессу и стоило бы способствовать. А не пытаться рисовать красивые ярлычки, демонстрируя знание приемов оптимизации и терминов.


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

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

Мое мнение - не запрещать в стандарте введение таких слов, но если их в конкретной форт-системе нет, то дать описание этих слов через другие слова, имеющиеся в конкретной форт-системе в обязательном порядке. Есть таким образом обязательный список слов и дополнительный список слов, семантика которых должна выражаться через слова из обязательного списка. Если это невозможно, то такие слова не должны помещаться в доп. список слов.
Например, 2/ будет выражаться как 1 ARSHIFT, где ARSHIFT слово из обязательного списка, а 1 представление числового литерала 1. Тут могут появится возражения, так как понятие переноса в существующих стандартах отсутствует. Я с такими возражениями не согласен, так как понятие переноса считаю относится к арифметике, которую должен поддерживать любой язык.

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


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

Зарегистрирован: Вт ноя 06, 2007 21:23
Сообщения: 227
Откуда: Екатеринбург
Благодарил (а): 4 раз.
Поблагодарили: 7 раз.
Цитата:
Например, 2/ будет выражаться как 1 ARSHIFT, где ARSHIFT слово из обязательного списка, а 1 представление числового литерала 1. Тут могут появится возражения, так как понятие переноса в существующих стандартах отсутствует. Я с такими возражениями не согласен, так как понятие переноса считаю относится к арифметике, которую должен поддерживать любой язык.

Зачем держать в голове есть там перенос или нет, мы же стараемся уйти от контроля на уровня железа в программе чтоб код был перносимый. А вот на каждом железе реализация слов пусть будет своя, и это уже хорошо реализовано в ФОРТ-системах. Ядро и платформенно-независый код для генерации системы. Конечно когда мы хотим использовать осбенности некоторой архитектуры, то будем учитывать это в библотеках расширения или если хотите "мансарде вашего дома" или надстройке.

Конечно различная реализация слов 2 / и 2/ которые смотрятся одинаково не совсем хороша.
Возможен выход из этой ситуации введением дополнительных словарей с именами ARITHMETIC и LOGIC и после ваша система будет генерировать правильные последовательности машинных команд в зависимости от того какой словарь сейчас активен и каким образом оптимизировать 2 / в 2/ ,- в арифметический сдвиг или операцию деления.
Тогда вы контролируете сами какие виды операций будут использоваться и программа становится более докуменитрованной при использовании слова 2/.

вот такое оно мое мнение


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6375
Благодарил (а): 14 раз.
Поблагодарили: 99 раз.
chess писал(а):
Мое мнение - не запрещать в стандарте введение таких слов, но если их в конкретной форт-системе нет, то дать описание этих слов через другие слова, имеющиеся в конкретной форт-системе в обязательном порядке.

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

А что значит "поддерживать"? Языки программирования специфицируют типы данных. Перенос имеет утилитарное значение - увеличение разрядности обрабатываемых чисел по сравнению с разрядностью процессора.


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

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


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

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


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

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