>Вах. Аппаратное переименование регистров появилось аж в Pentium-е, если мне склероз не
>изменяет,А это не переименование, это использование напристальной памяти как general-purpose регистров, с честной адресацией блока регистров указателем на область. Сравнили, блин, от интеля костыли и красивую реализацию неймановской концепции по максимуму.
>С какого это перепугу?
С такого что наличие реального адреса в памяти у регистров - не очень общее свойство для CPU, например.
>Бла-бла-бла. Понимаете, разница между мной и вами в том, что у меня
>был курс микроэлектроники и я умею пользоваться калькулятором,
ИМХО, благородный дон шибко самоуверен.
>а у вас всего этого не было.
У вас по-моему был и есть разве что апломб и гонор. А у меня оно не просто было - были и весьма прозорливые учителя. Как вам например предсказание что сериальные шины вытеснят параллельные сделанное в эпоху когда PCI (вполне себе параллельный) только-только появился?Некоторые, черт возьми, хорошо рубят в своем ремесле: спустя немало лет можно наблюдать как их предсказания постепенно воплощаются в реальном железе.Судя по вашим постам не всем везло так же...
>Давайте посчитаем, сколько же памяти занимает контекст. Забегая вперёд скажу что в
>самом распоследнем Core i7 всего 32K L1 кеша данных,
Мля, вот упертый тип то. Привязался к своему сраному х86 и дальше видеть ничего не хочет. Давайте, молитесь на интель :)
>быстрой памяти с низким latency у нас всего кот наплакал.
Ну и конечно же совершенно банальные инженерные трюки (как то хранение только часто используемых вещей типа general purpose регистров - ну редко, блин, системные дела нуждаются в FPU по большому счету) и перераспределение вентилей в пользу того или сего автору представить слабо.Зато пальцы растопыривать умеет.Так и запишем - протирал портки в каком-то учебном заведении.Зачем протирал - хрен бы его знает: думать своим мозгом его там не научили.
>Но давайте посчитаем размер контекста:
Вы, имхо, безнадежны. Вы считаете что в мире есть только х86 и что надо делать только так и баста. А теперь вот вам пуля в лоб: целью вроде был быстрый переход между состояниями для удобства микроядерной ос. Вопрос: ну и напуркуа системным делам контексты SSE и FPU? Они ими часто и много пользуются? Прямо в каждом системном процессе?!? Нет?! Ну так зачем их тогда хранить для каждой задачи, выжирая под них вагон скоростной оперативы? Потому что вас в вашем вузе думать не научили? oO
А вот например 16х64 регистров в те же 32К можно понапихать о-го-го... у вас активных потоков в системе заметно меньше, пожалуй. Т.е. грубый прикидон показывает что идея как раз вполне катит даже если не отращивать память сильно жирнее :).Хотя в случае такого дизайна имело бы смысл ее увеличить, откусив немного от мегабайтов L2 а то и L3, жрущих под себя немеряно площади кристалла.
>тобишь только один контекст уже занимает 508b. Тобишь в L1 кеш влезет
>аж 64 контекста, а ведь там ещё данные хранить нужно.
1) 64 контекста довольно неплохо. У вас в системе более 64 процессов активно переключаются между собой?
2) Я честно говоря не понял - нахрен таким макаром хранить данные всяких там побочностей типа SSE и FPU.
3) Более того - вы реально не способны представить себе ничего кроме х86 (наверное, это единственная архитектура которую вы знаете). Мой совет - посмотрите на еще несколько архитектур, мир на х86 не заканчивается.Зафиг ограничивать свои познания одним уродливым монстрилой с пачкой костылей и потом смотреть на остальной мир мир через это кривое зеркало?
> Добавьте в контекст каталоги страниц, чтобы за ними в память не лазить
>и не тормозить (одна PDPT, на которую cr3 указывает, занимает 512
>x 48bit = 3kb). В общем на такой идее можно смело ставить крест.
Ага, а если еще и дамп памяти для каждой задачи туда сохранять то и вообще пипец - даже контекст 1 задачи не втиснется. Ну и конечно же отличное такое мышление - на уровне "как бы эту идею прикрутить в известный мне х86 крап?!". Да, для х86 получается уныло. А зачем утыкаться в х86 и его проблемы? При разработке нового проца - свобода маневра полная. Чтобы понять насколько это может в итоге отличаться от "технологии начала 80 + много-много костылей к ним" можно допустим посетить http://www.xmos.com/ и (если мозга хватит) почитать даташиты на их добро(мне оно мозг вынесло неплохо, т.к. не похоже на то что я видел до этого). Чисто чтобы понять насколько проц в современной инкарнации, задизайненый с нуля может отличаться от говна надизайненого в начале 80 и обвешанного потом костылями по самые нидерланды по принципу "как вышло" и "чтобы было совместимо".
>Ещё раз - у немцев задача была на порядки проще.
Да.А я не знаю нахрен вы ее так старательно усложняете.Наверное, потому что "unable to think big" и поэтому не мыслите ничего кроме х86 и как бы к нему это прикрутить в виде стопервого костыля :)
>Ещё раз - 80C167, который конкурент 8051,
Угу, если 167 - конкурент 8051, тогда запор - конкурент поршу, однозначно:).Вообще-то это разные классы, x51 это в embedded по сути самый low end и свое почти отлетал (в новых разработках почти не используется, т.к. безбожно устарел а вопросы бинарной совместимости в новых разработках в embedded обычно никого не колебут). А 167 - это где-то серединка. Как бы х51 немного стушуется адресовать 16М памяти и быстро переключать задачи.
>поддерживал только основную программу
Основной программе ничто не мешает быть побитой на вагон задач между которыми быстое переключение - более того, 167 не то чтобы редко используется в системах с RTOS, ресурсов у него для этого предостаточно в отличие от 51 и он довольно удобен и для них и для компилера по своему устройству. И не вижу каких-то глобальных проблем запихать туда же program counter и регистр состояния (режим привилегий, etc).
> и два прерывания:
У 167 как бы вагон прерываний, IIRC...
>итого 3 контекста и в общей сложности < 48b на всё про всё.
Блин, скажите уж честно - вас в вашем вузе научили только тому как устроен всякий древний ископаемый крап типа х51, Z80 да x86. Так ведь? :)
>Вы просто с реальностью не дружите, вот и всё. Контекст в современном
>проце это намного больше чем десяток восьми битных регистров.
Ну да, конечно, если рассматривать все в контексте "а как бы эту кульную фичу к известному мне крапу х86 прикрутить" - и правда, возникают сомнения в дружбе с головой.Весь вопрос только в том - кто же с ней не дружит.ИМХО, тот кто хочет подобное прикручивать к х86, хранить контексты SSE и FPU и прочая :).Ну да, системный софт только и занимается что юзанием FPU и SSE :).Только вот в случае микроядра время жрет "распасовка" туда-сюда несколько раз между системными процессами и ядром - ну и напуркуа б им там SSE и FPU? Они ж должны быть простыми у тупенькими, by design.
> Даже если не учитывать каталоги страниц, то уже набегает пол килобайта, при этом
>их прийдётся вытаскивать из памяти и никакого одного такта не получится.
Угу, конечно, если подумать как сделать все максимально через жо, можно и придумать. У вас это получилось - я вас поздравляю, только вот я когда про это говорил - не имел в виду что это надо делать "ну совсем как в х86". Если бы по такому же принципу строили самолеты - это были бы кареты с крыльями :D
>Просто на практике это нереализуемо. Или вы думаете что разрабы добавляют L3
>кеш на много мегабайт просто из лени нарастить на столько же L1?
Нет, разумеется. Но, знаете, я не подразумевал что надо хранить все и вся таким макаром да еще сделав это как в х86.
>Потому что нет этой резвой локальной, а та что есть - мало.
А например у IBM в Cell есть 8 SPE и у каждого из SPE по 256 кило быстрой локальной памяти. Все это впихано на 1 кристалл.
>Вы в своих познаниях относительно архитектуры процессоров застряли в районе конца
>80-х начала 90-х.
Это вы наверное о себе - с вашими познаниями про архитектуру x86.Как раз было создано в начале 80-х и потом густо обвешивалось костылями.
>Давайте возьмём какой-нить RISC. У них регистров ещё больше и контекст занимает
>ещё больше.
Ну и пусть себе занимает, не так уж оно и много. А хранить всякие там SSE и подобное там же - идиотизм чистой воды, пардон. Хотя бы потому что системные процессы им не пользуются и стало быть ускорять оное в таком виде - нафиг не уперлось. А локальной памяти можно и побольше всобачить, если захотеть. Айбиэм вон захотели и впихали в свой целл по 256 кило на SPE.
>Можно всё сделать, если захотеть, только это никому не нужно будет,
А вот тут вы как ни странно правы - дело даже не в софте а в том что в большинстве применений микроядра никому нахрен не нужны, а там где все-таки нужны - рекордные скорости обычно не требуются. Ну вот и не заморачивается никто. Но если подумать как сделать удобный для микроядер проц не сливающий на переключении контекстов - можно и придумать. Только да, на хлам начала-середины 80-х как то х86 смотреть при этом не надо :)
>Ещё как принципиально. На размер контекста влияет.
Да, блин, если поставить себе сохранять в контексте ВСЕ И ВСЯ как вы это сделали - можно предложить еще и дамп памяти задачи туда сливать. Чтоб уж совсем не скромничать. А потом поныть что даже 1 задача не влезает :)))
>У меня сейчас на машинке запущено 245 процессов, сколько там потоков (тех
>самых execution context) - бог знает, считать лень. Тобишь уже места
>не хватает.
Гм, вообще, 254 наборов по 16х64 регистров (если уж не гнаться за хранением всего и вся и ориентироваться на скоростное переключение между системными процессами а не вообще хранение таким макаром всего и вся) - это менее 32К памяти. И уж ессно если городить такое - наверное надо выделить побольше чем 32Кб под это (предусмотрев на крайние случаи механизм отливающий редко юзаемые контексты в простую оперативку, etc). При том - такая механика не будет тупить при переключении контекстов до тех пор пока число активно работающих процессов помещается в такой "кэш" (при необходимости можно в принципе сливать наиболее редко используемые контексты в обычную RAM без какого-то чрезмерного ущерба). У вас часто в системе шпарят на всем ходу сотни процессов или хотя-бы тредов? Или большая их часть все-таки нихрена не делает большую часть времени а активно работает дай боже несколько десятков, которые как раз "забуферятся" и будут переключаться в момент? :)
>потому что это сделано, это работает, под это написано много кода.
А если б так конструировали самолеты - мы бы летали на каретах с крыльями. Упряжь (для сохранения совместимости с транспортировкой лошадью по взлетной полосе) была бы оставлена, хоть и безбожно портит аэродинамику. Где-то так, да? :)
>Делайте, кто вам мешает?
Отсутствие в этом какой либо необходимости. И даже не мне а много кому еще. Для начала пусть фаны микроядер расскажут - как они убедят юзерей что все это нужно. Но если допустить что микроядра все-таки нужны и озаботиться вопросом как сделать проц на котором микроядра не будут сильно сливать - может получиться что-то вот такое в первом приближении (мну просто подумал как сделать чтобы переключения контекстов были как можно более халявными по времени проца и даже накопал существующий дизайн проца наиболее похожий в этом плане на то что было надо).
