Рыночная капитализация на текущий момент в 2.7 раза меньше чем у аmd (82 vs 222).
Идут активные слухи о разделении компании и продаже по частям.
Как то это прямо так скажем совсем не то что я лично хотел. Я бы хотел чтобы amd intel догнала, и дальше они в каком то разумном соотношении аля 50 на 50 конкурировали друг с другом.
А не это вот неожиданное "извините, нешмогла, досвиданья".
Я что-то не могу понять, как они отделят "клиентские" процессоры — грубо говоря, от Celeron до i9 — от "серверных", всяких Xeon.
Рахитектура одна. Будет ещё один заклятый друг в стиле AMD, но с ограничением сегментации?
rm2>Как то это прямо так скажем совсем не то что я лично хотел. Я бы хотел чтобы amd intel догнала, и дальше они в каком то разумном соотношении аля 50 на 50 конкурировали друг с другом. rm2>А не это вот неожиданное "извините, нешмогла, досвиданья".
rm2>интел, не болей.
Intel болен изначально, чудовищными авантюрами, которые вгоняли их на уровень земли.
Им несколько раз исключительно везло. Сначала им помогла IBM, иначе 8086 был бы никому нахрен не нужен за его кривизну. Потом после iAPX432 они вытянулись на тех же PC, которые "вошли в струю".
Потом их спасли государственные деньги за ASCI Red, на которых они смогли сделать рабочий OoO и окончательно выдавить M68k.
Потом после взаимно родственных авантюр с Rambus, P4, и IA64 их спасли израильтяне с Core.
Но на сейчас я не вижу, на чём они могли бы снова выиграть. Резерв закончился.
Честно, мне их не очень жалко. X86 сам по себе имеет минимальную ценность. Ценно только то, что он стоял сердцем открытой архитектуры — пусть даже не для лаптопа, но для десктопа и сервера. Вот её мне жалко. Но и этому есть сейчас замены.
Здравствуйте, wl., Вы писали:
wl.>Здравствуйте, netch80, Вы писали:
N>>Рахитектура
wl.>зачем же с таким презрением об x64
1. Я говорил об x86 в целом. Она ужасна по 100500 параметров, и расписывать это можно часами.
2. x86-64 (я из юниксового лагеря и для меня "x64" это "любая 64-битная архитектура") не стала заметным улучшением. Да, чуть стало полегче за счёт количества регистров, и это по сути всё. Остальные ужасны остались на том же уровне.
Хочешь удивиться — почитай, что такое Intel APX. Фактически они поняли, что надо догнать AArch64, но при этом снова сохраняя тот шрёбаный прындец, который натворен в системе команд (начиная с кодировок).
Знакомый в интеле рассказывал как у них проходила встреча цель которой было запланировать переименование всех оскорбляющих стрингов на не оскорбляющее, master -> main и т.д.
Еще мне понравилась его история когда нужно было найти нового работника — девушку. Точнее практикантку, но это не суть. Из четырех кандидаток, которые практически ничего не умели, так как были сразу после ВУЗов, так еще и гуманитарных, выбрали ту ... что была черной.
А знаете в чем сок? Эта практикантка на старт получила 2500$, в Польше.
Здравствуйте, xma, Вы писали:
xma> Из четырех кандидаток, которые практически ничего не умели, так как были сразу после ВУЗов, так еще и гуманитарных, выбрали ту ... что была черной. xma>А знаете в чем сок? Эта практикантка на старт получила 2500$, в Польше.[/q]
Ну это не имеет отношения к Интелу. Это вообще Америку так убивают.
N>Им несколько раз исключительно везло. Сначала им помогла IBM, иначе 8086 был бы никому нахрен не нужен за его кривизну.
Согласен гораздо более, чем полностью
После pdp-11 программить на этом убожестве было просто мазохизмом, кем я не являюсь.
Но пришлось.
Плевался долго, пока не пересел окончательно на С++
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
N>>Им несколько раз исключительно везло. Сначала им помогла IBM, иначе 8086 был бы никому нахрен не нужен за его кривизну. LVV>Согласен гораздо более, чем полностью LVV>После pdp-11 программить на этом убожестве было просто мазохизмом, кем я не являюсь.
У меня была тоже когда-то ностальгия по PDP-11. Быстро прошла, когда вкопался глубже и познакомился плотнее с альтернативами. Вот как раз по сравнению с PDP-11 нельзя говорить, что x86 сильно хуже. Большинство пакостей, которые сделаны в x86, вообще за пределами того, что в PDP-11.
Ну и её подход на 32-битность уже практически не растягивался.
LVV>Но пришлось. LVV>Плевался долго, пока не пересел окончательно на С++
На такой уровне, конечно, особенности ISA уже почти не видны.
rm2>>>>интел, не болей. Pzz>>>Loongson наше всё. K>>наше? а где его купить-то? Pzz>Завезут еще.
от того момента когда я первый раз захотел его купить и до сегодня прошло уже столько лет что я его давно мысленно списал.
глупо тратить время на железку, которую завозят по большим праздникам. с практической точки зрения она мертва. т.е. где-то есть место, где вовсе даже не мертва, но я от этого места отделен такими барьерами, что отличить её от мертвой невозможно.
Здравствуйте, rm2, Вы писали:
rm2>А не это вот неожиданное "извините, нешмогла, досвиданья". rm2>интел, не болей.
Когда появился М1, и в особенности когда и виндоноутбуки начали делать на АРМ, интел действительно оказался совсем никому не нужен. Как некогда Нокиа после выхода айфона.
Селяви.
Здравствуйте, sergey2b, Вы писали:
S>Справедливости ради Интел удалил многие драйвера на материнки и для американцев S>Типа оптимизировали расходы на веб сайт
Компания, которая оптимизирует расходы, удаляя драйвера с сайта (!!!!!111111), тем более не заслуживает жить.
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
S>>Типа оптимизировали расходы на веб сайт
A>Компания, которая оптимизирует расходы, удаляя драйвера с сайта (!!!!!111111), тем более не заслуживает жить.
Здравствуйте, netch80, Вы писали:
N>>>Рахитектура wl.>>зачем же с таким презрением об x64 N>1. Я говорил об x86 в целом. Она ужасна по 100500 параметров, и расписывать это можно часами. N>2. x86-64 (я из юниксового лагеря и для меня "x64" это "любая 64-битная архитектура") не стала заметным улучшением.
Вообще говоря архитектуру amd64 так же известную как x86-64 и x64 создали в AMD. Был бы Intel главным инноватором до сих пор бы может сидели на x86, а после и на 4-ёх ядрах.
И главный прокол Intel это прежде всего не желание отдавать физическое производство процессоров на сторону при том, что их собственное производство устарело.
А попытки справиться с этим заводским бустом процессоров чтобы догнать конкурентов использующих более совершенный тех. процесс привели с годами к жёстким фейлам.
То что они ушли из России не комментирую. А то можно придумать много смешных историй про то, что их сгубило именно это. Но хейтеров это им добавило.
Здравствуйте, Muxa, Вы писали:
S>>>Типа оптимизировали расходы на веб сайт
A>>Компания, которая оптимизирует расходы, удаляя драйвера с сайта (!!!!!111111), тем более не заслуживает жить.
M>РЕЧЬ ИДЕТ О ТРЕХЗНАЧНЫХ СУММАХ!
Ладно, переубедил. #интел_живи
I'm a sewer mutant, and my favorite authors are Edgar Allan Poo, H.G. Smells and George R.R. Martin.
Здравствуйте, velkin, Вы писали:
N>>2. x86-64 (я из юниксового лагеря и для меня "x64" это "любая 64-битная архитектура") не стала заметным улучшением. V>Вообще говоря архитектуру amd64 так же известную как x86-64 и x64 создали в AMD.
Спасибо, кэп.
AMD на момент этого были нищие, готовы были обанкротиться в любой момент и поставили всё на этот дизайн. Что-то серьёзно менять они не могли, даже если хотели.
Да, они упустили многое по мелочам, но в их положении это примерно неизбежно и я их существенно винить за это как-то не планирую.
Во всём этом виноват Intel, который продвигал заведомо мертворожденную IA64 и потратил на неё гигабаксы, хотя нормальный 64-битный дизайн даже в стиле близком к x86-32 обошёлся бы на порядок дешевле.
V> Был бы Intel главным инноватором до сих пор бы может сидели на x86, а после и на 4-ёх ядрах.
Нет. 64-битные архитектуры вокруг уже начинали гулять толпами. Если бы вообще никто ничего не сделал, то уже к 2005 в серверном сегменте x86 не было бы вообще.
V>И главный прокол Intel это прежде всего не желание отдавать физическое производство процессоров на сторону при том, что их собственное производство устарело.
Это ещё не однозначно. Возможно, их не устроили денежные условия, или им не давали слоты вовремя. У TSMC уже очередь на годы вперёд.
V>>И главный прокол Intel это прежде всего не желание отдавать физическое производство процессоров на сторону при том, что их собственное производство устарело. N>Это ещё не однозначно. Возможно, их не устроили денежные условия, или им не давали слоты вовремя. У TSMC уже очередь на годы вперёд.
Ну они (топы) долго посмеивались над АМД и другими мол, настоящие пацаны все на своих фабриках делают.
Плюс во многом их успех в девяностые-нулевые обуславливался собственным производством.
Да и свое производство Интела долгое время по параметрам не уступало, а местами превосходило конкурентов.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, velkin, Вы писали:
N>>>2. x86-64 (я из юниксового лагеря и для меня "x64" это "любая 64-битная архитектура") не стала заметным улучшением. V>>Вообще говоря архитектуру amd64 так же известную как x86-64 и x64 создали в AMD. N>Спасибо, кэп.
Выражайся яснее и меньше будет кэпов. А то пишешь, что для тебя всё едино, потом у тебя все кэпы. Различай x86 и amd64 в особенности другие виды 64-битных архитектур. Тем более когда ты обсуждаешь то, что сделали Intel и что они не сделали.
N>AMD на момент этого были нищие, готовы были обанкротиться в любой момент и поставили всё на этот дизайн. Что-то серьёзно менять они не могли, даже если хотели.
Да вообще всегда такие нищие, но ATI Technologies всё же выкупили. А что делал Intel? Он просто адаптировал под себя архитектуру amd64. Потом драл деньги со всех, особенно с серверного сегмента. Xeon'ы у них золотые видимо судя по цене.
N>Да, они упустили многое по мелочам, но в их положении это примерно неизбежно и я их существенно винить за это как-то не планирую.
В положении, когда твой бизнес идёт отлично, конечно, проще ничего не делать и не изобретать.
N>Во всём этом виноват Intel, который продвигал заведомо мертворожденную IA64 и потратил на неё гигабаксы, хотя нормальный 64-битный дизайн даже в стиле близком к x86-32 обошёлся бы на порядок дешевле.
Ну вот AMD и сделали amd64 (x86-64) и заметь проблема та же самая, что сейчас с arm. Можно кричать на каждом углу про него, но если софт под него не компилируют, то это один в одни ситуация как с ia64. Я как-то давно читал статью, что это связано с тем на чём сидят разработчики. Если для разработчиков сервер не становится буквально рабочей машиной, то дела идут плохо.
V>> Был бы Intel главным инноватором до сих пор бы может сидели на x86, а после и на 4-ёх ядрах. N>Нет. 64-битные архитектуры вокруг уже начинали гулять толпами. Если бы вообще никто ничего не сделал, то уже к 2005 в серверном сегменте x86 не было бы вообще.
А не факт. По сути многие надеются, что свободный софт им всё разрулит. Именно так и продвигаются современные сервера. А если не разрулит, если люди не будут сразу переходить на новую архитектуру. Сейчас ведь тоже есть сервера на arm, но не каждый их купит.
V>>И главный прокол Intel это прежде всего не желание отдавать физическое производство процессоров на сторону при том, что их собственное производство устарело. N>Это ещё не однозначно. Возможно, их не устроили денежные условия, или им не давали слоты вовремя. У TSMC уже очередь на годы вперёд.
Да ладно, какая там очередь на годы вперёд, тем более сколько лет уже прошло. То что они хотели продвигать своё производство это да. То что по деньгам им это было выгодно тоже логично, но уже при условии качества. А ведь Intel брали за качество и превосходство. Если этого нет, то делай там что угодно, будут брать у конкурентов. Те же AMD продали своё производство чипов в Россию, значит оно у них всё же было. Не то чтобы Intel не могли идти таким же путём даже ничего не продавая, просто не хотели.
И как итог я тоже Штеуд особо и не виню, они просто просрали все полимеры. Даже мне простому обывателю было ясно ещё в 2017 году, что нужно готовиться к приходу AMD Ryzen. А сейчас уже всё, теперь нужно уже не готовиться, а что-то делать со сложившейся ситуацией. А в серверном сегменте нужно думать по поводу AMD Epyc Genoa и Bergamo.
Я единственное не думаю, что это конец Intel. С чего бы? Правительство США им всё равно не даст утонуть. И даже если они меньше заработают, подумаешь. Просто одно дело быть лидером и ломить цены, и другой дело знать своё место.
Здравствуйте, velkin, Вы писали:
N>>>>2. x86-64 (я из юниксового лагеря и для меня "x64" это "любая 64-битная архитектура") не стала заметным улучшением. V>>>Вообще говоря архитектуру amd64 так же известную как x86-64 и x64 создали в AMD. N>>Спасибо, кэп. V>Выражайся яснее и меньше будет кэпов.
А я вообще не говорил о том, что ты тут стал комментировать. Это была подветка, в которой кое-кто ещё отреагировал на "термин" "рахитектура". И зачем ты стал тут обостряться — я не понял.
V> А то пишешь, что для тебя всё едино, потом у тебя все кэпы. Различай x86 и amd64 в особенности другие виды 64-битных архитектур. Тем более когда ты обсуждаешь то, что сделали Intel и что они не сделали.
Да, это было в другом обсуждении и там я про AMD ничего не говорил.
N>>AMD на момент этого были нищие, готовы были обанкротиться в любой момент и поставили всё на этот дизайн. Что-то серьёзно менять они не могли, даже если хотели.
V>Да вообще всегда такие нищие, но ATI Technologies всё же выкупили.
Это было в 2006. А разрабатывать x86-64 они начали до 1999, первый процессор в железе вышел в 2003. Разницу в три года видишь?
N>>Да, они упустили многое по мелочам, но в их положении это примерно неизбежно и я их существенно винить за это как-то не планирую.
V>В положении, когда твой бизнес идёт отлично, конечно, проще ничего не делать и не изобретать.
Я говорил про AMD. Ты ошибся в хронологии и приписываешь им какую-то дичь.
N>>Во всём этом виноват Intel, который продвигал заведомо мертворожденную IA64 и потратил на неё гигабаксы, хотя нормальный 64-битный дизайн даже в стиле близком к x86-32 обошёлся бы на порядок дешевле. V>Ну вот AMD и сделали amd64 (x86-64) и заметь проблема та же самая, что сейчас с arm. Можно кричать на каждом углу про него, но если софт под него не компилируют, то это один в одни ситуация как с ia64.
Ничего не понял. Кто на ком стоял? Кто под что не компилирует?
X86-64? Да к моменту выхода первых процессоров в железе — для неё были готовы Linux и NetBSD. По хорошим готовым спецификациям это делается беспроблемно.
ARM? Все основные системы, включая даже винду, готовы под неё.
И с IA64 ситуация не имеет ничего общего. Под него тоже было всё готово. Только оказалось, что не окупается.
V> Я как-то давно читал статью, что это связано с тем на чём сидят разработчики. Если для разработчиков сервер не становится буквально рабочей машиной, то дела идут плохо.
Ну вот у меня и x86 и ARM одновременно в нескольких последних проектах. Что не так?
V>>> Был бы Intel главным инноватором до сих пор бы может сидели на x86, а после и на 4-ёх ядрах. N>>Нет. 64-битные архитектуры вокруг уже начинали гулять толпами. Если бы вообще никто ничего не сделал, то уже к 2005 в серверном сегменте x86 не было бы вообще. V>А не факт. По сути многие надеются, что свободный софт им всё разрулит. Именно так и продвигаются современные сервера. А если не разрулит, если люди не будут сразу переходить на новую архитектуру. Сейчас ведь тоже есть сервера на arm, но не каждый их купит.
Ну так разрулил же?
В 2003 как только оптероны вышли — одна дружественная контора тут же их закупила — ещё за "тонны нефти", по ~4000$ за штуку. А польза пришла сразу. Это был тяжёлый вебхостинг, которому тупо не хватало памяти в 32-битном варианте.
В этом году ставили два сервера, веб плюс мыло плюс то что вокруг них — поставили на ARM, потому что в ~два раза дешевле за те же параметры. Всему софту по барабану, что там за система команд. Если бы, например, Alpha была бы в наличии и ещё дешевле — взяли бы её.
V>Да ладно, какая там очередь на годы вперёд, тем более сколько лет уже прошло.
От 2 до 5, смотря как считать. Это от первых видимых проявлений и до того, когда ситуация стала напоминать катастрофическую.
За такое время такое производство не развернётся на 180°.
V> То что они хотели продвигать своё производство это да. То что по деньгам им это было выгодно тоже логично, но уже при условии качества. А ведь Intel брали за качество и превосходство. Если этого нет, то делай там что угодно, будут брать у конкурентов. Те же AMD продали своё производство чипов в Россию, значит оно у них всё же было. Не то чтобы Intel не могли идти таким же путём даже ничего не продавая, просто не хотели.
V>И как итог я тоже Штеуд особо и не виню, они просто просрали все полимеры. Даже мне простому обывателю было ясно ещё в 2017 году, что нужно готовиться к приходу AMD Ryzen. А сейчас уже всё, теперь нужно уже не готовиться, а что-то делать со сложившейся ситуацией. А в серверном сегменте нужно думать по поводу AMD Epyc Genoa и Bergamo.
Тут ничего не скажу — что там после 12-го поколения Core я перестал наблюдать аж совсем. А последние проблемы уже в 13-м и 14-м.
Но я не вижу, чем это отличается от вывода просто об их общей стагнации.
V>Я единственное не думаю, что это конец Intel. С чего бы? Правительство США им всё равно не даст утонуть. И даже если они меньше заработают, подумаешь. Просто одно дело быть лидером и ломить цены, и другой дело знать своё место.
Ну смягчат падение — ок, но спасать такой рынок уже вряд ли будут...
Здравствуйте, sergey2b, Вы писали:
S>И кто тогда будет пилить opencv and tbb
Ладно, tbb, но OpenCV Интел уже выкидывала на мороз. Ей не нужен был открытый конкурент их платной IPP. И проиграли: бывшие сотрудники и сообщество подняли библиотеку в лидеры и сделали де-факто стандартом лет на 20 точно. В это время активно начала писать свои модули для OpenCV Nvidia и даже AMD немного OpenCL кода написал. Потом было следующее: авторы OpenCV показали бэкенд для ARM, который ускорял на целевых процессорах некоторые алгоритмы до 10 раз (медианный фильтр, например). Вот тогда Интел и покупает OpenCV с командой назад, а проект для ARM тихо закрывает.
Потом часть разработчиков ушло пилить OpenVINO, сделали альтернативу в виде oneAPI. Но уже нет той массовости и классности продукта, как было раньше. К тому же сейчас курированием OpenCV занимается не Интел, а opencv.ai, я даже не знаю, кому она принадлежит. Ты не в курсе?
S>>>Типа оптимизировали расходы на веб сайт
A>>Компания, которая оптимизирует расходы, удаляя драйвера с сайта (!!!!!111111), тем более не заслуживает жить.
M>РЕЧЬ ИДЕТ О ТРЕХЗНАЧНЫХ СУММАХ!
ИМХО главная ошибка Интела такая же, как в свое время была у Микросовта. Они упустили мобильный рынок. Потихоньку производительность процессоров для мобилок росла, в итоге они выросли во вполне себе нормальных конкурентов x86.
Потом еще они точно так же упутили рынок видеокарт и 3d ускорителей, кто ж знал, что они понадобятся не только для игрушек, думаю это в итоге и было несильным, но добивающим ударом.
Вообще Интел очень большая организация, я так понимаю, в отличии от других разработчиков железа у них есть свое производство чипов, так что это стратегически важная организация, которой совсем загнуться не дадут, ди и вообще они много чего еще делают. Так, что я думаю Интел никуда не денется, но вот эра монополии х86 архитектуры на десктопе и серверах скорее всего уходит, если конечно они не выкатят разко что нибудь прорывное, как когда-то уже бывало. На мой взгляд, уход от х86 это большой плюс для индустрии.
Здравствуйте, ksandro, Вы писали:
K>Вообще Интел очень большая организация, я так понимаю, в отличии от других разработчиков железа у них есть свое производство чипов, так что это стратегически важная организация, которой совсем загнуться не дадут, ди и вообще они много чего еще делают. Так, что я думаю Интел никуда не денется, но вот эра монополии х86 архитектуры на десктопе и серверах скорее всего уходит, если конечно они не выкатят разко что нибудь прорывное, как когда-то уже бывало. На мой взгляд, уход от х86 это большой плюс для индустрии.
Она может разделиться на кучу компаний. Им и не дадут загнуться, скажем всему десятку фабрик. а отдел разработки уйдет скажем в qualcom. И там растворится.
Зря интел (и амд) не продают никому лицензию на х86 amd64. Ограничивают конкуренцию что к хрошему для этой ахитектуры не приведет.
Получается что другие компании у которых есть свои идеи в процессоростроении идут в arm, хотя могли бы создать что-то интересное для x84-64.
в конце концов это может привести к тому что в arm появится такой конкурент который вытеснит x84-64 и из ПК и из серверов и из ноутбуков, и вообще выкинут интел с рынка.
А так может и для телефонов кто-то может годный процессор на x84-64 создал бы, раз уж у Интела с Амд неполучлось.
Здравствуйте, Nuzhny, Вы писали:
N>Потом часть разработчиков ушло пилить OpenVINO, сделали альтернативу в виде oneAPI. Но уже нет той массовости и классности продукта, как было раньше. К тому же сейчас курированием OpenCV занимается не Интел, а opencv.ai, я даже не знаю, кому она принадлежит. Ты не в курсе?
Здравствуйте, sergey2b, Вы писали:
S>Справедливости ради Интел удалил многие драйвера на материнки и для американцев S>Типа оптимизировали расходы на веб сайт
Ну вот американцы оптимизировали расходы на интель. Я вообще не понимаю, кто в здравом уме сейчас, после скандала с деградацией процов, вместо амд возьмёт интел. Нужно быть совсем не в курсе или религиозным интелбоем.
Здравствуйте, sergey2b, Вы писали:
S>Я взял 13850 до плохих новостей S>У интела в десктопных процессорах есть видео енкодер реальная экономия 600-700$ если на компе работаеш с видео
Я когда смотрю обзоры попугаемеров процов, вмегда удивляюсь- ну для чего игроманам или кодерам знать о производительности аппаратного видео энкодера? Это может, "контент крейторам" инфлюенсерам важно, но для 99% покупателей этого проца- зачем? почему?
Здравствуйте, Артём, Вы писали:
Аё>Я когда смотрю обзоры попугаемеров процов, вмегда удивляюсь- ну для чего игроманам или кодерам знать о производительности аппаратного видео энкодера? Это может, "контент крейторам" инфлюенсерам важно, но для 99% покупателей этого проца- зачем? почему?
Аппаратный нужен, если видео сохраняешь. Сергей работает с видео, соответственно он и знает. Другое дело, что он есть не только у Интела. У меня уже давным-давно не было десктопа/ноута без дискретной видеокарты, поэтому не проблема.
Здравствуйте, koenig, Вы писали:
K>стоп-стоп, последний раз я про него слышал в контексте экспортных ограничений (т.е. они сами решили не завозить) — значит, одумались?
Распространение их процессора диаметрально противоположно нашему.
Чтобы купить эльбрус нужно быть или юр. лицом или сделать очень много
телодвижений и заплатить около полмиллиона.
А чтобы купить Loongson нужно быть физ. лицом и тогда за вменяемые деньги можно купить любую
сборку с ним из Китая.
Здравствуйте, Nuzhny, Вы писали:
N>Аппаратный нужен, если видео сохраняешь. Сергей работает с видео, соответственно он и знает.
Без аппаратного не тянет?
Здравствуйте, netch80, Вы писали:
N>1. Я говорил об x86 в целом. Она ужасна по 100500 параметров, и расписывать это можно часами. N>2. x86-64 (я из юниксового лагеря и для меня "x64" это "любая 64-битная архитектура") не стала заметным улучшением. Да, чуть стало полегче за счёт количества регистров
Плюс ABI вызовов, когда первые несколько параметров идут в регистрах, а не в стеке.
N>и это по сути всё. Остальные ужасны остались на том же уровне.
Ну, они собираются почистить проц и кодировку команд — убрать 16 и 32-разрядные режимы исполнения вовсе (оставить 32 бит в режиме песочницы из 64), убрать лишние префиксы для многих 64-битных команд.
N>Хочешь удивиться — почитай, что такое Intel APX. Фактически они поняли, что надо догнать AArch64, но при этом снова сохраняя тот шрёбаный прындец, который натворен в системе команд (начиная с кодировок).
И это тоже.
Да, совместимость — это гиря...
Но рано или поздно надо эту гирю убирать.
Здравствуйте, Артём, Вы писали:
N>>Аппаратный нужен, если видео сохраняешь. Сергей работает с видео, соответственно он и знает. Аё>Без аппаратного не тянет?
Здравствуйте, vdimas, Вы писали:
N>>1. Я говорил об x86 в целом. Она ужасна по 100500 параметров, и расписывать это можно часами. N>>2. x86-64 (я из юниксового лагеря и для меня "x64" это "любая 64-битная архитектура") не стала заметным улучшением. Да, чуть стало полегче за счёт количества регистров V>Плюс ABI вызовов, когда первые несколько параметров идут в регистрах, а не в стеке.
Ну это уже где как. Такой ABI можно было и в 32 битах заказывать отдельными опциями.
Плюс к тому есть контрпримеры — например, Go всё держит на стеке, и входные и выходные данные.
Но кэш смягчает последствия этой разницы.
N>>и это по сути всё. Остальные ужасны остались на том же уровне.
V>Ну, они собираются почистить проц и кодировку команд — убрать 16 и 32-разрядные режимы исполнения вовсе (оставить 32 бит в режиме песочницы из 64), убрать лишние префиксы для многих 64-битных команд.
Я видел проект X86S. Ты или видел какую-то очень раннюю версию, или ошибаешься.
32-битный режим остаётся для user level. (Для kernel — то есть ring 0 в терминах x86 — только 64 бита.) Кодировки не меняются, префиксы остаются.
Но самое серьёзное, что непонятно, а чего вообще они этим добьются. Ну не будет исполнять 16 бит вообще, а 32 в kernel level, и что, это серьёзно уменьшит толщину декодера?
V>Да, совместимость — это гиря... V>Но рано или поздно надо эту гирю убирать.
Ну вот похоже, что "убрать совместимость" окажется в итоге переходом на ARM или RISC-V ;\
Здравствуйте, netch80, Вы писали:
V>>Да, совместимость — это гиря... V>>Но рано или поздно надо эту гирю убирать. N>Ну вот похоже, что "убрать совместимость" окажется в итоге переходом на ARM или RISC-V ;\
Отож.
MIPS сейчас еще второе дыхание получит пинком от китайцев, бо изначально архитектура была заточена на матан и обработку сигналов.
Они так скромничали со своим MIPS-процом (Loongson) в деле экспорта, чтобы не вешать себе те самые гири.
И говорили об этом прямой речью, что пока мест происходит период экспериментов и устаканивания, и всё это на фоне отсутствия желания брать на себя ответственность по обеспечению обратной совместимости с промежуточными версиями архитектуры.
Но, похоже, этот период уже подошёл к концу.
Издание The Register в ноябре 2021 предположило, что компания Loongson взяла части архитектур MIPS и RISC-V, а также дополнительные инструкции, и смешала их в гибридную архитектуру для процессора 3A5000
использует модифицированный набор MIPS, с заменой некоторых команд на аналогичные, разработанные Институтом компьютерных технологий.
Вроде бы, топовый 1890ВМ118 (SoC, включающая графический сопроцессор, USB2.0, SATA, PCI, I²C) собираются делать у нас по 28 нм нормам (сделали, вроде, уже несколько безмасочных литографов, но их нужна целая ферма, бо одна пластина делается примерно 10 часов).
Вычислительный блок векторного сопроцессора позволяет выполнять операции одинарной и двойной точности над векторами
шириной 128 разрядов. Пиковая производительность достигается при использовании команд комплексного умножения с прибавлением и вычитанием третьего операнда («бабочка Фурье») и
составляет за такт 10 вещественных операций двойной точности или 20 вещественных операций одинарной точности.
Здравствуйте, netch80, Вы писали:
N>Им несколько раз исключительно везло. Сначала им помогла IBM, иначе 8086 был бы никому нахрен не нужен за его кривизну. Потом после iAPX432 они вытянулись на тех же PC, которые "вошли в струю".
Это не совсем так. 8086 изначально позиционировался Intel как временное решение, на 2-3 года, чтобы выйти за ограничения 8080. А к тому времени будет готов 432. Так что его "кривизна" была вполне естественной в тот момент.
Другое дело, что когда IBM по совету Гейтса употребила его в IBM PC, Intel быстро сообразила, что надо делать, забросила 432 и начала развивать x86.
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Им несколько раз исключительно везло. Сначала им помогла IBM, иначе 8086 был бы никому нахрен не нужен за его кривизну. Потом после iAPX432 они вытянулись на тех же PC, которые "вошли в струю".
PD>Это не совсем так. 8086 изначально позиционировался Intel как временное решение, на 2-3 года, чтобы выйти за ограничения 8080. А к тому времени будет готов 432.
Ничего в этом не противоречит тому, что я сказал. iAPX432 не выстрелил, и непонятно, кто думал, что он сможет — слишком радикальный подход. Зато выстрелил "промежуточный" 8086. Но зачем и в нём, и дальше было делать максимально уродски?
PD> Так что его "кривизна" была вполне естественной в тот момент.
Что в этом естественного? Что мешало даже тут делать поменьше ляпов на ровном месте?
PD>Другое дело, что когда IBM по совету Гейтса употребила его в IBM PC, Intel быстро сообразила, что надо делать, забросила 432 и начала развивать x86.
Да не было там "быстро". Они пытались усидеть на двух стульях: типа один для бизнеса, другой для "души" с дикими экспериментами.
Кто-то в руководстве (скорее всего, Гроув) пытался получить имя в истории величайшей разработкой века, которая бы дала вообще новое поколение.
Не получилось. Но ресурсов на это ушло безумно.
Здравствуйте, Sharov, Вы писали:
A>>И да и нет. Мне вангуется, что вместе с этим открытую архитектуру убьют.
S>Что подразумевается под открытой архитектурой? Отсутствие вендор лок? Я смогу заменить цпу в системе S>на любой другой совместимый?
Хотя бы как сегодня в десктопном и самосборно-серверном мире x86.
Полсотни производителей материнок, с возможностью купить в варианте от версии для печатной машинки до супермонстра игрового направления. Если IPMI, то не залоченный на тайные знания вендора.
Возможность воткнуть любой процессор из набора 10-20 подходящих от самого тупого (уровня Celeron) до самого мощного (как i7-i9).
Широкий выбор объёма и производителя оперативки.
Интерфейс, позволяющий воткнуть любой диск, или хоть 20 дисков, через отдельный контроллер.
Стандартизованный интерфейс (как сейчас PCI-E) с тысячами производителей плат всех направлений — сеть, дисковые контроллеры NVMe/SATA/SAS/etc., iRAM, хитрые видеокарты, контроллеры всякой целевой диковинки типа приводов для роботов и служебной вроде стримеров.
Максимально распространённые интерфейсы подключения внешних устройств, как USB.
BIOS (как бы ни звался), позволяющий всё это (а не как у некоторых вендоров, "допускается любой диск, если диск от меня любимого, который знает секретные слова").
Если всё это будет только на x86 — то надо держать x86. Даже если не от Intel.
Здравствуйте, netch80, Вы писали:
N>Если всё это будет только на x86 — то надо держать x86. Даже если не от Intel.
Да сам интел и будет держать. А с текущим кризисом ему поможет государство американское.
А учитывая зоопарк на других архитектурах x86 с нами еще надолго.
Единообразно, пусть и безобразно почти всегда и везде заруливает всё остальное не единообразное.
Здравствуйте, Vzhyk2, Вы писали:
N>>Если всё это будет только на x86 — то надо держать x86. Даже если не от Intel. V>Да сам интел и будет держать. А с текущим кризисом ему поможет государство американское.
Вот в помощь от государства я верю. Intel это США. Фабрика это рабочие места. У Intel есть фабрики в самих США. Тенденцию на возврат хотя бы части производств, пусть даже настолько химически грязных, поддерживают все политические направления. Даже если с процессорами будет плохо, загрузка для них найдётся. Но и процессоры, скорее всего, вытянут.
AMD для них слишком азиатская. Договариваться можно, считать столь же надёжным — нет.
V>А учитывая зоопарк на других архитектурах x86 с нами еще надолго.
Зоопарк чего? У ARM всё более-менее единообразно. Во всяком случае, не сильно зоопарковее Intel даже с поправкой на широчайший спектр ориентаций.
Но опять же могут начаться политические соображения. Даже с учётом того, что исходно ARM — "кузены" (британцы), чьи сейчас деньги, сказать сложно, а форсировать "пусть 51% капитала будет англоязычным" или типа того — как-то малореально.
Но тут начинаются вещи, которых мы не знаем точно, поэтому умолкаю.
Здравствуйте, netch80, Вы писали:
N>Вот в помощь от государства я верю. Intel это США. Фабрика это рабочие места. У Intel есть фабрики в самих США. Тенденцию на возврат хотя бы части производств, пусть даже настолько химически грязных, поддерживают все политические направления. Даже если с процессорами будет плохо, загрузка для них найдётся. Но и процессоры, скорее всего, вытянут.
Да и с процессорами наладится. Сейчас повыгоняют толпу на мороз, уменьшать левые инвестиции, помучаются еще с 1-2 поколениями своих процов и выкатят в итоге что-то приличное.
N>Зоопарк чего? У ARM всё более-менее единообразно. Во всяком случае, не сильно зоопарковее Intel даже с поправкой на широчайший спектр ориентаций.
На базе арма я не могу собрать комп, аналогичный такому же на х86.
З.Ы. Я бы очень хотел, чтобы в компах перешли к еще большей унификации интерфейсов для комплектующих.
Здравствуйте, netch80, Вы писали:
N>Вот в помощь от государства я верю. Intel это США. Фабрика это рабочие места. У Intel есть фабрики в самих США. Тенденцию на возврат хотя бы части производств, пусть даже настолько химически грязных, поддерживают все политические направления. Даже если с процессорами будет плохо, загрузка для них найдётся. Но и процессоры, скорее всего, вытянут. N>AMD для них слишком азиатская. Договариваться можно, считать столь же надёжным — нет.
там вопрос не в том будут или не будут помогать, там вопрос что получится после реструктуризации.
Т.к. если оно разделится на кучку компаний, и то подразделение которое x86 проектировало — перейдет(будет продано) скажем в qualcome,
то даже если государство будет этому как то помогать — нам как потребителям это может быть ни тепло ни холодно. ну помогает государство фирме которая arm разрабатывает, или фабричной части отделившейся от интела. И что?
N>Ничего в этом не противоречит тому, что я сказал. iAPX432 не выстрелил, и непонятно, кто думал, что он сможет — слишком радикальный подход. Зато выстрелил "промежуточный" 8086. Но зачем и в нём, и дальше было делать максимально уродски?
Сам 8086 уродским не был, если учесть основную задачу (расширить АП сверх 64 Кбайт) и помнить, что делался он на 2-3 года. Не взяли бы его для IBM PC — о нем никто бы и не помнил сейчас, кроме историков
80186 — без серьезных изменений, да и не использовался.
А вот 80286 — да, уродство. Точнее, набор решений, которые оказались невостребованными (переключение LDT, переключение задач). Но уже было обязательным обеспечить хоть какую-то совместимость c 8086/88, так как нельзя было просто объявить все DOS-программы несуществующими и начать с нуля.
И Интел быстро исправилась. Плоская модель в 32-битном режиме 80386 — никакое не уродство.
PD>> Так что его "кривизна" была вполне естественной в тот момент.
N>Что в этом естественного? Что мешало даже тут делать поменьше ляпов на ровном месте?
А как бы ты сделал это расширение 64 К в 8080 до хотя бы 1 М при том, что регистры остаются 16-битными ? Можно, конечно, без этого странного сложения seg<<4 + ofs, но по существу все равно выйдет то же самое.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А как бы ты сделал это расширение 64 К в 8080 до хотя бы 1 М при том, что регистры остаются 16-битными ? Можно, конечно, без этого странного сложения seg<<4 + ofs, но по существу все равно выйдет то же самое.
Я не про эту сегментную модель. Она как раз нормальна для данной ситуации. Но есть куча других аспектов.
В 8080 не было OF. В 8086 его добавили... в старший байт. При том, что в младшем было место, там и сейчас 3 бита тупо захардкожены в те же 100 что были в 8080. Кажется, мелочь? Уже тогда "стреляет" в виде издевательств, что из 8087 вытаскивается бит... в PF. LAHF/SAHF не работают с OF. В результате, отделить, что в Flags относится к condition, а что — к режиму, становится сильно сложнее. (Потом стреляет ещё и в ранней amd64.)
Изначально ненужные команды, но реализация которых — это чемодан набитый кирпичами без ручки. RCL/RCR со сдвигом более чем 1 бит — даже в ассемблере никто никогда не использовал. CMC — кому когда нужна?
8087: нафига стек регистров? Просто 4 регистра (никогда не использовалось больше) с прямой адресацией — помогло бы эффективнее и проще и изначально, и потом.
Ладно, это минимум. Дальше было хуже, см. ниже.
PD>Сам 8086 уродским не был, если учесть основную задачу (расширить АП сверх 64 Кбайт) и помнить, что делался он на 2-3 года. Не взяли бы его для IBM PC — о нем никто бы и не помнил сейчас, кроме историков PD>80186 — без серьезных изменений, да и не использовался. PD>А вот 80286 — да, уродство. Точнее, набор решений, которые оказались невостребованными (переключение LDT, переключение задач). Но уже было обязательным обеспечить хоть какую-то совместимость c 8086/88, так как нельзя было просто объявить все DOS-программы несуществующими и начать с нуля. PD>И Интел быстро исправилась. Плоская модель в 32-битном режиме 80386 — никакое не уродство.
Плоская модель сама по себе — да. А вот всё вокруг неё — нет.
Та же виртуальная память:
— Почему в page table entry один бит на права на страницу, а не два согласно режимам? Они этим самым с ходу убили rings 1 & 2 даже для тех, кто хотел и мог их осмысленно использовать.
— Почему для ring 0 форсирован маппинг? Ему это нафиг не надо, у него и так права на доступ ко всему физическому адресному пространству.
Далее, 32-битный режим:
— Почему префиксы 0x66, 0x67 явно декларирован с самого начала как NOP для байтовых доступов? Если бы сделали их reserved, не требовалось бы потом вводить REX для 64-битного.
— Они фактически изменили систему команд (декодер точно другой), значит, можно сделать многое иначе. В 1-байтовом наборе дохрена команд, которые редкие и которым не нужно быть такими короткими: как минимум IN[S], OUT[S], CMC, HLT, XLAT, CLI, STI, CLD, STD, ENTER, LEAVE, IRET, LAHF, SAHF, HLT, AAM, AAD... устал перечислять, но там примерно 60 кодов можно было высвободить. Почему это не сделано? Intel был в состоянии это сделать. Кстати, BCD helpers можно было убить уже тогда же из 32-битных (было сделано только для 64).
В результате мы сейчас имеем многобайтовые префиксы типа EVEX[2], всё короткое давно занято.
— Почему 32-битные версии регистров доступны по умолчанию? По-нормальному доступ к ним надо было явно вынести на флаг в CR0. Последствия кривого решения — проблемы с переключалками типа DESQview, если они не готовы к работе на 386, причём проблемы мистические, трудно идентифицируемые (пока все не оттоптались по этим грабелькам).
— Зачем SMSW, SGDT, etc. непривилегированные? Такое впечатление, что кто-то намеренно напакостил. Основы виртуализации были известны ещё 10 лет до того даже в том тупейшем варианте, который у Попек+Гольдберг (что для современной виртуализации как машина Тьюринга с её ленточкой).
Противоестественные реализации некоторых команд. Почему для BSF, BSR ставится ZF, против логики, что он должен ставиться по нулю _результата_, а не источника? Почему не сделать запись какого-нибудь -1 если источник — ноль?
CPUID надо было ввести ещё в 186 хотя бы в виде реализации как NOP (а потом добавлять реальные действия), если вообще началось развитие и различие версий.
Я уж не вспоминаю, что там уже явно были видны проблемы параллеления декодера, и сделать оформление длины команды в явном виде существенно бы облегчило работу. Но будем предполагать, что это бы они не потянули.
Я всё о таких вещах. Все они — нежелание подумать дальше полшага вперёд и сделать так, чтобы себе же было удобно не только в текущей версии, но и чуть-чуть позже... Но нет, "в своём гамаке я желаю полноценно трахаться на лыжах" (c). Фантастическое невежество и бескультурье там, где приложив чуть-чуть ума можно было получить значительно более качественный результат.
Здравствуйте, netch80, Вы писали:
N>В 8080 не было OF. В 8086 его добавили... в старший байт. При том, что в младшем было место, там и сейчас 3 бита тупо захардкожены в те же 100 что были в 8080. Кажется, мелочь? Уже тогда "стреляет" в виде издевательств, что из 8087 вытаскивается бит... в PF. LAHF/SAHF не работают с OF. В результате, отделить, что в Flags относится к condition, а что — к режиму, становится сильно сложнее. (Потом стреляет ещё и в ранней amd64.) N>Изначально ненужные команды, но реализация которых — это чемодан набитый кирпичами без ручки. RCL/RCR со сдвигом более чем 1 бит — даже в ассемблере никто никогда не использовал. CMC — кому когда нужна? N>8087: нафига стек регистров? Просто 4 регистра (никогда не использовалось больше) с прямой адресацией — помогло бы эффективнее и проще и изначально, и потом. N>Ладно, это минимум. Дальше было хуже, см. ниже.
Ну тут я могу еще кое-что добавить. BCD операции, например. Но тогда они казались нужными, да и, видимо, совместимость с 8080 требовалась.
N>Плоская модель сама по себе — да. А вот всё вокруг неё — нет. N>Та же виртуальная память: N>- Почему в page table entry один бит на права на страницу, а не два согласно режимам? Они этим самым с ходу убили rings 1 & 2 даже для тех, кто хотел и мог их осмысленно использовать.
Потому что механизмы от 286 оказались ненужными. Фактически весь механизм защиты и адресации от 286 в 386 аннигилирован. Он остается, как же иначе, но по сути роли не играет, его программируют так, чтобы не мешал. А реально защита идет на страничном механизме.
Вспомни, зачем сделали 4 кольца. 0-е для ядра ОС, 1- для драйверов, так что их падение не приведет к падению ОС. 2- например, для DB engine. Ну и 3. И никто не стал в 286 процессоре это использовать. Равно как никто не стал использовать задачи процессора и переключение LDT. Идея оказалась невостребованной.
N>- Почему для ring 0 форсирован маппинг? Ему это нафиг не надо, у него и так права на доступ ко всему физическому адресному пространству.
Это не понял. Что за форсирование маппинга ?
N>Далее, 32-битный режим: N>- Почему префиксы 0x66, 0x67 явно декларирован с самого начала как NOP для байтовых доступов? Если бы сделали их reserved, не требовалось бы потом вводить REX для 64-битного. N>- Они фактически изменили систему команд (декодер точно другой), значит, можно сделать многое иначе. В 1-байтовом наборе дохрена команд, которые редкие и которым не нужно быть такими короткими: как минимум IN[S], OUT[S], CMC, HLT, XLAT, CLI, STI, CLD, STD, ENTER, LEAVE, IRET, LAHF, SAHF, HLT, AAM, AAD... устал перечислять, но там примерно 60 кодов можно было высвободить. Почему это не сделано? Intel был в состоянии это сделать. Кстати, BCD helpers можно было убить уже тогда же из 32-битных (было сделано только для 64). N>В результате мы сейчас имеем многобайтовые префиксы типа EVEX[2], всё короткое давно занято. N>- Почему 32-битные версии регистров доступны по умолчанию? По-нормальному доступ к ним надо было явно вынести на флаг в CR0. Последствия кривого решения — проблемы с переключалками типа DESQview, если они не готовы к работе на 386, причём проблемы мистические, трудно идентифицируемые (пока все не оттоптались по этим грабелькам). N>- Зачем SMSW, SGDT, etc. непривилегированные? Такое впечатление, что кто-то намеренно напакостил. Основы виртуализации были известны ещё 10 лет до того даже в том тупейшем варианте, который у Попек+Гольдберг (что для современной виртуализации как машина Тьюринга с её ленточкой).
N>Противоестественные реализации некоторых команд. Почему для BSF, BSR ставится ZF, против логики, что он должен ставиться по нулю _результата_, а не источника? Почему не сделать запись какого-нибудь -1 если источник — ноль?
N>CPUID надо было ввести ещё в 186 хотя бы в виде реализации как NOP (а потом добавлять реальные действия), если вообще началось развитие и различие версий.
N>Я уж не вспоминаю, что там уже явно были видны проблемы параллеления декодера, и сделать оформление длины команды в явном виде существенно бы облегчило работу. Но будем предполагать, что это бы они не потянули.
N>Я всё о таких вещах. Все они — нежелание подумать дальше полшага вперёд и сделать так, чтобы себе же было удобно не только в текущей версии, но и чуть-чуть позже... Но нет, "в своём гамаке я желаю полноценно трахаться на лыжах" (c). Фантастическое невежество и бескультурье там, где приложив чуть-чуть ума можно было получить значительно более качественный результат.
Все, в общем, верно. Но в основном совместимость. Ну что прикажешь делать с теми же CLI/STI ? В 86 один код, а в 386 другой ? А SGDT вроде как еще от 286 пришла, и там был какой-то резон ее сделать непривилегированной. А может, и не было. Не подумали.
А в целом — типичное "развивающее" решение. Это когда не делают как следует с нуля, а делают с оглядкой на предыдущие решения. Конечно, многое можно было сделать лучше. Но сама архитектура отнюдь не плоха, а это все же мелочи.
С другой стороны, когда Intel попробовала сделать с нуля "как следует" — получился Itanium.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну тут я могу еще кое-что добавить. BCD операции, например. Но тогда они казались нужными, да и, видимо, совместимость с 8080 требовалась.
Нет, ну для периода примерно до Pentium они ещё имели какой-то смысл. Потом уже оказалось, что делать то же самое на бинарке крупными порциями (хотя бы по 2-3 цифры) уже выгоднее.
N>>- Почему в page table entry один бит на права на страницу, а не два согласно режимам? Они этим самым с ходу убили rings 1 & 2 даже для тех, кто хотел и мог их осмысленно использовать. PD>Потому что механизмы от 286 оказались ненужными. Фактически весь механизм защиты и адресации от 286 в 386 аннигилирован. Он остается, как же иначе, но по сути роли не играет, его программируют так, чтобы не мешал. А реально защита идет на страничном механизме. PD>Вспомни, зачем сделали 4 кольца. 0-е для ядра ОС, 1- для драйверов, так что их падение не приведет к падению ОС. 2- например, для DB engine. Ну и 3. И никто не стал в 286 процессоре это использовать. Равно как никто не стал использовать задачи процессора и переключение LDT. Идея оказалась невостребованной.
В 286 — по другой причине, что он сам был какой-то убогий и переходной — попытка фактически реанимировать iAPX432 поверх 8086.
А посмотри на VAX. Там 4 кольца используются на полную. Или сейчас на ARM, то же самое (с поправкой, что одно из них это гипервизор) и плюс по другой оси ещё "реалмы". Или на RISC-V, там три кольца плюс резерв для гипервизора (но они в итоге сделали иначе и PL2 просто не нужен).
А сами Intel сделали SMM, который по их нумерации получается номер -1.
Ну так стоило ли так грубо и тупо вырезать? Что, одного бита в свободной области было жалко? Там до сих пор есть резерв.
N>>- Почему для ring 0 форсирован маппинг? Ему это нафиг не надо, у него и так права на доступ ко всему физическому адресному пространству. PD>Это не понял. Что за форсирование маппинга ?
Всё просто. Если ты посмотришь на такую пачку архитектур, как MIPS, POWER, и даже SystemZ, то там можно (а в некоторых (было) обязательно), что в режиме супервизора маппинг (трансляция) виртуальных адресов в физические просто идемпотентна! То есть этот уровень работает в физических адресах. Ну просто нафиг ему не сдалось заниматься ещё и тем, что самому себе обеспечивать страничные каталоги, искать где их размещать и как правильно управлять, чтобы самому себе не вышибить почву из-под ног...
Если то, что называется Software-Managed Address Translation (гуглится, куча работ), то в этом случае все эти страничные каталоги и подкаталоги просто не существуют — это случай MIPS. Там супервизор командует напрямую кэшом трансляций (translation lookaside buffer (TLB) у большинства включая Intel). Но (у SystemZ) иерархия страничных каталогов в памяти, но супервизору трансляцию обычно отключают.
А у x86 эта трансляция если включена, то принудительно на всех. В результате получается куча костылей. Ты видел, как инициализируются современные ОС?
В одном из вариантов (очень долго был основным) сначала надо в нижнем мегабайте создать хотя бы один корневой каталог и один подкаталог 0 (первые 4MB в 32 битах). Именно там — потому, что до верхней памяти не добраться.
И они создаются с идемпотентной трансляцией.
Далее когда уже включили — можно сменить на другой каталог (а их надо делать для каждого процесса свой, если процесс не чисто ядерный).
Если надо перейти в реальный режим — тоже два этапа: сначала ужаться каталогами (а также GDT) в первый мегабайт, идемпотентно, и тогда отключать.
Сейчас больше используют unreal mode на 4GB и это не нужно в таком виде, больше свободы. Но чтобы переключиться потом в 64 бита, всё равно нужен ещё один прыжок режима.
И это я только про то, что видно процессору. А ещё надо структуры для самой ОС, где расписано, где она держит эти каталоги. И эти структуры тоже надо где-то держать. Если фиксированного места на них не хватает, задача становится ой нетривиальной — надо сделать так, чтобы собственные же структуры не затереть, не сдвинуть, если нельзя...
Пока писал, вспомнил ещё один момент. В Intel его тоже могли знать, потому что уже был VAX в полную силу доступен. Корневой каталог страниц свой на каждый процесс. Но если меняется маппинг для ядерной половины, его надо менять у всех процессов, на это есть особый контроль при переключении процесса. Что мешало сделать раздельные корневые каталоги хотя бы на две половины адресного пространства, и верхнюю не менять лишний раз? В VAX таких каталогов 4. В ARM сделали два каталога и управляемую границу между ними. Зачем x86 создал трудности на ровном месте?
PD>Все, в общем, верно. Но в основном совместимость. Ну что прикажешь делать с теми же CLI/STI ? В 86 один код, а в 386 другой ?
Нет. В 16-битном режиме (неважно, 8086, 386, Corei14...) один. В 32-битном (начиная с 386) другой. В 64-битном, возможно, третий.
Между ними и так существенная разница, и сделать различие в кодогенераторе и в декодере — только добавить к уже существующему.
PD> А SGDT вроде как еще от 286 пришла, и там был какой-то резон ее сделать непривилегированной. А может, и не было. Не подумали.
Я 101% уверен, что просто не подумали.
PD>А в целом — типичное "развивающее" решение. Это когда не делают как следует с нуля, а делают с оглядкой на предыдущие решения. Конечно, многое можно было сделать лучше. Но сама архитектура отнюдь не плоха, а это все же мелочи.
Ну _в общем и целом_, да, она не худшая. У неё достаточно гибкости, чтобы ещё конкурировать. Но при этом количество костылей, подпорок, ненужных и заброшенных частей ужасает.
PD>С другой стороны, когда Intel попробовала сделать с нуля "как следует" — получился Itanium.
Там другая история. Я уверен, что кому-то из топов хотелось, опять же, выстебнуться и зайти в историю. Иначе не объяснить, как заведомо нерабочая изначально концепция могла пойти в железо. А почему кто-то мог подумать, что она рабочая — потому что история с Rambus, которые пообещали избавление от основных причин, почему вообще нужен out-of-order.
Здравствуйте, netch80, Вы писали:
N>А посмотри на VAX. Там 4 кольца используются на полную. Или сейчас на ARM, то же самое (с поправкой, что одно из них это гипервизор) и плюс по другой оси ещё "реалмы". Или на RISC-V, там три кольца плюс резерв для гипервизора (но они в итоге сделали иначе и PL2 просто не нужен).
А они реально используются ? Драйверы там отделены от ОС ? Если нет — то для чего используются ?
N>А сами Intel сделали SMM, который по их нумерации получается номер -1.
Это да. Но это нельзя было реализовать в рамках Ring3-0, не получилось бы compatibility с 286.
N>Всё просто. Если ты посмотришь на такую пачку архитектур, как MIPS, POWER, и даже SystemZ, то там можно (а в некоторых (было) обязательно), что в режиме супервизора маппинг (трансляция) виртуальных адресов в физические просто идемпотентна! То есть этот уровень работает в физических адресах. Ну просто нафиг ему не сдалось заниматься ещё и тем, что самому себе обеспечивать страничные каталоги, искать где их размещать и как правильно управлять, чтобы самому себе не вышибить почву из-под ног...
N>Пока писал, вспомнил ещё один момент. В Intel его тоже могли знать, потому что уже был VAX в полную силу доступен. Корневой каталог страниц свой на каждый процесс. Но если меняется маппинг для ядерной половины, его надо менять у всех процессов, на это есть особый контроль при переключении процесса. Что мешало сделать раздельные корневые каталоги хотя бы на две половины адресного пространства, и верхнюю не менять лишний раз? В VAX таких каталогов 4. В ARM сделали два каталога и управляемую границу между ними. Зачем x86 создал трудности на ровном месте?
Все логично. Но это еще один регистр типа CR3. А граница, вообще говоря, нигде в 386 не фиксирована, это уже потом в Windows, скажем, 2:2 или 3:1. Более того, формально ее просто нет, совсем нет деления на 2 части. Так что пришлось бы по каждому адресу делать проверки, нужно ли его транслировать или нет, и если да, то через какой каталог. В общем, это некоторое усложнение, и , видимо, они решили сделать проще.
И еще вот что учти. В этих ARM и VAX нет никаких GDT/LDT, а тут надо было сделать, чтобы соответствовало требованиям сегментного механизма. Никто не стал делать ОС в формате 16:32, но вообще-то ее сделать было можно, и не могла фирма не обеспечить это. Представь себе, что кто-то бы сделал ОС, в которой небольшие сегменты Ring0 лежат в 32-битном пространстве вперемежку с сегментами Ring3 — в общем, 32-битный вариант Windows 3.1...
Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
PD>>С другой стороны, когда Intel попробовала сделать с нуля "как следует" — получился Itanium.
N>Там другая история. Я уверен, что кому-то из топов хотелось, опять же, выстебнуться и зайти в историю. Иначе не объяснить, как заведомо нерабочая изначально концепция могла пойти в железо. А почему кто-то мог подумать, что она рабочая — потому что история с Rambus, которые пообещали избавление от основных причин, почему вообще нужен out-of-order.
Вот с этим объяснением не согласен. Itanium делали же Intel вместе с HP. В обеих компаниях топам захотелось ?
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>А посмотри на VAX. Там 4 кольца используются на полную. Или сейчас на ARM, то же самое (с поправкой, что одно из них это гипервизор) и плюс по другой оси ещё "реалмы". Или на RISC-V, там три кольца плюс резерв для гипервизора (но они в итоге сделали иначе и PL2 просто не нужен).
PD>А они реально используются ? Драйверы там отделены от ОС ?
Ты о ком именно?
VAX? Да, отделены.
ARM? У Apple — да, но другими механизмами (те драйверы, что отделены, фактически user level). А дополнительные уровни — на гипервизора (понятно, почему отдельно) и EL3 — это близко к SMM в x86: суперпривилегированный уровень, который знает аппаратные тонкости. Вообще из-за secure mode и реалмов их сравнивать напрямую не получится.
Но в итоге то, что "драйвер", может быть разделено между всеми уровнями.
PD>Все логично. Но это еще один регистр типа CR3.
Да.
PD> А граница, вообще говоря, нигде в 386 не фиксирована, это уже потом в Windows, скажем, 2:2 или 3:1.
Вот и зафиксировали бы хотя бы на 1:1.
PD> Более того, формально ее просто нет, совсем нет деления на 2 части. Так что пришлось бы по каждому адресу делать проверки, нужно ли его транслировать или нет, и если да, то через какой каталог. В общем, это некоторое усложнение, и , видимо, они решили сделать проще.
Скорее "быстро". Проще для железячников, да — ценой серьёзного усложнения для софта. Причём упрощение для железа небольшое, а вот усложнение для софта — серьёзное.
PD>И еще вот что учти. В этих ARM и VAX нет никаких GDT/LDT, а тут надо было сделать, чтобы соответствовало требованиям сегментного механизма.
Нет, конечно. Страничный и сегментный механизм в 386 никак не связаны. Даже тот факт, что страничный не включается без защиты, это просто волюнтаристское решение. Его можно было спокойно включать без защищённого режима, и это тоже бы работало.
Где есть связь — это в IBMовских SystemZ и POWER. Там в обоих одинаково (понятно, почему) аналог селектора сегмента используется для выбора конкретного корня страничной трансляции (из до 2^16 вариантов, что перегиб — реально редко кто использует больше 2). Вот если бы Intel подумал в эту сторону — было бы интереснее. Но они сделали так, что уже в 386 вся эта сегментация стала использоваться только для указания левых параметров типа в какой битности мы сейчас будем работать.
PD> Никто не стал делать ОС в формате 16:32, но вообще-то ее сделать было можно, и не могла фирма не обеспечить это. Представь себе, что кто-то бы сделал ОС, в которой небольшие сегменты Ring0 лежат в 32-битном пространстве вперемежку с сегментами Ring3 — в общем, 32-битный вариант Windows 3.1...
Я не понял, что именно мне представлять. Это явно уже было: в случае запуска 16-битных приложений в 32-битной среде, как нативных Windows, так и в DOS-режиме. Но от этого, как известно, старались быстро уйти ("быстро" это 5-10 лет, со стандартной инерцией IT).
PD>Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
Я тоже до такой степени не помню. Но вижу, что, например, 64-битный длинный режим нельзя включить в один заход: надо перейти сначала в 32 и потом переключаться флажком, который находится именно в CS (в его подробностях в GDT). А переключение в стиле loadall больше не делают.
Но интересно увидеть таки ссылку.
PD>>>С другой стороны, когда Intel попробовала сделать с нуля "как следует" — получился Itanium.
N>>Там другая история. Я уверен, что кому-то из топов хотелось, опять же, выстебнуться и зайти в историю. Иначе не объяснить, как заведомо нерабочая изначально концепция могла пойти в железо. А почему кто-то мог подумать, что она рабочая — потому что история с Rambus, которые пообещали избавление от основных причин, почему вообще нужен out-of-order.
PD>Вот с этим объяснением не согласен. Itanium делали же Intel вместе с HP. В обеих компаниях топам захотелось ?
Причины могли быть разные. HP — например, чтобы сохранить инвестиции в уже сделанные и кое-как работавшие наработки, и надежда на долгое плодотворное сотрудничество со вполне себе сделавшим имя успешным партнёром. А вот для Intel попытка рывка в неизведанное — призрачный шанс вполне мог застить очевидные соображения.
Здравствуйте, netch80, Вы писали:
PD>> А граница, вообще говоря, нигде в 386 не фиксирована, это уже потом в Windows, скажем, 2:2 или 3:1.
N>Вот и зафиксировали бы хотя бы на 1:1.
PD>>И еще вот что учти. В этих ARM и VAX нет никаких GDT/LDT, а тут надо было сделать, чтобы соответствовало требованиям сегментного механизма.
N>Нет, конечно. Страничный и сегментный механизм в 386 никак не связаны. Даже тот факт, что страничный не включается без защиты, это просто волюнтаристское решение. Его можно было спокойно включать без защищённого режима, и это тоже бы работало.
N>Я не понял, что именно мне представлять. Это явно уже было: в случае запуска 16-битных приложений в 32-битной среде, как нативных Windows, так и в DOS-режиме. Но от этого, как известно, старались быстро уйти ("быстро" это 5-10 лет, со стандартной инерцией IT).
Соединил твои ответы, чтобы дать один свой
Страничный и сегментный механизмы связаны, и вот как
Адрес-то формально 48 битный, то есть 16:32. Другое дело, что реально 0:32, то есть flat model. Ну а если все же кто-то решил бы делать адресацию на 16:32 ? Не запретишь.
Вот смотри. Упоминаю CS, но может быть любой сегментный регистр. Для простоты считаю, что все они идут через LDT
CS1 base = 0, limit = 1 MB, ring 0
CS2 base = 1MB limit = 1 MB, ring 3
CS3 base = 2MB limit = 1 MB, ring 0
CS4 base = 3MB limit = 1 MB, ring 3
и т.д.
Могу я так запрограммировать LDT ? Имею право.
В итоге в линейном пространстве лежат куски по 1 MB . Права в страничном механизме — первый должен быть S, второй U, третий S, четвертый U и т.д.
А еще учти, что можно завести
CS5 base = 0, limit = 1 MB, ring 3
то есть тот же самый, что и CS1, но ring3.
Так что зафиксировать деление 32-битного на 2 части просто нельзя. Когда нет этого сегментного механизма — тогда мы изначально имеем дело с 32-битным пространством, в нем правило деления на части можно определить, а тут, увы...
PD>>Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
N>Я тоже до такой степени не помню. Но вижу, что, например, 64-битный длинный режим нельзя включить в один заход: надо перейти сначала в 32 и потом переключаться флажком, который находится именно в CS (в его подробностях в GDT). А переключение в стиле loadall больше не делают. N>Но интересно увидеть таки ссылку.
Увы, где-то прочитал, где- не помню, так что ссылку дать не могу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Соединил твои ответы, чтобы дать один свой PD>Страничный и сегментный механизмы связаны, и вот как PD>Адрес-то формально 48 битный, то есть 16:32. Другое дело, что реально 0:32, то есть flat model. Ну а если все же кто-то решил бы делать адресацию на 16:32 ? Не запретишь.
Да нету там адресации 16:32.
Было 2^14 (два бита ушли на RPL) сегментов умножить на 2^32 адресов, и тут же из них сделали один 32-битный "линейный", в котором вся информация о том, какой сегмент использовался, тупо выброшена. Всё, её нету. И уже из этих 32 бит линейного делают 32 бита физического независимо от того, какой сегмент это был.
Или даже если делается 36 бит физического (PSE36), то всё равно из 32 логических.
Или если page fault, то информация о сегментации потеряна, обработчик page fault тоже ничего не знает, из какого сегмента это пришло. Даже если бы он восстановил это разбирая команду, на которой фолт, то в TLB он не сможет ничего занести.
Поищи видео по словам "lost in mirror maze". Вот этот самый лабиринт зеркал — это максимум, что у тебя получится. До 2^14 отражений кусков одного и того же пространства.
Поэтому это просто красивый пшик...
Опять же, сравни с SystemZ — где сделано без потери данных. Есть address space number (ASN) — параметр: для юзерского приложения равен 1 — primary (для 99% обычных приложений только оно используется), 2 — secondary, >=3 — прочие. Есть методы (хоть местами странные) систематически ходить через другой ASN. У каждого ASN своё дерево страничных каталогов. И когда лукап отработан железом, то ASN выбирает, какой физический адрес страницы. А если ушло в обработчик (страницы нет, писать нельзя, и т.п.), обработчик получает напрямую, какой ASN был, и может в зависимости от этого подключить что ему угодно и как ему угодно, и в TLB эта информация сохраняется. Вот это уже действительно честное виртуальное 47-битное пространство (16:31) в S/370...S/390, и 80-битное (16:64) в z/Architecture (расширенная до 64).
(Почему 31, а не 32, позволялось для адреса — я не нашёл с ходу, потом надоело искать. По сути неважно.)
PD>CS1 base = 0, limit = 1 MB, ring 0 PD>CS2 base = 1MB limit = 1 MB, ring 3 PD>CS3 base = 2MB limit = 1 MB, ring 0 PD>CS4 base = 3MB limit = 1 MB, ring 3
[...]
PD>Так что зафиксировать деление 32-битного на 2 части просто нельзя.
Не просто можно, а это постоянно и делали. Если у тебя все страницы со старшим битом линейного адреса равным 0 (если вообще существуют) имеют права доступа пользователя, а 1 — супервизора. Сейчас в 64 битах повторяется то же самое с поправкой на используемую длину виртуального (линейного) адреса (48 или 57 бит).
А то, что ты показал считалочку с сегментами — "перемножается" на это: имеют значение в итоге минимальные права из двух источников. Если тебе дали сегмент с правом доступа юзера (ring 3) но на адрес, через страничный механизм доступный только супервизору (считаем, ring 0) — всё, доступа нет.
Да, эта сегментная хрень по факту легаси и уже не использовалась никем в здравом уме и твёрдой памяти — именно поэтому AMD в long mode просто вырубило нафиг это, ничего не потеряв. Да, у дескриптора остаётся DPL, которое задаёт, с какими правами вообще это исполнять (kernel vs. user), и L (исполнять в 32 или 64 битах). Остальные бесполезны.
И при наличии прав доступа через страницы такие же механизмы для не-кодовых сегментов вообще теряют смысл — поэтому в реальных ОС в long mode в DS/ES/SS грузится одно и то же значение — "всем всё можно". (Базовый адрес и длину там и так процессор игнорирует.)
PD> Когда нет этого сегментного механизма — тогда мы изначально имеем дело с 32-битным пространством, в нем правило деления на части можно определить, а тут, увы...
См. выше. При правах доступа по страницах, доступных в принципе (i386 и далее) или единственно оставшихся (amd64) — это уже бесполезно или недоступно. Ну а то, что сегментация показывает внутрь того же адресного пространства, и делает её бесполезной.
PD>>>Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
PD>Увы, где-то прочитал, где- не помню, так что ссылку дать не могу.
Меня в этом удивило именно то, что "с виртуальными машинами".
В этой архитектуре битность режима выполнения определяется тем, что загружено согласно селектору в CS — в соответствующем месте в памяти в слове было указание, 16 или 32. Ломать этот механизм совсем было бессмысленно. Поэтому на него же нагрузили включение 64-битного режима, и это выглядит достаточно оптимальным — в пределах уже сделанного извращения
А вот с виртуальными машинами важнее, думаю, только то, что раз в них исполняются системы любой древности (хоть PC-DOS 1.0), то должно было работать всё, что поддерживали предыдущие процессоры. Но это и так примерно очевидно.
Здравствуйте, netch80, Вы писали:
N>Поэтому это просто красивый пшик...
Ну не совсем. Да, в итоге будет 32 бита. Но limit в дескрипторе не отменен, и если он не 4Г, то нарвешься не на page fault, а на general protection fault. А так да, в итоге 4 Г, конечно
PD>>CS1 base = 0, limit = 1 MB, ring 0 PD>>CS2 base = 1MB limit = 1 MB, ring 3 PD>>CS3 base = 2MB limit = 1 MB, ring 0 PD>>CS4 base = 3MB limit = 1 MB, ring 3
N>[...]
PD>>Так что зафиксировать деление 32-битного на 2 части просто нельзя.
N>Не просто можно, а это постоянно и делали. Если у тебя все страницы со старшим битом линейного адреса равным 0 (если вообще существуют) имеют права доступа пользователя, а 1 — супервизора. Сейчас в 64 битах повторяется то же самое с поправкой на используемую длину виртуального (линейного) адреса (48 или 57 бит).
Это если со старшим. А если сегменты как я нарисовал, то так не получится.
N>А то, что ты показал считалочку с сегментами — "перемножается" на это: имеют значение в итоге минимальные права из двух источников. Если тебе дали сегмент с правом доступа юзера (ring 3) но на адрес, через страничный механизм доступный только супервизору (считаем, ring 0) — всё, доступа нет.
Насчет доступа — согласен, а в остальном все остается. Лежат себе в 32-битном пространстве 1 Мб куски с правами S и U вперемежку. Почему лежат — а так LDT настроили. И не получится никакого разделения АП на U/S части. А запретить нельзя.
N>Да, эта сегментная хрень по факту легаси и уже не использовалась никем в здравом уме и твёрдой памяти — именно поэтому AMD в long mode просто вырубило нафиг это, ничего не потеряв. Да, у дескриптора остаётся DPL, которое задаёт, с какими правами вообще это исполнять (kernel vs. user), и L (исполнять в 32 или 64 битах). Остальные бесполезны.
Конечно, не использовалась. Но не могла фирма Intel не дать возможность ее использовать. Даже если понимала, что никому не понадобится — все равно обеспечить возможность должна была дать.
N>См. выше. При правах доступа по страницах, доступных в принципе (i386 и далее) или единственно оставшихся (amd64) — это уже бесполезно или недоступно. Ну а то, что сегментация показывает внутрь того же адресного пространства, и делает её бесполезной.
Бесполезно — да. А обеспечить работу были обязаны. А ну как все же кто-то решит использовать не flat, а как я написал.
PD>>>>Другое дело, что вообще-то можно было совсем отказаться от сегментных регистров в 32 битном режиме. Кстати, где-то я читал, что при переходе к 64-битному от них хотели отказаться, но возникли какие-то проблемы с виртуальными машинами. Пруф не дам.
PD>>Увы, где-то прочитал, где- не помню, так что ссылку дать не могу.
N>Меня в этом удивило именно то, что "с виртуальными машинами".
Вот это я точно помню. Помню (не дословно) и текст. Примерно так — хотели отказаться от сегментных регистров, но разработчики виртуальных машин столкнулись с непреодолимыми трудностями.
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Поэтому это просто красивый пшик...
PD>Ну не совсем. Да, в итоге будет 32 бита. Но limit в дескрипторе не отменен, и если он не 4Г, то нарвешься не на page fault, а на general protection fault. А так да, в итоге 4 Г, конечно
Формально, GPF — это термин Windows, и распространяется он на оба случая. В процессоре есть разница между #GP (13) и #PF (14). Но это я уже придираюсь к терминам.
Но важнее тут именно то, что при наличии страничной защиты, и активном нежелании программистов бодаться со сложной структурой адресации (вместо одной плоской) — этот механизм тут же перестал использоваться, как только появилась первая возможность. В книгах по тому, как переходить с программирования под Win16 — под Win32, это было написано английским (или переведённым) по фоновому много раз.
N>>Не просто можно, а это постоянно и делали. Если у тебя все страницы со старшим битом линейного адреса равным 0 (если вообще существуют) имеют права доступа пользователя, а 1 — супервизора. Сейчас в 64 битах повторяется то же самое с поправкой на используемую длину виртуального (линейного) адреса (48 или 57 бит). PD>Это если со старшим. А если сегменты как я нарисовал, то так не получится.
Так сегменты в таком виде немедленно перестали использовать. Кому оно такое нужно?
А схема "старшая половина — супервизору" — не знаю кто первый придумал, но в VAX она была закреплена в железе. (Точнее, там было просто 3 квадранта (один в резерве) и каждый под любое, и формально могли их переставить наоборот, но никто так не делал.) А вслед за ним это начали делать чуть менее чем все.
N>>А то, что ты показал считалочку с сегментами — "перемножается" на это: имеют значение в итоге минимальные права из двух источников. Если тебе дали сегмент с правом доступа юзера (ring 3) но на адрес, через страничный механизм доступный только супервизору (считаем, ring 0) — всё, доступа нет.
PD>Насчет доступа — согласен, а в остальном все остается. Лежат себе в 32-битном пространстве 1 Мб куски с правами S и U вперемежку. Почему лежат — а так LDT настроили. И не получится никакого разделения АП на U/S части. А запретить нельзя.
Неее, ну так можно и на страничной схеме сделать. Вот устроим чередование, что каждый следующий мегабайт — другого доступа. Можно? Можно, DAT с его каталогами страниц по 4KB такое позволяет в полный рост. Но зачем? Опять троллейбус из буханки?
Во многих версиях ОС, на самом деле, к супервизору относилась не только старшая половина, но и первые (индекс 0) 4MB. Потому что 1) было удобно идемпонентно отражать первый мегабайт, у которого спец. функции, 2) удобно делать это цельным подкаталогом, 3) NULL должен был давать исключение. Но потом от этого в основном ушли.
Так что, повторюсь, можно. И даже удобнее, если вдруг кому надо, это делать на страничном механизме, чем на сегментации. Но — в обоих никому не нужно. Вот сегментация и умерла.
N>>Да, эта сегментная хрень по факту легаси и уже не использовалась никем в здравом уме и твёрдой памяти — именно поэтому AMD в long mode просто вырубило нафиг это, ничего не потеряв. Да, у дескриптора остаётся DPL, которое задаёт, с какими правами вообще это исполнять (kernel vs. user), и L (исполнять в 32 или 64 битах). Остальные бесполезны.
PD>Конечно, не использовалась. Но не могла фирма Intel не дать возможность ее использовать. Даже если понимала, что никому не понадобится — все равно обеспечить возможность должна была дать.
Реально они могли отменить это не на 64 битах (как AMD позже), а уже на 32. Но на это им не хватило решительности.
N>>Меня в этом удивило именно то, что "с виртуальными машинами".
PD>Вот это я точно помню. Помню (не дословно) и текст. Примерно так — хотели отказаться от сегментных регистров, но разработчики виртуальных машин столкнулись с непреодолимыми трудностями.
Здравствуйте, netch80, Вы писали:
N>Так сегменты в таком виде немедленно перестали использовать. Кому оно такое нужно?
Да я разве спорю, что нужно ? Не в этом же вопрос. А в том, что коль уж сделали так, то пришлось обеспечить возможность такого, даже если и не нужно.
N>Неее, ну так можно и на страничной схеме сделать. Вот устроим чередование, что каждый следующий мегабайт — другого доступа. Можно? Можно, DAT с его каталогами страниц по 4KB такое позволяет в полный рост. Но зачем? Опять троллейбус из буханки?
Ну чередование — это просто мой пример. Можно еще 100500 других вариантов предложить. Суть-то простая — при наличии сегментного механизма и сегментов произвольного размера невозможно "в железе" зафиксировать правила деления АП на U и S. Вот им и пришлось делать одинаковые правила трансляции адресов по страничному механизму для U и для S
N>Так что, повторюсь, можно. И даже удобнее, если вдруг кому надо, это делать на страничном механизме, чем на сегментации. Но — в обоих никому не нужно. Вот сегментация и умерла.
Тут спорить я никак не могу.
PD>>Вот это я точно помню. Помню (не дословно) и текст. Примерно так — хотели отказаться от сегментных регистров, но разработчики виртуальных машин столкнулись с непреодолимыми трудностями.
N>Если найдёте откуда, прошу закинуть сюда.
Здравствуйте, Pavel Dvorkin, Вы писали:
N>>Неее, ну так можно и на страничной схеме сделать. Вот устроим чередование, что каждый следующий мегабайт — другого доступа. Можно? Можно, DAT с его каталогами страниц по 4KB такое позволяет в полный рост. Но зачем? Опять троллейбус из буханки?
PD>Ну чередование — это просто мой пример. Можно еще 100500 других вариантов предложить. Суть-то простая — при наличии сегментного механизма и сегментов произвольного размера невозможно "в железе" зафиксировать правила деления АП на U и S. Вот им и пришлось делать одинаковые правила трансляции адресов по страничному механизму для U и для S
Ну это уже чистое "сгорел сарай, гори и хата". Если у старого механизма проблемы, то зачем усиливать от этого проблемы на новом?
Впрочем, вопрос риторический, и можно не продолжать эту тему.
PD>>>Вот это я точно помню. Помню (не дословно) и текст. Примерно так — хотели отказаться от сегментных регистров, но разработчики виртуальных машин столкнулись с непреодолимыми трудностями. N>>Если найдёте откуда, прошу закинуть сюда. PD>Если найду — обязательно. Но вряд ли найду.
Здравствуйте, rm2, Вы писали:
rm2>Рыночная капитализация на текущий момент в 2.7 раза меньше чем у аmd (82 vs 222). rm2>Идут активные слухи о разделении компании и продаже по частям.
Здравствуйте, rm2, Вы писали:
rm2>https://www.ixbt.com/news/2024/09/06/intel-50-qualcomm.html
rm2>Как то это прямо так скажем совсем не то что я лично хотел. Я бы хотел чтобы amd intel догнала, и дальше они в каком то разумном соотношении аля 50 на 50 конкурировали друг с другом.
ну а они же любят "по горячее", поэтому им и 120 градусов на проце норм
