Forth http://fforum.winglion.ru/ |
|
Вздрогнули: Описание soft-процессоров серии EQUINOX http://fforum.winglion.ru/viewtopic.php?f=56&t=2182 |
Страница 4 из 6 |
Автор: | simne [ Вс июл 05, 2009 11:01 ] |
Заголовок сообщения: | |
Хищник писал(а): Если первый случай - GPF, то второй - совершенно штатная ситуация, вошедшая в околокомпьютерный фольклор как "диск свопит".
Для процессора нет разницы, GPF или "подкачка свопа", то есть по научному подкачка страницы виртуальной памяти (она не обязательно происходит с диска, может например с сети) - в любом случае происходит исключение (переключение контекста итп), а мы тут пока обсуждаем именно процессор а не ОС Впрочем, виртуальную память можно организовать и на уровне виртуальной машины - теряется производительность на програмные проверки, зато экономится некоторое количество вентилей на кристалле. |
Автор: | WingLion [ Вс июл 05, 2009 11:08 ] |
Заголовок сообщения: | |
mOleg писал(а): WingLion, симулятор будет?
Что-то я вопрос сей совсем упустил (прозевал)... Симулятор надо делать, но только после того, как железка более-менее заработает, иначе и симулировать нечего. В данный момент процессор умеет только экран забивать мусором. В текущем плане - работа над target-компилятором для него. |
Автор: | Hishnik [ Пн июл 06, 2009 00:07 ] |
Заголовок сообщения: | |
simne писал(а): Для процессора нет разницы, GPF или "подкачка свопа", то есть по научному подкачка страницы виртуальной памяти (она не обязательно происходит с диска, может например с сети) - в любом случае происходит исключение (переключение контекста итп), а мы тут пока обсуждаем именно процессор а не ОС
Для процессора как раз есть разница - не на каждое исключение выделяется специальный флаг. А "флаг присутствия страницы" как раз имеется в наличии. Делается это для ускорения обработки данного исключения, поскольку обмен с виртуальной памятью может происходить постоянно, и он не должен существенно тормозить работу процессора. А вот вылет за пределы выделенного адресного пространства может быть обработан и достаточно неторопливым способом, поскольку в финале пользователь все равно увидит "программа выполнила недопустимую операцию...". Для встроенного варианта форт-процессора мне не видится очень актуальным подключение внешней памяти для расширения стека - проблем много, а эффект состоит в основном в том, что программа еще немножко "протрепыхается", если в каком-то цикле на каждой итерации на стеке будет оставаться "забытое" число. |
Автор: | simne [ Пн июл 06, 2009 00:38 ] |
Заголовок сообщения: | |
Хищник писал(а): simne писал(а): Для процессора нет разницы, GPF или "подкачка свопа", то есть по научному подкачка страницы виртуальной памяти (она не обязательно происходит с диска, может например с сети) - в любом случае происходит исключение (переключение контекста итп), а мы тут пока обсуждаем именно процессор а не ОС Для процессора как раз есть разница - не на каждое исключение выделяется специальный флаг. А "флаг присутствия страницы" как раз имеется в наличии. Делается это для ускорения обработки данного исключения, поскольку обмен с виртуальной памятью может происходить постоянно, и он не должен существенно тормозить работу процессора. А вот вылет за пределы выделенного адресного пространства... Ну вообще-то виртуальная память на то и виртуальная, что для типичного современного процессора время обработки исключения измеряется в долях микросекунды, а время считывания/записи винта в лучшем случае в единицах миллисекунд, так что специальный флаг там погоды не делает, и многие не-х86 процессоры соответственно ничего подобного не имеют Хищник писал(а): Для встроенного варианта форт-процессора мне не видится очень актуальным подключение внешней памяти для расширения стека - проблем много, а эффект состоит в основном в том, что программа еще немножко "протрепыхается", если в каком-то цикле на каждой итерации на стеке будет оставаться "забытое" число.
Для встроенного может быть. Все зависит от цены программирования - на каком-то моменте окажется, что выгоднее сделать более дуракоустойчивый процессор, чем переплачивать за сверхнадежный код. |
Автор: | Hishnik [ Пн июл 06, 2009 01:16 ] |
Заголовок сообщения: | |
simne писал(а): Ну вообще-то виртуальная память на то и виртуальная, что для типичного современного процессора время обработки исключения измеряется в долях микросекунды, а время считывания/записи винта в лучшем случае в единицах миллисекунд, так что специальный флаг там погоды не делает, и многие не-х86 процессоры соответственно ничего подобного не имеют Это не отменяет принципиально различного назначения исключения, связанного с виртуальной памятью, и исключений, связанных с нарушениями прав доступа. В том же x86 существует целый класс исключений, после обработки которых команда, вызвавшая исключение, выполняется повторно. Подразумевается, что обработчик исключения принял меры к исправлению ошибочной ситуации и сделал ее исполнение возможным. Именно это поведение и обсуждается. simne писал(а): Для встроенного может быть. Все зависит от цены программирования - на каком-то моменте окажется, что выгоднее сделать более дуракоустойчивый процессор, чем переплачивать за сверхнадежный код.
Более дуракоустойчивый процессор потребуется, если непосредственно на нем кто-то будет проводить разработку. Тогда может оказаться полезной реализация механизма защиты памяти, чтобы проблемы в отлаживаемом приложении не угробили среду разработки. А вот сверхнадежный код для работы вовсе не нужен - достаточно просто работоспособного. Вообще, когда глубина стека в процессе выполнения кода устойчиво растет - это ненормально. И подкачка тут не спасает, а только маскирует проблему. |
Автор: | Kopa [ Пн июл 06, 2009 08:28 ] |
Заголовок сообщения: | |
Возможно E16 не совсем удачное название т.к. разработка Форт процессора в FPGA E16 есть у Brad Eckert:) |
Автор: | Hishnik [ Пн июл 06, 2009 12:53 ] |
Заголовок сообщения: | |
Kopa писал(а): Возможно E16 не совсем удачное название
т.к. разработка Форт процессора в FPGA E16 есть у Brad Eckert:) Букв латинского алфавита не так уж и много. Brad-у Eckert-у, видимо, не повезло |
Автор: | Kopa [ Пн июл 06, 2009 13:09 ] |
Заголовок сообщения: | |
Хищник писал(а): Kopa писал(а): Возможно E16 не совсем удачное название т.к. разработка Форт процессора в FPGA E16 есть у Brad Eckert:) Букв латинского алфавита не так уж и много. Brad-у Eckert-у, видимо, не повезло Не повезёт googlе если не переименовать, например, на EQ16 ( что тоже может с чем нибудь пересечься ) Например новость: Код: Разработчики оконного менеджера Enlightenment E16 решили изменить способ нумерации
релизов и вместо очередной версии 0.16.8.16 выпустили 1.0.0. В новом выпуске не отмечено значительных изменений, отмечается, что проект уже дозрел до изменения своего статуса Не думаю что информация о Форт процессоре E16 будет публиковаться в opennet.ru/opennews P.S. Букв, действительно, не так много в латинском алфавите и ограничивает выбор применения шаблона *Forth в именовании Форт систем. |
Автор: | вопрос [ Пн июл 06, 2009 13:17 ] |
Заголовок сообщения: | |
WingLion писал(а): вопрос писал(а): Мне показалось, что префикс обрабатывается отдельно это мечта ... программа сигнализирует Laughing непосредственно перед совершением ошибки и останавливается Поток команд обрабатывается непрерывно, и прервать исполнение загруженной очереди уже ничто не может. Прерывания обрабатываться будут (сейчас этого еще нет!) в момент исполнения команды NOP. хм... это хорошо или плохо? Это, может быть. ненадёжно, вот подвис процессор и никаким прерыванием его не вытащищь, если в цикле NOP не обнаружено сделать тогда уже 2 аналогичных процессора, раз они так мало занимают на кристалле, один - это этот, другой такой же. но принимает прерывания и всё, что может - подать другой код в очередь комманд, если сочтёт нужным ... |
Автор: | WingLion [ Пн июл 06, 2009 18:15 ] |
Заголовок сообщения: | |
вопрос писал(а): Это, может быть. ненадёжно, вот подвис процессор и никаким прерыванием его не вытащищь, если в цикле NOP не обнаружено
В данном случае "не обнаружен NOP в цикле" - означает, что процессор команды вообще не грузит, потому что NOP - это загрузка команд, и она появляется автоматически после того, как группа команд исполнена. A а всякая группа ограничена количеством бит в слове. |
Автор: | WingLion [ Пн июл 06, 2009 23:19 ] |
Заголовок сообщения: | |
Kopa писал(а): Возможно E16 не совсем удачное название
т.к. разработка Форт процессора в FPGA E16 есть у Brad Eckert:) E16 - это название модификации, так же, как Е32 и Е64, а название для процессора - Equinox Можно, конечно, и название модификации поправить до EQ16, как предложено, но что от этого изменится? Если прямо сейчас забить в поисковик "процессор equinox" - то он такое выдает, что волосы дыбом встают Впрочем, уже сейчас google мне эту тему третьим пунктом выдал по такому запросу. |
Автор: | simne [ Пн июл 06, 2009 23:31 ] |
Заголовок сообщения: | |
WingLion писал(а): Если прямо сейчас забить в поисковик "процессор equinox" - то он такое выдает, что волосы дыбом встают
А че, неплохие штуки выдает: особенно популярен некий музыкальный процессор, причем (а это идея!), который вроде еще и с SCSI интерфейсом Хотя может это он мне такое выдает.. Говорят, у гугла сейчас ранжировка ответов зависит от истории прошлых запросов, то есть он вроде учится и пытается предлагать именно то чего наиболее подходит пользователю |
Автор: | izvr [ Ср июл 08, 2009 00:56 ] |
Заголовок сообщения: | |
WingLion писал(а): проверка производиться должна на уровне стека - так, чтобы отлавливать состояния "на грани" - осталось 2 элемента запаса глубины - пора делать слив со дна в память. Добрался процесс почти до дна стека (еще 2 DROP-a и конец!) - пора делать подкачку из памяти.
Это надо понимать обсуждался интерфейс с оперативкой, а если совсем точно - расширение глубин стека в глубины РАМа? А потом плавно перешло к обсуждению виртуалки? Так и не дали Льву высказаться P.S. А насчет виртуалки окаянной(MMU) - так некоторые буржуины ее в виде сопроцессора реализуют (см. www.arm.com). Ой, и я туда же ;( |
Автор: | WingLion [ Ср июл 08, 2009 07:23 ] |
Заголовок сообщения: | |
Обсуждение параллельных вычислений вынесено в отдельный топик: http://fforum.winglion.ru/viewtopic.php?t=2191 |
Автор: | WingLion [ Ср июл 08, 2009 07:49 ] |
Заголовок сообщения: | |
izvr писал(а): Это надо понимать обсуждался интерфейс с оперативкой, а если совсем точно - расширение глубин стека в глубины РАМа?
началось то все с обсуждения ловли исключительных ситуаций, которые, как мне кажется, обрабатывать надо железно а не программно. Программно только подсказки железу, типа, "не обращать внимания на переполнение стека" или "а тут ловить попытку выхода за такие-то пределы про обращении к памяти..." и т.п. Тогда код, в конечном итоге, отлаживать будет проще, а программа будет иметь более гибкие возможности. Вместо того, чтобы контролировать каждый шаг программы, контролировать можно нечто более общее и более просто. На примере стека этот контроль вполне формализуется. Ловить переполнение/исчерпание надо далеко не всегда. А вот аппаратно поймать медленную утечку стека или памяти - это уже более интересно, как мне кажется. |
Страница 4 из 6 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |