The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..., opennews (??), 05-Ноя-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


42. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +7 +/–
Сообщение от Аноним (-), 05-Ноя-11, 19:09 
>> 64-разрядная сборка работает быстрее
> С чего бы это?

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

Не говоря о том что регистров в 64-битном режиме больше, поэтому в отличие от х86, где половина программы состоит из сохранения и восстановления регистров и всяких там пересчетов адресов при старте (режима относительной адресации у 32-битной х86 дряни тоже не было) - тут программа больше работает и меньше тягает туда-сюда стек, и код в произвольный адрез перебазируется просто копированием, без патчинга всей программы по немеряной таблице релокаций как это надо х86-му делать.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

46. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  –1 +/–
Сообщение от anonymous (??), 05-Ноя-11, 19:33 
>режима относительной адресации у 32-битной х86 дряни тоже не было

Приплыли.

Эффективные менеджеры атакуют? Только одна гастроль, проездом из Сколково?

Воообще то набор команд Intel x86_32 это самый сложный за всю историю процессоров, в нем есть практически все что придумал воспаленный мозг за период 1969-2011гг. И не только относительная адресация.

Со времен Klamanch ( Pentium 2) этот код видимый программистом вообще не имеет смысла, потому как сам микропроцессор скрыт от глаз программиста блоком перекодировки. Внутри P2 на самом деле RISC-подобный процессор, систему команд которого скрывают с секрете, а при выполнении "86" кода его на лету перекодируют и оптимизируют во внутренний код ( uops ).

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

Ну и со времен P2 тоже времени немало прошло, ситуация на данный момент такая что вместо микропроцессора у нас многомашинный комплекс с некоторым перекодировщиком, и что там на самом деле происходит как выбирабтся команды и какие режимы адресации можно только догадываться.

Ответить | Правка | Наверх | Cообщить модератору

62. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 05-Ноя-11, 21:37 
> Приплыли.

Всю ночь гребли, а лодку отвязать забыли?

> Эффективные менеджеры атакуют? Только одна гастроль, проездом из Сколково?

Не знаю, вам виднее.

> Воообще то набор команд Intel x86_32 это самый сложный за всю историю
> процессоров, в нем есть практически все что придумал воспаленный мозг за
> период 1969-2011гг. И не только относительная адресация.

К чему здесь этот маркетоидный буллшит? В x86-32 нет адресации относительно текущего места выполнения (относительно текущего значения program counter-а).Наследственная болячка x86. Поэтому в х86 программах есть такой костыльный лулз как большая таблица релокаций. Потому что программу просто так нельзя загрузить по иным адресам нежели было задумано изначально. В частности у x86-32 нет команд перехода на кусок кода адресованый относительно текущего места выполнения относительным смещением от этого места до нужного участка кода. Можно только абсолютный адрес ткнуть. Который имеет свойство меняться, что очень доставляет. Для того чтобы все-таки вгрузить программу в адреса отличные от дефолтных - загрузчик программ ОС читая программу до кучи разбирает таблицу релокаций (отдельная секция выполняемого файла) и на ходу патчит все адреса которые ссылаются на абсолютные адреса, пересчитывая все ссылки по абсолютному адресу под новый базовый адрес, отличный от исходного. Стоит ли говорить что фокусы типа ALSR при которых как раз программы грузят в разные адреса каждый раз, чтобы усложнить хакинг - тормозят загрузку этих самых программ, потому как приходится постоянно педалить огромные таблицы и на ходу хакать полпрограммы в памяти. В нормальных процессорах давно уже сделаны режимы адресации относительно текущего места выполнения. При этом не важно в какой адрес грузится программа - патчить ничего не надо: если сказано "от сих 60 байтов вперед" - при этом не важно какой там базовый адрес был.

> Со времен Klamanch ( Pentium 2) этот код видимый программистом вообще не
> имеет смысла, потому как сам микропроцессор скрыт от глаз программиста блоком перекодировки.

Капитан информирует что на самом деле, microcode ROM - это неотъемлимая часть CISC-процессора. Этот ROM разваливает сложные команды CISC в более простые RISC-образные субкоманды для относительно простых блоков выполнения. Так было даже в 8086, просто менее явно светилось наличие микрокода и он был не обновляемым. Обновляемым его сделали после парочки годных фэйлов с Pentium (первым). Где часть камней пришлось пустить под пресс и бесплатно заменять, потому что во первых вылезла ошибка вычислений, а во вторых - определенная последовательность байтов намертво вешала проц, поэтому даже самый бесправный юзер в операционке мог поставить колом все вокруг. Интел высрал гору кирпичей и где-то немного опосля сделал microcode ROM обновляемый (биос содержит эти файлики, также они иногда встречаются отдельно, Linux умеет их вгружать в проц, если они у вас есть). Поэтому часть ошибок дизайна стало можно чинить после выпуска проца и не пуская его под пресс. Но на самом деле microcode ROM придумал не интел, это почти стандартная часть дизайна CISC. Просто потому что сделать блоки выполнения в которые напрямую можно пхнуть сложные CISC команды - очень сложно. И багов в них будет немеряно. А поскольку все это в железе - сколько процов пойдет под пресс? Microcode ROM упрощает дело, переводя по таблице сложные команды в простые для куда более простых блоков, типа обычного простого ALU и прочих. Вроде были психи которые пробовали делать в своих процах декод CISC команд прямо в железе, без перекодирующего ROM, но они потерпели дружный FAIL в силу нетривиальности затеи и сложности блоков. И в итоге все такие давно самовыпилились.

> Внутри P2 на самом деле RISC-подобный процессор, систему команд которого
> скрывают с секрете, а при выполнении "86" кода его на лету
> перекодируют и оптимизируют во внутренний код ( uops ).

На самом деле - ничего нового там нет. Висит декодер, разваливающий (не без помощи microcode ROM) сложные CISC команды в RISC-подобные команды. RISC зачастую представляет собой то же самое, только декодер оторван, а упрощенный набор команд подается в блоки без преобразований через microcode ROM. Логично что ядро RISC априори проще ядра CISC. Потом дошло что можно в принципе пихать и побольше одинаковых блоков за декодер, так что за раз сможет выполняться и более одной команды.

Основная проблема всего этого: программам и компилерам не видно что там внутри. Поэтому оптимизация из очевидного действа превращается в то еще разгадывание ребусов архитектуры и укладывание костылей и подпорок.

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

На самом деле сглаживается оно в основном умным кешированием, так что стек первым делом оседает в кеше и не покидает его. Но это не отменяет того факта что даже так проц занимается глупой тасовкой регистров в стек и обратно (суммарный эффект от push + pop равно NOP, т.к. бесполезная служебная операция никак не связанная с реализацией логики программы). А вот х64 с его кучей регистров намного чаще может посчитать все вообще не лазя в стек. Там даже ABI построено так, что часть регистров - для передачи параметров в функцию, часть для локальных рассчетов, часть для возврата результата. На все хватает, в отличие от х86 уродца, который в этом месте обтасуется регистрами. Ну по крайней мере в типовых случаях. В том числе и поэтому часто дергаемые функции с 20 сложными параметрамми - плохая идея (если не хватит регистров - придется пушить в стек).

> Ну и со времен P2 тоже времени немало прошло, ситуация на данный
> момент такая что вместо микропроцессора у нас многомашинный комплекс с некоторым
> перекодировщиком, и что там на самом деле происходит как выбирабтся команды
> и какие режимы адресации можно только догадываться.

Наружу вывешивается система команд х86. И потому - не важно что там внутри, танцевать приходится по этим правилам. Воспользоваться преимуществами указанного комплекса, даже если б они были - нельзя. Потому что рукояток наружу нет. И если вы в системе команд х86 не можете адресоваться относительно текущего места кода, вы это не можете и все тут. Это ограничение системы команд, а как система команд внутри реализована - да какая разница вообще?! Вы все равно за пределы возможностей системы команд не прыгнете. В х64 это тупое упущение исправили, сделав наконец относительную адресацию, как во всех нормальных процах. Которую, блин, программы, компилеры и программеры могут явно юзать на свое благо. Поэтому если мы хотим сгененить position-independent code - мы наконец то можем это делать и без отсыла в немеряные таблицы релокаций! Алилуя!

Ответить | Правка | Наверх | Cообщить модератору

89. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Анон (?), 05-Ноя-11, 23:25 
Знаний по архитектуре микропроцессоров у меня маловато (надо было Таненбаума читать и др. литературу по этой теме), но все же кое что я понял. Спасибо за такие подробные разъяснения. :)
Ответить | Правка | Наверх | Cообщить модератору

91. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +17 +/–
Сообщение от Hety (??), 05-Ноя-11, 23:42 
Спасибо. Такие посты компенсируют месяц чтения комментов.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

102. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +5 +/–
Сообщение от Аноним (-), 06-Ноя-11, 01:19 
что за чушь про отсутствие команд относительной адресации в x86?
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

105. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +2 +/–
Сообщение от z (??), 06-Ноя-11, 01:44 
Ну "спец" же =) Вроде одни преумущества, но на практике 32-х битный (generic) код довольно часто почему-то быстрее 64х-битного: то ли лишний уровень в TLB даёт о себе знать, то ли префиксы кодманд и адресность становятся бутылочным горлышком для декодера - неизвестно, т.к. "спец" решил об этом умолчать =)
Ответить | Правка | Наверх | Cообщить модератору

111. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +2 +/–
Сообщение от Онон (?), 06-Ноя-11, 02:49 
майн гот! относительная адресация еще в 70ч бфла реализована на процессорах DEC - еще 30 лет назад они по гибкости переплевывали х86 уродов

Ответить | Правка | Наверх | Cообщить модератору

134. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 06-Ноя-11, 16:46 
> майн гот! относительная адресация еще в 70ч бфла реализована на процессорах DEC
> - еще 30 лет назад они по гибкости переплевывали х86 уродов

х86 в 32-битном режиме таскает за собой наследие ранних 80х. Например, почему интел не сделал нормальный набор регистров в 32-битном режиме - загадка природы. Так и был куцый уродец, пока не пришел АМД...

Ответить | Правка | Наверх | Cообщить модератору

159. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 07-Ноя-11, 01:45 
> х86 в 32-битном режиме таскает за собой наследие ранних 80х

Может быть потому что ia32 начали разрабатывать в этих ранних 80x? Вы об этом не задумывались?

Ответить | Правка | Наверх | Cообщить модератору

183. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 07-Ноя-11, 17:56 
> Может быть потому что ia32 начали разрабатывать в этих ранних 80x? Вы
> об этом не задумывались?

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

Ответить | Правка | Наверх | Cообщить модератору

136. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +1 +/–
Сообщение от Аноним (-), 06-Ноя-11, 17:21 
> Ну "спец" же =) Вроде одни преумущества, но на практике 32-х битный
> (generic) код довольно часто почему-то быстрее 64х-битного: то ли лишний уровень
> в TLB даёт о себе знать, то ли префиксы кодманд и адресность становятся
>  бутылочным горлышком для декодера - неизвестно,

Не думаю. Декодер успевает распихивать команды на кучи блоков, изображая "как-бы 8-ядерный" х86 и прочие гипертрединги, так что в результате роялит именно распределение нагрузки на блоки, которые находятся за ним. Поэтому врядли он является узким местом. Например, недавний тест фороникса очень недвусмысленно демонстрирует поведение бульдозера, при том это поведение формируется распределением нагрузки на блоки. Ну то-есть скорость целочисленных операций перестает существенно расти после того как закончатся неозадаченные целочисленные блоки, что ожидаемо, ну и так далее ;). Гипертрединг тоже похоже преследует цель догрузить блоки за декодером. На изображение полноценного честного ядра конечно остатков возможностей блоков не хватает, но свои 15-20% на сильно многопоточных случаях получить все-таки удается. С чего бы быть хоть какому-то приросту, если в декодер все уткнулось?

> т.к. "спец" решил об этом умолчать =)

Не, плюсов совсем без минусов не бывает. Еще и код и данные жирнее, значит реже будут в кеш попадать целиком. С другой стороны, кеши нынче у х64 процов весьма жирные и наврядли это сильная проблема в большинстве случаев. И в целом по шинам надо передавать несколько больше данных, и это может упереться и в оперативку и в размер кеша. Ну и оперативку нынче понапихали многоканальную, с нехилым бандвизом. Наверное не для красоты.

Понятно что в целом есть возможности проиграть 32-битному коду в некоторых случаях. С другой стороны, годный алгоритм критичный к скорости - должен быть не сильно жирным и целиком влезать в кеш, а когда это случилось, наличие 64-битной арифметики, кучи регистров и гарантированное наличие SSE2 вполне могут обеспечить победу.

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

178. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от z (??), 07-Ноя-11, 17:20 
>Декодер успевает распихивать команды на кучи блоков
>Поэтому врядли он является узким местом

Агнер Фог с вами несогласен, определённо, ознакомтесь с его "The microarchitecture of Intel, AMD and VIA CPUs"

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

x86_64 это ещё и x86_32, поэтому при прочих равных кеша в 32-х битном режиме больше

>вполне могут

лишь при наличии специфических вычислений, во всех остальных случаях - 32бита как правило быстрее

Ответить | Правка | Наверх | Cообщить модератору

181. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 07-Ноя-11, 17:29 
> лишь при наличии специфических вычислений, во всех остальных случаях - 32бита как
> правило быстрее

Практики против, пересборка почти любого софта под нативный x86_64 даёт прирост производительности (меньше нагрузка на CPU).

Ответить | Правка | Наверх | Cообщить модератору

202. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от z (??), 08-Ноя-11, 15:05 
>Практики против, пересборка почти любого софта под нативный x86_64 даёт прирост производительности (меньше нагрузка на CPU)

не вижу доказательств, - стоит ждать? :)


Ответить | Правка | Наверх | Cообщить модератору

203. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 08-Ноя-11, 15:05 
> не вижу доказательств, - стоит ждать? :)

Зачем ждать? gcc -m32, gcc -m64, и вперёд.

Ответить | Правка | Наверх | Cообщить модератору

204. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 08-Ноя-11, 15:14 
> Практики против, пересборка почти любого софта под нативный x86_64 даёт прирост производительности
> (меньше нагрузка на CPU).

core 2, основаные на conroe и сотоварищах, в x64 были медленее чем x86. Особености декодера и криворукость разрабов в amd, из-за чего в среднем длина комманды в x64 больше чем в x86 благодаря куче всяких новых префиксов.

Так что не надо тут ляля.

Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

206. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 08-Ноя-11, 15:19 
> core 2, основаные на conroe и сотоварищах, в x64 были медленее чем
> x86

ЛПП отдельных продуктов отдельных вендоров мне мало интересны.
В сумме у меня на всех площадках прирост есть, он не может не есть.
Банальная пересборка пыха под x86-64 на хостингах высвобождает до 15% ресурсов.

Ответить | Правка | Наверх | Cообщить модератору

231. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 15-Ноя-11, 02:24 
> среднем длина комманды в x64 больше чем в x86

А еще там адреса 64-битные - потоки данных в среднем больше. Но нынче и оперативка стала многоканальной, а кеши большими. Поэтому указанный факт изрядно нивелирован. Вон GPU вообще например успевают пачку VLIW-ов огроменными командами прокормить, и ничего, никто не бухтит что у VLIW команды слишком большие.

Ответить | Правка | К родителю #204 | Наверх | Cообщить модератору

236. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 15-Ноя-11, 12:15 
> Агнер Фог с вами несогласен, определённо, ознакомтесь с его "The microarchitecture of
> Intel, AMD and VIA CPUs"

Реально эпичнейшая дока! Хоть частично и основанная на малопроверенных фактах и потому воспринимаемая с осторожностью. Те кто верит в инопланетян и неизвестно что работающее в проце - срочно читать!

Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

138. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 06-Ноя-11, 17:40 
> что за чушь про отсутствие команд относительной адресации в x86?

Да нет никакой чуши - у x86-32 нет адресации данных относительно program counter.

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

153. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +1 +/–
Сообщение от anonymous (??), 06-Ноя-11, 19:38 
>> что за чушь про отсутствие команд относительной адресации в x86?
> Да нет никакой чуши - у x86-32 нет адресации данных относительно program
> counter.

Еще один.

У них любая адресация идет относительно БАЗОВОГО СЕГМЕНТНОГО РЕГИСТРА.
У интела вообще вся адресация относительная.
Если честно, просто руки опускаются - неужели все ТАК ПЛОХО.

Ответить | Правка | Наверх | Cообщить модератору

179. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от z (??), 07-Ноя-11, 17:22 
>Еще один.

верующий

Ответить | Правка | Наверх | Cообщить модератору

186. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 07-Ноя-11, 20:24 
> Еще один.
> У них любая адресация идет относительно БАЗОВОГО СЕГМЕНТНОГО РЕГИСТРА.

А это СОВСЕМ НЕ ТО. Когда говорят о относительной адресации, как правило имеют в виду адерсацию относительно текущего места выполнения (смещение относительно значения Program Counter в данный момент).

Зачем именно так? А чтобы можно было писать позиционно-независимые программы. Которые не делают _никаких_ допущений о том в каких адресах они работают. В случае сегментных регистров - без допущений уже не выходит, да? Федот, да не тот.

> У интела вообще вся адресация относительная.

У интела вообще вся адресация с сегментами - одно большое извращение. Плоская модель памяти рулит. Хотя у некоторых процессоров бывают и режимы явно ориентированные на работу с массивами и прочими, по типу mov R4, [R5+30], это по крайней мере менее похабно и более логично выглядит, но относительной адресацией в ее обычном понимании - не является.

> Если честно, просто руки опускаются - неужели все ТАК ПЛОХО.

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

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

205. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от z (??), 08-Ноя-11, 15:15 
Сплошной поток мантр и заблуждений, даже читать до конца не хочется

Условные/безусловные переходы могут быть относительными, даже имеются короткие формы в случае близких(-128/+127) переходов, call инструкция с опкодом E8 тоже производит вызов по относительному смещению - это любой ассемблерщик знает, которым вы, и это очевидно, не являетесь

Ответить | Правка | Наверх | Cообщить модератору

207. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 08-Ноя-11, 15:21 
> Сплошной поток мантр и заблуждений, даже читать до конца не хочется

Давайте прервём этот поток:
У x86 ЕСТЬ относительная адресация по смещению от EIP, или НЕТ?
Вот и всё.

Ответить | Правка | Наверх | Cообщить модератору

212. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от dq0s4y71 (??), 09-Ноя-11, 13:44 
Так какбе всегда было:

> INTEL 80286 PROGRAMMER'S REFERENCE MANUAL 1987
> ...
> 3.6.1.1  Jump Instruction
> ...
> Direct JMP within the current code segment. A direct JMP that transfers control to a target location within the current code segment uses a relative displacement value contained in the instruction. This can be either a 16-bit value or an 8-bit value sign extended to 16 bits. The processor forms an effective address by adding this relative displacement to the address contained in IP. IP refers to the next instruction when the additions are performed.

Здесь оно называется "прямым переходом", но по сути это то, о чём говорил Аноним - относительное смещение _добавляется_ к IP.

Ответить | Правка | Наверх | Cообщить модератору

214. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 09-Ноя-11, 14:26 
Блин, как же всё плохо. Direct JMP - это ни фига не "относительная адресация". Это регистровая операция сложения ADD IP/EIP,imm.
Ответить | Правка | Наверх | Cообщить модератору

192. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от alex (??), 07-Ноя-11, 22:02 
>>> что за чушь про отсутствие команд относительной адресации в x86?
>> Да нет никакой чуши - у x86-32 нет адресации данных относительно program
>> counter.
> Еще один.
> У них любая адресация идет относительно БАЗОВОГО СЕГМЕНТНОГО РЕГИСТРА.
> У интела вообще вся адресация относительная.
> Если честно, просто руки опускаются - неужели все ТАК ПЛОХО.

ВСЕ ГОРАЗДО ХУЖЕ чем здесь кажется. Еще 3-5 лет таких инженеров повыпускают и нас даже завоевывать не нужно будет - они и так все всем отдадут со 100% уверенностью что так было всегда. :-(

Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

113. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  –4 +/–
Сообщение от anonymous (??), 06-Ноя-11, 03:31 
Я тебе сказал, что еще в П2 УЖЕ НИКТО НЕ ЗНАЕТ КАК НА САМОМ ДЕЛЕ РАБОТАЕТ ПРОЦЕССОР.

Кажется, что он что то адресует, что то записывает, что то читает. Ходят слухи (СЛУХИ!) что исполнение команд организовано по типу RISC. Слухи. На основе маркетоидного бреда.

Может быть там RISC. Может не RISC а какой то хитрый VLIW, или 100 нод 4 битного транспьютерного хренпойми как соеждиненного между собой массива. Почему нет? Этого НИКТО из не посвященных не знает.

Сейчас ни у кого нет П2.

Время прошло.

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

Так что, фантазируй что угодно, а факты вещь упрямая.

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

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

118. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +4 +/–
Сообщение от sasha (??), 06-Ноя-11, 11:27 
> Сейчас ни у кого нет П2.

Прикинь у меня есть )))

Ответить | Правка | Наверх | Cообщить модератору

122. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от rpisarev (?), 06-Ноя-11, 12:59 
Используем на работе П2 и в ноуте и на "сервере" (вариации убунт)
Ответить | Правка | Наверх | Cообщить модератору

141. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +2 +/–
Сообщение от Аноним (-), 06-Ноя-11, 18:32 
> Я тебе сказал, что еще в П2 УЖЕ НИКТО НЕ ЗНАЕТ КАК
> НА САМОМ ДЕЛЕ РАБОТАЕТ ПРОЦЕССОР.

Да какая нахрен разница, как он там внутри работает? Снаружи то с ним можно работать лишь с тем набором команд (и ограничениями оного) которые вывешены нам. И если в этом наборе команд чего-то нет, этим не удастся воспользоваться. Представьте себе что у вас есть авто. У него замечательный двигатель, все дела. Только вот нет руля. Поэтому ездить можно только вперед и назад. Сильно ли вас при этом волнует тип двигателя? Какая разница, электрический он, дизельный или бензиновый? На возможность совершения поворотов это вообще не влияет.

> Кажется, что он что то адресует, что то записывает, что то читает.
> Ходят слухи (СЛУХИ!) что исполнение команд организовано по типу RISC. Слухи.
> На основе маркетоидного бреда.

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

> Может быть там RISC. Может не RISC а какой то хитрый VLIW,
> или 100 нод 4 битного транспьютерного хренпойми как соеждиненного между собой
> массива. Почему нет? Этого НИКТО из не посвященных не знает.

Да опять же - это по-фи-гу. Наружу вывешен интерфейс "я тут типа х86 процессор". Все взаимодействие - через него. Если через этот интерфейс чего-то сделать нельзя, очевидно, какой бы крутой бэкэнд там ни был, мы не сможем его проинструктировать в нужном виде. И он не сможет сделать нужную операцию независимо от своей крутизны. Нужной рукоятки то нет.

> Сейчас ни у кого нет П2. Время прошло.

И что? Если уж на то пошло, коры - это внучек ядра пентиум3. Когда Netburst ака пень4 себя дискредитировал и вчистую проиграл атлонам, из загашников был раскопан старый добрый пентиум 3. После вдувания порции стероидов это обозвали кором, и до сих пор обзывают. А изменения в основном количественные. Потоньше процесс? Побольше блоков выполнения воткнем! Побольше кешатины. И т.д. - и вот уже немолодой дизайн разгоняется до космических скоростей. А чего б ему не разогнаться, если блоков донавесили, частоты задрали, кеша целые мегабайты воткнули?

> Что там сейчас - это лютый писец, я уверен даже имея послойно
> снятую топологию уже не разобраться за лет 20,

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

> а к тому времени они выпустят еще более сложную хрень. Просто посчитай какую площадь
> на бумаге займет чертеж одного слоя кристалла i5 2500.

К чему эта "умная" фраза вообще?

> Так что, фантазируй что угодно, а факты вещь упрямая.

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

> Кстати если уж так сильно чешется, не подскажешь команду как там прыжок
> на небольшие расстояния делается? Ась? Относительный вы наш.

Там уже подсказали, вплоть до опкода. Только вот:
1) Это только на малые дистанции. Не уложились? Будет абсолютный адрес (и его пересчет). У других архитектур лимиты бывают и больше. Но формально, камень в огород принимается.
2) Но все это не отменяет отсутствия команд для загрузки данных по смещению относительно program counter. Ну нету их у х86. При этом не важно какой там пепелац за декодером: его нельзя проинструктировать сделать это на уровне набора команд. Глупо, но факт.

Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

152. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +1 +/–
Сообщение от anonymous (??), 06-Ноя-11, 19:25 
Еще раз.

Ты сказал, что x86_64 лучше чем i386(i686) потому что:

- есть относительная адрасация (в отличие от).
- больший пул регистров и сами регистры длиннее, а так же появились исполнительные устройства которве изначально спроектированы для оаботы с 64 битными данными (предположим это на саомм деле так, хотя какая разница 1 устройство с огромной площадью за такт умножающее 2 64 битных числа или 2 утсройства с 1/4 площадью делающих то же за 2 такта но тактируемые в 2 раза чаще)

Со вторым спорить не стал, хотя там есть один подводный камень - вся радость увеличения регистрового пула только писателям компиляторов. Задача раскидывания переменных по регистрам она порядка NP, решается оптимально толко полным перебором, и если железо поддерживает больше регистров то это немного сглаживает принципиальную неоптимальность АЛГОРИТМА ОПРИМИЗАЦИИ КОМПИЛЯТОРА. К железу и скорости выполнения это никак не относится. Но факт есть - если больше регистров, то программы будут быстрее выполняться. Поправка только - это не недостаток архитектуры i3(6)86, а недоразвитость теории алгоритмов и компиляторов.

Но тут появилась 'относительная адресация'. Все, финиш.

В 4004 и ранних вариантах логики в программируемых калькуляторах еще можно было о чем то говорить, но СЕЙЧАС? Это что, троллинг такой?

Относительная адресация говорит об одном - что у этого процессора в отличие от предыдущих
есть еще один сумматор, который на лету добавляет к адресу содержимое другого регистра. Любого. Этим изобретением гордились в 60 года, "... и это еще не все, наш микропроцессор не только стирает и раскладывает носки по парам, но и имеет - вы только представьте - относительную адресацию ! Наши инженеры добавили еще дно уникальное устройство сложения, теперь для часто упортебляемой комбинации вы можете сразу выбрать смещение из кода операции и ОДНОВРЕМЕННО сложить с базовым регистром, ОТНОСИТЕЛЬНО которого вы и адресуетесь"

Считаем.

Таблица страниц - 1 сложение с маскированием не считая проверки флагов и прочее.
Нахождение рального адреса путем суммирования базового регистра и смещения - еще 1.

Итого - Любая адресация у интела ОТНОСИТЕЛЬНАЯ. Причем минимум ДАВЖДЫ ОТНОСИТЕЛЬНАЯ Любая. Из за сегментных регистров, и тем более таблиц виртуальной памяти MMU.

Более того, есть еще и ТРЕТИЙ УРОВЕНЬ по пути к физичемкому регистру - есть специальные коды операций, в которых под 3 битное поле регистра, ОТНОСИТЕЛЬНО которого идет выборка данных, эдакий "аппаратный ускоритель для доступа к массивам и структурам по смещению от их начала". Там адресация IP не предусмотрена. А ЗАЧЕМ нам адресовать в коде чтото относительно регистра программного счетчика? Мы уже не Гарвардскую архитектуру имеем? У нас что, допотопная Лента Тьюринга? Мы пишем самомодифицирующийся код который на лету меняет сам себя? Зачем выбирать данные в трехуровневой сегментноф стековой машине с физически разделенной памятью команд и данных отностиельно команд?

Итог - любой интеловский процессор имеет минимум 2 кратно относительную адресацию. Двухкратно, а для некоторых случаем и трехкратную.

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

Ответить | Правка | Наверх | Cообщить модератору

193. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 07-Ноя-11, 22:15 
> Еще раз.
> Ты сказал, что x86_64 лучше чем i386(i686) потому что:
> - есть относительная адрасация (в отличие от).

Да. Правда про выполнение я приврал - там все-таки номинально относительная адресация есть. Тупая (маленький диапазон смещений), что делает ее трудноюзабельной, но номинально я все-таки не прав. А кроме этого есть еще работа с данными. А вот с этим у х86 все еще хуже. Для тех кто тупит, поясняю: общепринято понимать под относительной адресацией адресацию по смещению относительно текущего значения program counter. По уму должно быть реализовн и для кода и для доступа к данным, иначе без диких костылей в позиционно-независимой программе не обойтись. Особенно смешно с учетом того что в современных реалиях очень желательно чтобы весь код такой и был, чтобы ALSR можно было делать просто и быстро, на радость хакерам (брутфорсить 2^64 адресов, особенно по сети - прикольное занятие).

> но тактируемые в 2 раза чаще)

Тактируется оно одинаково. А огромный там в основном кеш. Сомнительно что замена 32-битных ALU на 64-битные сильно меняет картину.

> Со вторым спорить не стал, хотя там есть один подводный камень -
> вся радость увеличения регистрового пула только писателям компиляторов.

Да в общем то и програмеру, если ему приперло вот в именно этой пяди кода отыграть максимум, так что до асма снизошли - трах с полутора неравноправными регистрами х86 и их постоянным пушпопом совершенно не в кассу. А в кучке 64-битных регистров многое можно посчитать и без пхания промежуточных результатов в стек. В операциях регистр-регистр тормозить просто нечему, так что в лучшем случае регистровая математика пойдет на полной скорости которую вообще в принципе способен развить проц. А х86 неизбежно тормознется лишними пушпопами, которые как ни крути лишние команды, подлежащие выполнению + лишние доступы в память, хотя-бы в кеш. Вариант когда все удалось сделать чисто на регистрах - как правило самый ядреный. В основном потому что процу все регистры доступны в пределах того же такта и без дополнительных условий и оговорок.

> Задача раскидывания переменных по регистрам она порядка NP,
> решается оптимально толко полным перебором,

Теория это здорово, но на практике достаточно посмотреть на то чем отличается х86 ABI от x64 ABI и прикинуть что на х64 вызов типовой функции с 1-2 параметрами и 1 результатом на выход выглядит в виде асма явно менее уныло чем пачка PUSH всего и вся а потом POP всего и вся на х86 ;)

> и если железо поддерживает больше регистров то это немного сглаживает принципиальную
> неоптимальность АЛГОРИТМА ОПРИМИЗАЦИИ КОМПИЛЯТОРА.

Избыточные PUSH + POP не может быть оптимальным, т.к. это не часть логики программы а лишь технический костыль в ситуации когда "пороху^W регистров не хватило". Все переменные программы заведомо не влезут в куцые регистры х86.

Кстати в целом для компилеров (и програмеров :D) идеальным вариантом был бы проц с бесконечным числом регистров. Тогда можно засунуть практически все переменные в регистры и крайне быстро с ними всеми работать, вообще никогда не сохраняя в стек ничего. Правда,  поскольку бесконечное число регистров сделать не получается, компилер вынужденно укладывается в тот бюджт который есть. Чем больше регистров - тем ближе к идеалу, когда все переменные максимально быстрые, а стек вообще насиловать не надо.

> К железу и скорости выполнения это никак не относится.

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

> Но факт есть - если больше регистров, то программы будут быстрее выполняться.
> Поправка только - это не недостаток архитектуры i3(6)86, а недоразвитость
> теории алгоритмов и компиляторов.

Не, извини, дяденька, здравый смысл подсказывает, что если в алгоритме есть 10 переменных с которыми хочется одновременно делать интенсивно математику, хорошо если все 10 попадут в 10 независимых регистров, немедленно доступных процу на том же такте и допускающих математические операции. Тогда с ними удастся поработать быстро и без изгалений. Лобовыми математическими операциями с регистрами. А если регистров будет меньше, придется совершенно непроизводительно тасовать переменные между стеком и регистрами по причине "на всех регистров не хватило". Лишние пушпопы ну совсем никак не могут производительность добавить. На х86 компилеры усираются, пытаясь впихнуть в эту куцую хрень ну хоть чего нибудь. Оптимально раскидывать полтора регистра? Хаха, смешно. На х86 их постоянно приходится "оптимально" сливать в стек и доставать обратно. Чтобы вообще иметь возможность хоть чего-то считать. Ибо если регистр уже занят ценным промежуточным результатом, считать в нем что-то еще без потери результата уже как-то не получится, и надо его сохранить, да?

> Но тут появилась 'относительная адресация'. Все, финиш.

Ага, вот только чей?

> В 4004 и ранних вариантах логики в программируемых калькуляторах еще можно было
> о чем то говорить, но СЕЙЧАС? Это что, троллинг такой?

Архитектура системы команд х86 настолько уныла что вполне заслуживает быть обтролленой. Пережитки идиотизмов чуть ли не времен 8080 лезут из всех щелей. Один из таковых - куцый набор регистров. Все более современные процы давно уже сделали выводы о том как компилерам и програмерам лучше. Ну а интел как обычно.

> Относительная адресация говорит об одном - что у этого процессора в отличие
> от предыдущих
> есть еще один сумматор, который на лету добавляет к адресу содержимое другого
> регистра. Любого.

Спасибо, капитан. Только не "любого" а "program counter", а то что вы упоминаете - это индексированный доступ. А относительная адресация нужна затем чтобы можно было адресовать данные и код относительно текущего места выполнения, сделав блок кода некоей полностью самодостаточной сущностью в памяти. Тогда его просто будет в память вгрузить и просто перенести в другие адреса, в идеальном случае - тупым копированием/загрузкой в желаемое место в адресах. В случае program counter EPIC WIN состоит в том что в командах кодируется только относительное смещение, а программе не надо вообще ничего знать о том в каких вообще адресах происходит дело. Ну, program counter при выполнении неизбежно фигурирует и актуализуется, потому что иначе программа бы не работала. А вот о других регистрах этого не скажешь. А то что вы расписали - это скорее индексированный доступ, но это совсем не то. Потому что базу индекса надо явно задавать где-то. А в случае program counter "база" сама себя задает, и код генерить не сложно (указать "от сих на 60 байтов вперед" - невелика наука) ;)

> Этим изобретением гордились в 60 года, "...

Да, уже тогда некоторые господа придумали кое-что получше чем уродец на костылях с полутора куцыми регистрами. А интел настолько ушибся на своем 8080 и потом 8086, что так и таскал этот куцый набор регистров, чтобы было похоже на выпердыши конца 70-х и начала 80-х прошлого столетия и дальше :))).

> адресацию ! Наши инженеры добавили еще дно уникальное устройство сложения, теперь
> для часто упортебляемой комбинации вы можете сразу выбрать смещение из кода
> операции и ОДНОВРЕМЕННО сложить с базовым регистром, ОТНОСИТЕЛЬНО которого вы и
> адресуетесь"

Ну так в интеле почему-то это не осилили. Только в амд64 появилось.

> Итого - Любая адресация у интела ОТНОСИТЕЛЬНАЯ. Причем минимум ДАВЖДЫ ОТНОСИТЕЛЬНАЯ Любая.
> Из за сегментных регистров, и тем более таблиц виртуальной памяти MMU.

Ага, если не считать такой мелочи что
1) Сегментные регистры кто-то должен явно программировать, в отличие от program counter'а, который актуален "by design".
2) Обычная программа в ring3 вообще ничего не знает ни о каком paging ;)

[del]
> адресация IP не предусмотрена. А ЗАЧЕМ нам адресовать в коде чтото
> относительно регистра программного счетчика?

У него есть одно важное свойство: program counter актуализует себя сам, естественными методами, без заботы программы об этом. Если программа адресуется относительно него - ее можно в любой адрес запихнуть, а она не заметит разницы. Потому что для ее запуска всяко управление будет подано на старт, а потом PC сам же себя и апдейтит. А вот всякие там другие регистры таким полезным свойством не обладают, требуя к себе явного внимания и указания правильной базы в программе :P. Это не относительная а индексированная адресация получается. Только вот базовый адрес надо явно задавать, и программа должна это явно знать, поэтому ни о каком свободном переезде по адресам спич не идет.

> Мы уже не Гарвардскую архитектуру имеем?

Epic fail! В гарвардце такое как раз и было бы невозможно. У совсем злостного гарвардца адресные пространства кода и данных различны, поэтому program counter (описывающий адрес с точки зрения кода) не имеет физического смысла применительно к адресам в пространстве данных. Поэтому в 100% трушном гарвардце относительная адресация в ее обычном виде - а это вообще как? Другое дело что чистокровные гарвардцы по этому поводу довольно мучительны в програминге. Даже сама по себе идея "вгрузим бинарь с диска!" очень плохо ложится на парадигму гарвардца с четким разделением кода и данных. Начинаются всякие костыли "а давайте к коду все-таки можно будет обращаться как к данным?" и прочие веселости.

> У нас что, допотопная Лента Тьюринга? Мы пишем самомодифицирующийся код который
> на лету меняет сам себя? Зачем выбирать данные в трехуровневой сегментноф
> стековой машине с физически разделенной памятью команд и данных отностиельно команд?

Простейший пример зачем это надо я привел: допустим простая, быстрая и безгеморная реализация ALSR.

> Итог - любой интеловский процессор имеет минимум 2 кратно относительную адресацию. Двухкратно,
> а для некоторых случаем и трехкратную.

Агащаз. Федот да не тот. Скорее, это просто индексированная адресация. Только вот она ни разу не помогает писать программу не зависящую от адресов.

> И уж совершенно ненусветная глупость говорить что это как то ускоряет или
> замедляет, с чего собственно началось.

Костылинг который приходится для х86 по этому поводу проводить - определенно замедляет процесс старта программы: при нужде передвинуть программу в новые адреса - патчится все что нельзя заадресовать относительным смещением, а можно только указанием конкретных адресов.

Ответить | Правка | Наверх | Cообщить модератору

198. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  –1 +/–
Сообщение от Aleksey Salow (ok), 08-Ноя-11, 00:10 
> Простейший пример зачем это надо я привел: допустим простая, быстрая и безгеморная
> реализация ALSR.

Во-первых не ALSR, а ASLR (Address Space Layout Randomization), а во-вторых я таки понял зачем вам адресация относительно eip.

Так вот, сам по себе ASLR это такой необходимый костыль из-за использования flat memory model. Вы можете записать что угодно в память, а потом передать туда управление. Та security model которую проектировали для PM в 286+ делала использования ASLR банально не нужным т.к. модификацию сегментов кода можно ограничить где-то на ring0 вместе с vmm, планировщиком и обработчиками исключения. Всё остальное (дрова, системные сервисы, юзерленд) крутить на более низких уровнях.

Ответить | Правка | Наверх | Cообщить модератору

232. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 15-Ноя-11, 02:47 
> Во-первых не ALSR, а ASLR (Address Space Layout Randomization), а во-вторых я
> таки понял зачем вам адресация относительно eip.

Затем чтобы грузить программу в произвольный адрес и не патчить потом полпрограммы, очевидно.

> Так вот, сам по себе ASLR это такой необходимый костыль из-за использования
> flat memory model.

У этой самой flat memory model при наличии MMU как бы есть страницы и есть разные права на оные, из которых делается все что угодно. Из страниц и их атрибутов можно сэмулировать сегменты. Из сегментов страничная память не эмулируется. Вывод: MMU с страничной адресацией - это суперсет, а не subset технологий. Это шаг вперед. И линейная адресация, и возможность защиты памяти программ друг от друга и ОС от программ, и виртуальная память. Все и сразу.

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

На самом деле это ниоткуда не следует: все от атрибутов страниц зависит. NX бит - всего лишь логичное доразвитие идеи MMU и страничной адресации. А оно даже без NX бита как минимум вполне справлялось с изоляцией ОС от процессов и процессов друг от друга.

> Та security model которую проектировали для PM
> в 286+ делала использования ASLR банально не нужным

ASLR не замена NX бита. А дополнение к оному. И да, я не вижу чем защита памяти через сегменты лучше защиты памяти через MMU и атрибуты страниц. MMU + атрибуты страниц может изобразить любой мыслимый сегмент с гранулярностью равной размеру страницы. А вот обратный вариант не катит.

> т.к. модификацию сегментов кода можно ограничить где-то на ring0 вместе
> с vmm, планировщиком и  обработчиками исключения.

А что не дает сделать то же самое с MMU и атрибутами страниц? Попробуйте из ring3 сунуться в память операционки или другого процесса влобовую, а не через услуги ОС, расскажите как получилось. Своп кстати является "штатным" исключением - если нужной страницы нет, случается эксепшн и его обработчик должен обеспечить догрузку с диска нужной страницы до возобновления работы задачи. А потом обработчик вернет состояние проца в вид "как было" и задача не узнает что оказывается был какой-то там page fault вообще :)))

> Всё остальное (дрова, системные сервисы, юзерленд) крутить
> на более низких уровнях.

Внезапно, деление на кернел и юзер ничего такого не запрещает. Можно даже писать user-mode драйвер, который для того чтобы выполнить некое действие будет просить привилегированный кусок ядра отработать ему опасную операцию. Для этого достаточно 2 уровней, юзер и система. Больше - в принципе конечно лучше, но вот исторически все как-то забили на эту фичу х86 и дружно юзали ring0 и ring3, тем более что у других процов есть эквиваленты оных, что позволяет проще портировать операционку на другие процессоры ("kernel mode" и "user mode" в общем случае).

Ответить | Правка | Наверх | Cообщить модератору

234. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 15-Ноя-11, 05:15 
>> Так вот, сам по себе ASLR это такой необходимый костыль из-за использования
>> flat memory model.
> У этой самой flat memory model при наличии MMU как бы есть
> страницы и есть разные права на оные, из которых делается все
> что угодно.

Фигня в том что страничная адресация это совершенно другой уровень управления памятью. О то что есть какие-то страницы приложения знать не обязательно. А сегментное разделение это логическая структура приложения.

> Из страниц и их атрибутов можно сэмулировать сегменты. Из
> сегментов страничная память не эмулируется.

Ещё раз, сегменты и страницы это совершенно различные уровни абстракций.

> Вывод: MMU с страничной адресацией -
> это суперсет, а не subset технологий. Это шаг вперед. И линейная
> адресация, и возможность защиты памяти программ друг от друга и ОС
> от программ, и виртуальная память. Все и сразу.

Защита через сегменты появилась в 82-м году, работает и не пробивается. NX bit - четверь века спустя и, по сути, не является гарантированым решением проблемы. Такой прямо мегаскачок :)

>> Та security model которую проектировали для PM
>> в 286+ делала использования ASLR банально не нужным
> ASLR не замена NX бита. А дополнение к оному. И да, я
> не вижу чем защита памяти через сегменты лучше защиты памяти через
> MMU и атрибуты страниц.

Ну что я могу сказать. Лучше тем что она работала ещё когда вас в проекте не было, в отличии от.

> Своп кстати
> является "штатным" исключением - если нужной страницы нет, случается эксепшн и
> его обработчик должен обеспечить догрузку с диска нужной страницы до возобновления
> работы задачи. А потом обработчик вернет состояние проца в вид "как
> было" и задача не узнает что оказывается был какой-то там page
> fault вообще :)))

Это к чему? Решили блеснуть знаниями? Какие ещё исключения знаете? :)

> Внезапно, деление на кернел и юзер ничего такого не запрещает.

Ужас. Показываю на пальцах. Пробили вы драйвер сетевухи. В совеременных осях вы сразу оказываетесь в ring0 и можете делать что угодно, а при нормальной реализации защиты вы будете сидеть в ring1/2 и нихрена делать не можете.

Ответить | Правка | Наверх | Cообщить модератору

235. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 15-Ноя-11, 07:25 
> Защита через сегменты появилась в 82-м году, работает и не пробивается. NX
> bit - четверь века спустя и, по сути, не является гарантированым
> решением проблемы. Такой прямо мегаскачок :)
> Ну что я могу сказать. Лучше тем что она работала ещё когда
> вас в проекте не было, в отличии от.

Стеклодувы появились в 200 году до нашей эры. Где они? Почему они больше не требуются в массовом производстве?

К слову говоря: сегментная защита имеет _массу_ недостатков. "Работает и не пробивается" он только в том случае, как вы правильно заметили, если сегменты не пересекаются. Попробуйте увязать сегментную защиту с page sharing - и быстро поймете, что мир не такой уж и розовый. Запустить 100500 копий одного процесса в Linux без существенной потери памяти? Да легко. А в винде (которая выросла из сегментной защиты)?

> Ужас. Показываю на пальцах. Пробили вы драйвер сетевухи. В совеременных осях вы
> сразу оказываетесь в ring0 и можете делать что угодно, а при
> нормальной реализации защиты вы будете сидеть в ring1/2 и нихрена делать
> не можете.

Достаточно того, что ring1/2 могут писать в память ring3. Далее с системой можно сотворить что угодно, в т.ч. и рута получить. А с рута уйти в ring0 - как делать нефиг, достаточно подгрузить ring0-модуль. Так что бестолково.

Ответить | Правка | Наверх | Cообщить модератору

237. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 15-Ноя-11, 13:17 
> Попробуйте увязать сегментную защиту с page sharing - и
> быстро поймете, что мир не такой уж и розовый.

Да лехко. Страничная адресация это совершенно другой уровень абстракции.

> А в винде (которая выросла из сегментной защиты)?

Сегменты использовала только 3.x винда, если не ошибаюсь. NT их не использовала из-за того что взлетать нужно было на куче архитектур на старте.

> Достаточно того, что ring1/2 могут писать в память ring3. Далее с системой
> можно сотворить что угодно, в т.ч. и рута получить. А с
> рута уйти в ring0 - как делать нефиг, достаточно подгрузить ring0-модуль.

ring1/2 может писать куда им разрешили. При грамотном разделении какой-нить драйвер сможет насрать только в какой-нить shared buffer, что не особо критично.

Ответить | Правка | Наверх | Cообщить модератору

238. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 15-Ноя-11, 13:41 
>> Попробуйте увязать сегментную защиту с page sharing - и
>> быстро поймете, что мир не такой уж и розовый.
> Да лехко. Страничная адресация это совершенно другой уровень абстракции.

Серьёзно? Потрудитесь описать механизм, и объяснить, как оно после этого будет коррелировать с Вашим "сегменты не пересекаются"?

Ответить | Правка | К родителю #237 | Наверх | Cообщить модератору

239. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 15-Ноя-11, 14:33 
>>> Попробуйте увязать сегментную защиту с page sharing - и
>>> быстро поймете, что мир не такой уж и розовый.
>> Да лехко. Страничная адресация это совершенно другой уровень абстракции.
> Серьёзно? Потрудитесь описать механизм, и объяснить, как оно после этого будет коррелировать
> с Вашим "сегменты не пересекаются"?

Да лехко. То что сегменты не пересакаются важно только в рамках одной задачи, и делается это всё в ldt. Т.е. с 0 по size идёт cs, потом данные, потом куча и с maxmem растёт вниз стек.

А дальше в общем-то всё просто. Механизм аналогичен тому что используется сейчас. Каждая задача таскает с собой свой каталог страниц (cr3 сохраняется в tss), и в нём настраивается что логический адрес с 0 (начало cs) и N соотв. страниц мапяться на участки физической памяти с кодом, и эту память все могут без проблем шарить.

Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

240. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 15-Ноя-11, 14:40 
> Да лехко. То что сегменты не пересакаются важно только в рамках одной
> задачи, и делается это всё в ldt. Т.е. с 0 по
> size идёт cs, потом данные, потом куча и с maxmem растёт
> вниз стек.

И зачем в этой схеме сегменты?
Если есть
а) NX для данных и стека
б) RO для кода

Ответить | Правка | К родителю #239 | Наверх | Cообщить модератору

241. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 15-Ноя-11, 16:54 
>> Да лехко. То что сегменты не пересакаются важно только в рамках одной
>> задачи, и делается это всё в ldt. Т.е. с 0 по
>> size идёт cs, потом данные, потом куча и с maxmem растёт
>> вниз стек.
> И зачем в этой схеме сегменты?
> Если есть
> а) NX для данных и стека
> б) RO для кода

Это сейчас есть. NX появился через четверть века после сегментов. А ro для страниц кода не спасает от инжекта оного в любую другую страницу с данными и передачи управления туда в текущей плоской модели памяти.

Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

242. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 15-Ноя-11, 21:52 
> Это сейчас есть. NX появился через четверть века после сегментов.

Ну так сегменты окончательно стали не актуальны. О чём и речь.

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

246. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 17-Ноя-11, 10:00 
> Это сейчас есть. NX появился через четверть века после сегментов.

Ну так с его появлением нужны сегменты или нет?
Hint: архитектура x86-64 в native mode вообще не поддерживает при адресации никаких опционов в плане сегментов, кроме FS/GS, да и те весьма ограниченно - только для совместимости с маразматичностью винды.

Ну и TSS в классическом виде (для переключения задач) тоже уже не поддерживается, как устаревший механизм. Только для задания кое-каких параметров на Ring'ах.

Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

247. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 17-Ноя-11, 12:32 
>> Это сейчас есть. NX появился через четверть века после сегментов.
> Ну так с его появлением нужны сегменты или нет?

Идиотский вопрос, особенно в свете того что ими никто не пользуется.

> Hint: архитектура x86-64 в native mode вообще не поддерживает при адресации никаких
> опционов в плане сегментов, кроме FS/GS, да и те весьма ограниченно
> - только для совместимости с маразматичностью винды.

fs/gs это не маразматичность винды. В fs винда держит tls (линупс для эти целей пользует gs), второй регистр использую системы виртуализации (vmware как минимум).


Ответить | Правка | К родителю #246 | Наверх | Cообщить модератору

248. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 21-Ноя-11, 03:44 
> Фигня в том что страничная адресация это совершенно другой уровень управления памятью.

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

> О то что есть какие-то страницы приложения знать не обязательно. А
> сегментное разделение это логическая структура приложения.

В нормальной многозадачной операционке приложение не должно само лезть в такие дебри.  

[..]
> Ещё раз, сегменты и страницы это совершенно различные уровни абстракций.

Из страниц можно изображать разные регионы-"сегменты" с разными правами доступа. То что один полезный вариант прав не предусмотрели - ну да, упущеньице.

[..]
> Защита через сегменты появилась в 82-м году, работает и не пробивается.

А паровозы появились вообще более 100 лет назад и им было плевать на обрыв контактной сети. И чего теперь, на паровозах чтоли ездить до упора?

> NX bit - четверь века спустя и, по сути, не является гарантированым
> решением проблемы. Такой прямо мегаскачок :)

На самом деле - в лобовую пробить аппаратно выставленный NX бит достаточно проблематично. MMU вполне честно энфорсит права на доступ в память. А то что хакеры находят разные веселые воркэраунды - так это еще вопрос что было бы с сегментами. Их нынче никто не юзает и поэтому проверки на практике не было.

[..]
>> не вижу чем защита памяти через сегменты лучше защиты памяти через
>> MMU и атрибуты страниц.
> Ну что я могу сказать. Лучше тем что она работала ещё когда вас в проекте не было,

Кто сказал что меня не было в проекте? Мы тут шарлатанов не вызывали.

> в отличии от.

А вот паровозы изобрели когда меня не было в проекте. Они стало быть лучше скоростных поездов, правда? И чего это все от них дружно отказались?

> Это к чему? Решили блеснуть знаниями? Какие ещё исключения знаете? :)

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

>> Внезапно, деление на кернел и юзер ничего такого не запрещает.
> Ужас. Показываю на пальцах. Пробили вы драйвер сетевухи. В совеременных осях вы
> сразу оказываетесь в ring0 и можете делать что угодно, а при
> нормальной реализации защиты вы будете сидеть в ring1/2 и нихрена делать
> не можете.

Ага, вас послушать так в ring3 и вообще пукнуть нельзя. А поди ж ты, хаксоры умудряются оттуда полностью систему раздолбать. Наиболее очевидный вариант: можно там спокойно сидеть и патчить все что качает юзер, довешивая эксплойты на известные дыры для известных форматов файлов + втыкать вирусы в все скачиваемые EXE. Но это же сущие пустяки, да? :)

Кстати если драйверу нельзя опасные операции - он должен просить ос. И тут еще вопрос как там с безопасностью всего этого. А чем это принципиально отличается от того что ring3 просит ядро разрулить запросы?

Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

160. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 07-Ноя-11, 02:21 
> После вдувания порции стероидов это обозвали кором, и до сих пор обзывают.

core/core 2 - это наследник p3, современная i-серия, это таки нехалемы.

> Но все это не отменяет отсутствия команд для загрузки данных по смещению относительно program counter.

Приплыли. Возьму на себя роль КО. Security model в ia32 была достаточно мощной для своего времени, и она достаточно мощна сегодня, ну существует туева хуча процов для бедных которые поддерживали только два уровня защиты и страничную адресацию с плоским линейным пространством без защиты из-за чего пришлось похерить такую мегавещь. В результате мы имеем такие бонусы как buffer overflow позволяющие загрузить и выполнить код, ведро костылей в виде nx/xd и, опять же, возможность пробить систему и вылезти в ring 0.

А возможность загружать данные относительно (e)ip она лишняя, сегмент кода в ring 3 (тобишь userland) похорошему должен иметь только execute, без всяких read.

Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

187. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +1 +/–
Сообщение от Аноним (-), 07-Ноя-11, 20:48 
> core/core 2 - это наследник p3, современная i-серия, это таки нехалемы.

А i-серия - наследник коров2, еще более доработанный. Там еще больше блоков, еще больше кеша, etc. И что забавно, это в очередной раз позволило интелу взять новые высоты, эволюционным а не революционным методом. Что довольно предсказуемо.

>> Но все это не отменяет отсутствия команд для загрузки данных по смещению относительно program counter.
> Приплыли. Возьму на себя роль КО. Security model в ia32 была достаточно
> мощной для своего времени,

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

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

Не хочу ничего сказать, но MMU других процессоров (на плечи которых и ложится обеспечение защиты памяти) по общей своей идее почему-то довольно похожи на то что у х86. Примерно такие же страницы и что там еще. А плюс-минус 1-2 лишних кольца-уровня защиты - да вообще похрену, все-равно все современные операционки довольствуются 2-я, "ядром всемогущим" и "юзером бесправным". Все, включая ваш любимый MS на "лишние" кольца дружно забили и ограничились двумя. Ну и все остальные производители процов гляда на это тоже активно развивали эти 2 режима. Бывает и больше режимов, это у кого как. В этом плане тот же интел не так уж принципиально отличен от ARM или MIPS или там кого еще. Примерно как почти все легковые автомобили имеют более-менее похожий друг на друга дизайн, 4 колеса, руль и педали, так и здесь. Устоялся вот такой вот дизайн.

> В результате мы имеем такие бонусы как buffer overflow позволяющие
> загрузить и выполнить код,

Не вижу как лишние кольца помогли бы борьбе с переполнением буфера. Если не брать в расчет приколы типа эксплойта на анимированные курсоры в вашей любимой винде (да, переполнение буфера в ядре это весьма лютый фэйл, а учтя что у вас там один только win32k.sys на 2 мега вгружается - наверное он не последний), код выполняется в наименее привилегированном 3-м кольце.

> ведро костылей в виде nx/xd и, опять же, возможность пробить систему и
> вылезти в ring 0.

А вот тут стоит сказать особо. Сам по себе дизайн с разделением на кернел, юзер и страничным MMU, что у интела, что у остальных (он стал столь же типичен, как типовой дизайн автомобиля) - вполне честный и не имеющий очевидных изъянов: есть "система", которая рулит правами (ядро). И бесправный юзер который сам ничего не может и должен просить систему через сисколы делать потенциально опасные операции под чутким контролем системы. И если вдруг изоляция процесса от процесса или системы от процесса пользователя нарушилась, значит ... операционка обосралась при выполнении своей непосредственной задачи как то разделение ресурсов, управление их совместным использованием и энфорсинг прав доступа. Это - откровенный баг операционки. Сюрприз!

> А возможность загружать данные относительно (e)ip она лишняя, сегмент кода в ring
> 3 (тобишь userland) похорошему должен иметь только execute, без всяких read.

На самом деле, execute без read - это из разряда "хочу есть, но не ртом". На такие извращения процессоры никто не рассчитывал и есть такое смутное подозрение что во первых, сломается половина программ, во вторых, это ограничение наверное можно попробовать обойти окольными путями, а в третьих - мне не понятно: а кого и от чего это защитит? Ну защита на запись - понятно. Защита областей типа стека от выполнения - тоже понятно. А вот защита от чтения - ???

Ответить | Правка | Наверх | Cообщить модератору

197. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 07-Ноя-11, 23:52 
> Не хочу ничего сказать, но MMU других процессоров (на плечи которых и
> ложится обеспечение защиты памяти) по общей своей идее почему-то довольно похожи
> на то что у х86.

Уверены?

> Примерно такие же страницы и что там еще.

Вот-вот. Большинство разрабов процов хватило только на страницы.

> Все, включая ваш любимый MS на "лишние" кольца
> дружно забили и ограничились двумя.

э? Винда на старте поддерживала x86, mips и alpha, потом добавили ppc. Какой там mmu  в этих других процах можете сами почитать. А то что Линус не осилил сегментную модель памяти... что можно ожидать от эмулятора терминала.

>> В результате мы имеем такие бонусы как buffer overflow позволяющие
>> загрузить и выполнить код,
> Не вижу как лишние кольца помогли бы борьбе с переполнением буфера.

Потому что о том как устроен PM в 286+ вы читали в журнале мурзилка (хотя сомневаюсь что вы этот журнал в глаза видели). Для выполнения задачи в PM необходимо LDT, TSS, и три сегмента: code, data, stack. Это уровень организации приложения. Каждый тип сегмента имеет свои уникальные свойства. Сегмент кода всегда RO, а на сегмент данных или стека нельзя сделать джамп. Так вот, для приложения эти три сегмента делаются непересекаемыми, в итоге в случае buffer overflow с загрузкой кода и попыткой перехода мы получим банальный GP.

О том как можно эффективно использовать 4 уровня привелегий подумайте сами.

> На самом деле, execute без read - это из разряда "хочу есть,
> но не ртом". На такие извращения процессоры никто не рассчитывал и

Я ж таки прав. О PM в 286+ вам явно Рабинович на хинди напел.
http://pdos.csail.mit.edu/6.828/2005/readings/i386/s06_03.htm.

> это ограничение наверное можно попробовать обойти окольными путями,

Обойти? Если влезть на уровень mmu то всё обойти можно, а так если сегменты не пересекаются, то никак.

Ответить | Правка | Наверх | Cообщить модератору

233. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 15-Ноя-11, 03:20 
> Уверены?

Общая идея которая устаканилась у всех более-менее одинакова. Ну как говоря авто я ожидаю увидеть руль, 4 колеса, фары, двигатель и прочие стопсигналы, так говоря MMU я в обещм случае ожидаю увидеть вполне характерный агрегат для работы с страничной памятью, у которого на месте более-менее обычные "руль и 4 колеса" и так далее. Какая-то конкретика разумеется отличается, но общая концепция более-менее устаканилась.

>> Примерно такие же страницы и что там еще.
> Вот-вот. Большинство разрабов процов хватило только на страницы.

Знаете, это интела к их чести хватило выбросить свой геморрой с сегментами и перейти на нормальный MMU. То что было в 80286 - лютый феерический пи...ц. Там даже компилеры не могли массивы адресовывать более чем на 64К без спецкостылей и подпорок. Совершенно кретинская модель памяти. К чести интела они решили похоронить это недоразумение и сделать нормальный MMU и линейную адресацию, как у всех вменяемых архитектур. Правда вот выбросить до конца останки наследия не смогли. И зачем-то оставили совершенно куцые регистры, хотя имели все шансы исправить и это упущение.

>> Все, включая ваш любимый MS на "лишние" кольца
>> дружно забили и ограничились двумя.
> э? Винда на старте поддерживала x86, mips и alpha, потом добавили ppc.
> Какой там mmu  в этих других процах можете сами почитать.

Не путайте MMU и кольца защиты. Это разные вещи. На самом деле MMU внедрили в основном для поддержки виртуальной памяти. А до кучи страницная организация памяти дает возможность вешать страницам атрибуты и защищать память всех ото всех, чтоб не шарились почем зря. NX-бит это лишь логичное доразвитие идеи. Никого же не удивляет память отмаркированная как read only например и лютый эксепшн по поводу попытки туда что-то записать.

> А то что Линус не осилил сегментную модель памяти... что можно
> ожидать от эмулятора терминала.

Знаете, сегментная модель памяти юзалась только в 16-бит винде и это было редкостное угробище. Как и вся винда 3.х и 9х - там такая жесть в кернелмоде что линукс на фоне этих куч костылей и нескольких разрозненных кусков ядер разной битности густо подпертых костылями - просто эталон стройности. Не говоря о том что была куча методов испортить память системы из пользовательской программы так что система вставала колом при малейшем сбое программ DOS и т.п.. Linux более-менее на уровне современных ОС как раз потому что его не пытались строить под заведомо дефективную и ограниченную модель памяти и сразу забабахали под именно ту модель памяти которая покорила мир. Кстати современные версии NT-based вы тоже никогда не адаптируете к 80286 и его убогой модели памяти. Они тоже завязаны на страничные методы адресации и ни о каких сегментах и прочих костылях эпохи 286 знать ничего не желают. Потому что в отличие от самопального гумна 3.х/9х это нормальная команда ядерщиков писала, удачно скупленная MSом.

>>> В результате мы имеем такие бонусы как buffer overflow позволяющие
>>> загрузить и выполнить код,
>> Не вижу как лишние кольца помогли бы борьбе с переполнением буфера.
> Потому что о том как устроен PM в 286+ вы читали в
> журнале мурзилка (хотя сомневаюсь что вы этот журнал в глаза видели).

Все эти сегменты в 286 - лютейший маздай. И весь PM - первый блин комом. Нечто вменяемое родили только в i386. И как ни странно, большая часть процессоров (даже всякие ARM и MIPS) используют довольно похожие подходы по части MMU и того что связано с страничной памятью. Сдохло фирменное уе...ство с сегментами - туда и дорога. Flat модель памяти тупо удобнее программить, а атрибуты на страницы вполне можно развесить.

> Для выполнения задачи в PM необходимо LDT, TSS, и три сегмента:
> code, data, stack. Это уровень организации приложения.

А ничего что по хорошему, не все так просто?
Code бывает заведомо readonly, а бывает read-write. И по идее есть 2 разных случая: в идеале хорошо бы readonly, но тогда например в принципе не удастся делать jit компилеры, рантайм оптимизации и прочее. С другой стороны, полная либерастия "пусть код в память пишет кто угодно" чревато невкусными неожиданностями "ой, нас тут внезапно пропатчили без предупреждения и получения на это правов от ОС".
Данные тоже бывают как read-only статичные данные, так и read-write. Но ведь 640 кило хватит всем, правда? :)

> Каждый тип сегмента имеет свои уникальные свойства. Сегмент кода всегда RO,

... и поэтому JIT, трансляцию кода и прочие рантайм оптимизации вообще делать нельзя? Как мило.

> а на сегмент данных или стека нельзя сделать джамп.

Что, и EXE-packers тоже дружно в пролете?

Кстати, теперь примерно то же самое делает NX бит. То что его сразу почему-то не предусмотрели - вот это слегка упущеньице. Но тут стоит вспомнить что в те поры интернет не был так популярен и переполнения буферов всем были до лампочки, а битва шла вокруг защиты ОС от поползновений задач и защиты задач друг от друга. С этим MMU справляется на ура и без NX бита в общем то. Какую задачу решали - ту и решили. А переполнения заткнули когда это стало актуально. Хотя теоретически никто не мешал и раньше это предусмотреть.

> Так вот, для приложения эти три сегмента делаются непересекаемыми, в итоге
> в случае buffer overflow с загрузкой кода и попыткой перехода мы получим банальный GP.

Ну а сейчас получим исключение по поводу NX бита. То же самое, только для страничной модели.

> О том как можно эффективно использовать 4 уровня привелегий подумайте сами.

Что-то ваш любимый майкрософт не захотел на этот счет думать.

>> На самом деле, execute без read - это из разряда "хочу есть,
>> но не ртом". На такие извращения процессоры никто не рассчитывал и
> Я ж таки прав. О PM в 286+ вам явно Рабинович на хинди напел.
> http://pdos.csail.mit.edu/6.828/2005/readings/i386/s06_03.htm.

Не вижу никакого смысла читать о 80286 и его сегментных моделях. Независимо от того какими хорошими и пушистыми были мамонты - они сдохли. Не вижу смысла тратить мое время на труп.

>> это ограничение наверное можно попробовать обойти окольными путями,
> Обойти? Если влезть на уровень mmu то всё обойти можно, а так
> если сегменты не пересекаются, то никак.

Угу, только вся эта сегментная модель предполагает довольно жесткие ограничения на то как выглядит задача и что она вообще может. Взять вот типичный браузер. Он на ходу перегоняет куски скриптов в машинный код для ускорения. Как это делать если сегмент тотально RO? "Это не нужно"? Спасибо, про то что 640К хватит всем - уже слышали.

Ответить | Правка | Наверх | Cообщить модератору

243. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 15-Ноя-11, 21:54 
> Приплыли. Возьму на себя роль КО. Security model в ia32 была достаточно
> мощной для своего времени

Она оказалась настолько неудобоваримой, что в итоге её никто толком так и не использовал в реализациях, и в конце концов от неё ушли в пользу Flat/NX.

Ответить | Правка | К родителю #160 | Наверх | Cообщить модератору

244. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Aleksey Salow (ok), 15-Ноя-11, 22:36 
>> Приплыли. Возьму на себя роль КО. Security model в ia32 была достаточно
>> мощной для своего времени
> Она оказалась настолько неудобоваримой, что в итоге её никто толком так и
> не использовал в реализациях, и в конце концов от неё ушли
> в пользу Flat/NX.

ага

http://en.wikipedia.org/wiki/Ring_(computer_security)

For example, the reason Windows uses only two levels (ring 0 and ring 3) is that some hardware architectures that were supported in the past (such as PowerPC or MIPS) implemented only two privilege levels.

Аналогично было и с сегментами. Они поддерживались только на x86 и соотв. их никто не реализовывал. Правда не помню у кого читал это, может у Реймонда Чена, но гугль ссылок не даёт.

Ответить | Правка | Наверх | Cообщить модератору

245. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 16-Ноя-11, 07:28 
> For example, the reason Windows uses only two levels

Оно до сих пор нормально не умеет NX, так что не пример. *nix'ы тоже особо лишние уровни не жаловали.

Ответить | Правка | Наверх | Cообщить модератору

123. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +4 +/–
Сообщение от koloboid (ok), 06-Ноя-11, 13:50 
>В частности у x86-32 нет команд перехода на кусок кода адресованый относительно текущего места выполнения относительным смещением от этого места до нужного участка кода.

месье, откройте для себя опкод 0xEB (емнип). да, в пределах +-127, и проблему не решает, но подсказывает, что не надо делать опрометчивых заявлений.

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

142. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 06-Ноя-11, 18:34 
> месье, откройте для себя опкод 0xEB (емнип). да, в пределах +-127, и
> проблему не решает, но подсказывает, что не надо делать опрометчивых заявлений.

Камень в огород принимается ;). Скорее, следовало припомнить отсутствие адресации данных относительно PC. Вот это уже надежно вбивает гвозди в крышку гроба позиционно-независимых программ.

Ответить | Правка | Наверх | Cообщить модератору

164. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от koloboid (ok), 07-Ноя-11, 11:15 
> Скорее, следовало припомнить отсутствие адресации данных
> относительно PC. Вот это уже надежно вбивает гвозди в крышку гроба
> позиционно-независимых программ.

это да. не понимаю, почему оно до сих пор живое? не по дарвину все это :)

Ответить | Правка | Наверх | Cообщить модератору

213. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от dq0s4y71 (??), 09-Ноя-11, 14:22 
А ещё можно открыть для себя опкод 0xE9 и префикс размера операнда 0x66, тогда, может быть, и в пределах 4-х гигов можно будет прыгать :)
Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

215. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 09-Ноя-11, 14:28 
> А ещё можно открыть для себя опкод 0xE9 и префикс размера операнда
> 0x66, тогда, может быть, и в пределах 4-х гигов можно будет
> прыгать :)

Ещё раз: (0x66) 0xE9 - ADD IP/EIP,imm
Никакой относительной адресацией тут даже не пахнет.

Ответить | Правка | Наверх | Cообщить модератору

219. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от dq0s4y71 (??), 09-Ноя-11, 14:41 
Неправда.

> IA-32 Intel® Architecture Software Developer’s Manual Volume 2: Instruction Set Reference
> ...
> JMP—Jump
> ...
> E9 cd JMP rel32 Jump near, relative, displacement relative to next instruction
> ...
> Near and Short Jumps. When executing a near jump, the processor jumps to the address

(within the current code segment) that is specified with the target operand. The target operand specifies either an absolute offset (that is an offset from the base of the code segment) or A RELATIVE OFFSET (A SIGNED DISPLACEMENT RELATIVE TO THE CURRENT VALUE OF THE INSTRUCTION POINTER IN THE EIP REGISTER).

Ответить | Правка | Наверх | Cообщить модератору

124. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  –1 +/–
Сообщение от Школьник (ok), 06-Ноя-11, 14:01 
>И если вы в системе команд х86 не можете адресоваться относительно текущего места кода, вы это не можете и все тут.

Было бы хорошо, если бы вы не несли бред столь самоуверенно:

http://en.wikipedia.org/wiki/X86_assembly_language
---
Each jump operation has three different forms, depending on the size of the operand. A short jump uses an 8-bit signed operand, which is a relative offset from the current instruction. A near jump is similar to a short jump but uses a 16-bit signed operand (in real or protected mode) or a 32-bit signed operand (in 32-bit protected mode only).
---

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

128. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +1 +/–
Сообщение от AlexAT (ok), 06-Ноя-11, 15:49 
Школьники, как и полагается, путают относительную адресацию статических данных с относительным переходом...
Ответить | Правка | Наверх | Cообщить модератору

137. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 06-Ноя-11, 17:36 
> Школьники, как и полагается, путают относительную адресацию статических данных с относительным
> переходом...

А данные адресовать нам что, не надо? Относительный переход - это круто, но что с ним делать без доступа к данным?! А относительной адресации данных у х86 нет.

Ответить | Правка | Наверх | Cообщить модератору

145. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Школьник (ok), 06-Ноя-11, 18:47 
Да, с данными ничего не поделаешь. Можно, конечно, изобрести костыль вроде

mov esi, eip (не помню, можно ли вот так сразу, но не суть)
mov eax, [esi+var_1]

но это именно что костыль.

Ответить | Правка | Наверх | Cообщить модератору

188. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 07-Ноя-11, 20:59 
> но это именно что костыль.

Ну так о чем и речь, в х86 такого "счастья" - на каждом углу.

Ответить | Правка | Наверх | Cообщить модератору

143. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Школьник (ok), 06-Ноя-11, 18:36 
А что, товарищ где-то говорил про адресацию _данных_? Он говорил про относительную адресацию в общем. Он даже вот это упомянул:

>В частности у x86-32 нет команд перехода на кусок кода адресованый относительно текущего места выполнения относительным смещением от этого места до нужного участка кода.

что не соответствует действительности. Мне следовало бы именно это процитировать, да, виноват.

ЗЫ Но красноглазым, как и полагается, что частное, что общее - все равно, лишь бы очередной патч к патчу на патч для свеженького ядреца наложился, да? ;-)

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

148. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 06-Ноя-11, 19:05 
> А что, товарищ где-то говорил про адресацию _данных_? Он говорил про относительную
> адресацию в общем. Он даже вот это упомянул:

Да-да, прогнал. У х86 все-таки есть зачаточная относительная адресация переходов. Нет относительной адресации данных, поэтому позиционно независимую программу сделать все-равно не выйдет без костылей.

>>В частности у x86-32 нет команд перехода на кусок кода адресованый относительно текущего места выполнения относительным смещением от этого места до нужного участка кода.
> что не соответствует действительности. Мне следовало бы именно это процитировать, да, виноват.

Да-да, уже подправили, но не школьник почему-то ;). На самом деле - я х86 набор команд видел давно, проблевался и предпочел более вменяемые наборы команд. Поэтому знания оного - весьма так себе.

> ЗЫ Но красноглазым, как и полагается, что частное, что общее

Это слишком толсто - незачет.

Ответить | Правка | Наверх | Cообщить модератору

151. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Школьник (ok), 06-Ноя-11, 19:18 
>> ЗЫ Но красноглазым, как и полагается, что частное, что общее
>Это слишком толсто - незачет.

Это было не вам адресовано :-) Вы вообще хороший комментарий написали, с интересом прочитал, только вот с относительной адресацией была неточность.

Ответить | Правка | Наверх | Cообщить модератору

216. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от dq0s4y71 (??), 09-Ноя-11, 14:35 
> У х86 все-таки есть зачаточная относительная адресация переходов.

Почему зачаточная?

> 66E978563412 jmp +0x123456768

не достаточно?

> На самом деле - я х86 набор команд видел давно, проблевался и предпочел более вменяемые наборы команд.

Это какие, например?

Ответить | Правка | К родителю #148 | Наверх | Cообщить модератору

217. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 09-Ноя-11, 14:36 
>> У х86 все-таки есть зачаточная относительная адресация переходов.
> Почему зачаточная?
>> 66E978563412 jmp +0x123456768
> не достаточно?

Блин. Всё, "специалисты" понабежали. JMP +x - это ни что иное, как ADD IP/EIP,x. Никакой относительной адресации тут нет, обычный ADD r,imm.

Ответить | Правка | Наверх | Cообщить модератору

221. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от dq0s4y71 (??), 09-Ноя-11, 15:06 
Смешной вы. У "обычного ADD r,imm" другой опкод. А что там процессор у себя делает, чтобы получить новый адрес, не имеет никакого значения. Вполне логично предположить, что он для этого выполняет ОПЕРАЦИЮ СЛОЖЕНИЯ :)
Ответить | Правка | Наверх | Cообщить модератору

223. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 09-Ноя-11, 19:51 
> Смешной вы. У "обычного ADD r,imm" другой опкод. А что там процессор
> у себя делает, чтобы получить новый адрес, не имеет никакого значения.
> Вполне логично предположить, что он для этого выполняет ОПЕРАЦИЮ СЛОЖЕНИЯ :)

C EIP/IP доступна только одна подобная операция - поэтому для нее отдельный опкод.

Ну и еще раз перечитайте себя - ОПЕРАЦИЯ СЛОЖЕНИЯ и операция взятия данных по относительному адресу - это одно и то же?

Ответить | Правка | Наверх | Cообщить модератору

224. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от dq0s4y71 (??), 09-Ноя-11, 21:22 
> C EIP/IP доступна только одна подобная операция - поэтому для нее отдельный опкод.

С EIP/IP не доступна НИ ОДНА операция. Есть операции переходов/вызовов и др., с помощью которых можно косвенно изменить EIP/IP, но это не "операции с EIP/IP".

> Ну и еще раз перечитайте себя - ОПЕРАЦИЯ СЛОЖЕНИЯ и операция взятия данных по относительному адресу - это одно и то же?

Нет. А я разве где-то утверждал обратное? :) Я лишь, вслед за другими, не согласился с утверждением, что в x86 отсутствует операция перехода относительно текущего EIP/IP. И подтвердил это цитатами из двух интеловских мануалов. Читайте внимательнее и таки учите матчасть :)

Ответить | Правка | Наверх | Cообщить модератору

225. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 09-Ноя-11, 22:07 
> С EIP/IP не доступна НИ ОДНА операция. Есть операции переходов/вызовов и др.,
> с помощью которых можно косвенно изменить EIP/IP, но это не "операции
> с EIP/IP".

Операция перехода - это как раз либо MOV IP/EIP,imm либо ADD IP/EIP,imm
Да, она стала чуть хитрее - различные сбросы очередей, конвееров, оптимизации и т.п.
Да, она бывает условной. Но она не имеет НИКАКОГО отношения к относительной адресации.
Учите матчасть, еще раз повторяю.


Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

226. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 09-Ноя-11, 22:38 
Если уж быть последовательным до конца, у x86 есть (возможны условия в условных переходах и загрузка сегментных регистров в дальних переходах):

1. Операция прямого перехода с прямой адресацией: JMP imm
2. Операция относительного перехода (!!!) с прямой адресацией (!!!): JMP +imm
3. Операция прямого перехода с регистровой адресацией: JMP reg
4. Операция прямого перехода с косвенной регистровой адресацией: JMP [reg]

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

227. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от dq0s4y71 (??), 09-Ноя-11, 23:48 
> Операция перехода - это как раз либо MOV IP/EIP,imm либо ADD IP/EIP,imm

Таких инструкций не существует, вы бредите :)

> 2. Операция относительного перехода (!!!) с прямой адресацией (!!!): JMP +imm

Перехода относительно ЧЕГО? Сосредоточьтесь и попытайтесь подумать: относительно ЧЕГО осуществляется переход. А потом ещё раз перечитайте, что писал Аноним и что ему отвечали. Тогда, может быть, настанет проблеск :) Все вменяемые уже давно поняли... :)

Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

228. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +1 +/–
Сообщение от AlexAT (ok), 10-Ноя-11, 07:21 
>> Операция перехода - это как раз либо MOV IP/EIP,imm либо ADD IP/EIP,imm
> Таких инструкций не существует, вы бредите :)

То, что вы их без очков не видите, предпочитая упереться в книжки - ваши ЛПП.

>> 2. Операция относительного перехода (!!!) с прямой адресацией (!!!): JMP +imm
> Перехода относительно ЧЕГО?

Вы - идиот. Относительная адресация и относительный переход - разные вещи.

Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

229. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Аноним (-), 15-Ноя-11, 01:47 
>> C EIP/IP доступна только одна подобная операция - поэтому для нее отдельный опкод.
> С EIP/IP не доступна НИ ОДНА операция. Есть операции переходов/вызовов и др.,
> с помощью которых можно косвенно изменить EIP/IP, но это не "операции
> с EIP/IP".

Да ну бросьте. По факту - это именно они и есть. Кстати на ARM например можно влобовую с аналогичным по смыслу регистру операции делать. Потому что по свойствам он как РОН. Сразу, без извращений.

Ответить | Правка | К родителю #224 | Наверх | Cообщить модератору

184. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от fi (ok), 07-Ноя-11, 19:14 
> В x86-32 нет адресации относительно текущего места выполнения (относительно текущего значения program counter-а).Наследственная болячка x86.

Наглая лож. Смотрим старый добрый asm86 для 8086, команда JMP (0xEB).  

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

218. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от AlexAT (ok), 09-Ноя-11, 14:37 
> Наглая лож. Смотрим старый добрый asm86 для 8086, команда JMP (0xEB).

Ещё один. См. выше.

Ответить | Правка | Наверх | Cообщить модератору

252. "Новости Ubuntu: отказ от CD, удаление Mono, акцент на 64-раз..."  +/–
Сообщение от Мужик32 (ok), 02-Дек-11, 14:35 
>за период 1969-2011гг

Сейчас сложно найти бинарный пакет, скомпилированный для Intel SuperMegaProc 100500 Cores. Пакеты собирают для i486, i586, максимум - это i686. А 686 был выпущен в 1995 году.
Ну и вообще, зачем вы рассказываете о том, что может быть возможно есть во внутреннем RISC-процессоре? Ведь для программиста всё равно доступна только система команд x86. Да и вряд ли этот RISC умеет больше, чем нужно для выполнения x86-программ.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру