Компания Intel представила упрощённую процессорную архитектуру x86S (x86 Simplification), реализующую только 64-разрядный режим и избавленную от поддержки устаревших концепций. Поддержка 16- и 32-разрядных операционных систем в x86S прекращена, но их можно будет запускаться при помощи виртуализации. Возможность запуска 32-разрядных приложений в окружении 64-разрядной ОС сохранится...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59164
Dos будет портирован на 64 бита и совместимость со всеми программами нарушится. Но всё равно никто не использует DOS.
А вот страрые программы будут работать через трансляцию?
Насколько это упростит и поможет?
32-битные программы работать будут, 16-битные нет, но их по сути никто уже нативно и не запускает со времён 2000/XP и NTVDM.
> 16-битные нетОни и сейчас не работают если взять какую-то семёрку или десятку.
32 разрядную?
> 32 разрядную?А вот про это не могу сказать. Не приходилось использовать 32 разрядные семерки и десятки. Но здравый смысл подсказывает что предел для 32 разрядных систем - ХПшка. Хотя даже ХПшку я использовал 64 разрядную, как только появился в наличии 4 пень такой с поддержкой.
> Хотя даже ХПшку я использовал 64 разрядную, как только появился в наличии 4 пеньС ОЗУ в те времена было вроде не очень. 4 гига - предел мечтаний. Хотя могу и ошибаться.
> 4 гига - предел мечтаний.Я со вторым пнём и 512MB спокойно жил и не знал трудностей где-то до 2011 года, пока сайты вдруг не начали тяжелеть в геометрической прогрессии. 4 пень для меня, школьника а затем нищего студента, был пределом мечтаний, не говоря уж о "запредельном объёме" памяти более 1 гига))
Этот новый проц вновь поставит вопрос "память или такты" Под булеву переменную 64 бита даешь! )
> Этот новый проц вновь поставит вопрос "память или такты" Под булеву переменную
> 64 бита даешь! )Да он и 32 не сильно хуже будет. А так - да, вы знаете, адресовать "нативный" юнит памяти сильно быстрее чем выколупывать фрагмент из него, делая RMW. И условные операции могут быть быстрее. Ну там флагами проца допустим. Скажем not zero -> jump (1 условная инструкция в многих наборах команд). А теперь представь что вместо этого надо 15-й бит в 32-битном слове проверить, потому что булеан упаковали вот туда... это уже сколько команд проца будет?! Так что да, есть speed vs RAM tradeoff.
> вы знаете, адресовать "нативный" юнит памяти сильно быстрее чем выколупывать фрагмент
> из него, делая RMW.А на практике я взял двусвязный список, заменил указатели (64 разряда) на индексы (32 разряда). Это добавило лишнюю операцию при расчёте адреса. И дало выигрыш по скорости в 30% при работе с памятью в интерпретаторе, где такой список используется для хранения данных.
На самом деле на большом OoO проце с кешом, да еще с современным компилером где у оптимизатора свои идеи как он вооон то сделать хотел, все бывает довольно неоднозначно. Скажем эеономить RAM при гигазах вроде бы глупо. Но иногда можно получить прибавку перфоманса "потому что уместилось в кеш". Даже если вычислений и больше, из кеша они могут отработать быстрее. Более того, иногда -O3 с его unroll может все испортить, навернув более жирный код который перестал лезть в кеш или прогрузил собой шины.А конкретно в случае процов vs булеаны у некоторых бывают инструкции для работы с битами и битовыми полями. И вот так можно конкретные биты трогать/чекать и 1 командой. Что самое ироничное, в микроконтроллернах ARM их почему-то нет :)
> А теперь представь что вместо этого надо 15-й бит в 32-битном слове проверить,
> потому что булеан упаковали вот туда... это уже сколько команд проца будет?!на самом деле в даже в классической x86 архитектуре будет примерно одинаково.
в первом случае, если булевская переменная отдельно хранится, будет что-то типа:
cmp some_dword_bool, 1
jne not_oneво втором случае, если булевская переменная где-то там упакована, будет:
test some_bit_in_dword, 8000h
jz not_one
Только в первом варианте сравнение с 0м должно быть (0 или не 0).Второй вариант потенциально быстрее: если флаги упакованы, значит они нужны примерно в одно время; при доступе ко второму он уже в кеше.
> Только в первом варианте сравнение с 0м должно быть (0 или не 0).можно и так, всё-таки true, по-логике, тоже имеет только одно значение.
> Второй вариант потенциально быстрее: если флаги упакованы, значит они нужны примерно в
> одно время; при доступе ко второму он уже в кеше.там ещё надо потактовки смотреть, а лучше - во что это всё выльется для каждой из архитектур, с учётом uops и задействованных внутренних блоков. А то, например, сделали такую замечательную команду BEXTR, которая может битовое поле вытащить без сдвигов и масок, вот только оказалось, что быстрее она будет работать только на процессорах AMD, на Intel никакой пользы от неё нет[1].
А на чём смотреть потактовки? Раньше была утилита AMD CodeAnalyst - вот она после прогонки выполняла симуляцию конвейера и строила график, где каждая команда разбивалась на микрооперации. Рядом с прямоугольниками параллельно исполняющихся инструкций, где при замене инструкций разброс был в пару тактов, промахи кеша в сотню тактов выглядели очень печально. В uProf этого нет, а у intel никогда и не было (разработчик vTune объяснил мне в своё время, что это вообще не нужно).
> А на чём смотреть потактовки?как я понял, разработчики компиляторов пользуются табличками https://uops.info/table.html и сервисом godbolt.org (https://godbolt.org/z/zdktz_)
Ну, скажем, для ADC (R64, M64) указана латентность 1 и пропускная способность 2. Значит и для TEST столько же или лучше. В теории, процессор может выполнить две такие команды за такт. А на практике окажется промах кеша, процессор примется ждать, пока данные считаются из ОЗУ, и вообще переключится на второй поток HyperThreading. Потому чем компактнее данные расположены в памяти, тем они вероятнее окажутся в кеше, что потенциально лучше для скорости.
> Ну, скажем, для ADC (R64, M64) указана латентность 1 и пропускная способность
> 2. Значит и для TEST столько же или лучше. В теории,
> процессор может выполнить две такие команды за такт. А на практике
> окажется промах кеша, процессор примется ждать, пока данные считаются из ОЗУ,
> и вообще переключится на второй поток HyperThreading. Потому чем компактнее данные
> расположены в памяти, тем они вероятнее окажутся в кеше, что потенциально
> лучше для скорости.Вы можете сами провести эксперименты. В частности для исходных cmp vs test, при прочих равных, разницы не будет: https://godbolt.org/z/8Kc371aMK
С кешем всё так, но упаковка битов в слово может и наоборот, влиять отрицательно - когда биты между собой не связаны, тогда хождение за этими флагами сможет вытеснять другие данные из кеша и влиять на производительность уже других частей программы.
К сожалению, сейчас поисковики по запросу AMD CodeAnalyst pipeline simulation не выдали мне подходящих картинок, что бы можно было наглядно показать, о чём я говорю.Что CMP и TEST исполняются одинаково, как и большинство арифметико-логических команд (за исключением ADC/SBC) - это мне известно из IA Software Optimization Manual. Ключевой момент - "при прочих равных". Когда две такие команды стоят подряд и обращаются к одной ячейке (проверяют разные биты) - это один вариант. Когда они обращаются к разным - это другой вариант, здесь на второй команде потенциально будет загрузка линейки кеша из ОЗУ. godbolt тут не поможет. Что-то можно сделать утилитой perf, но локализовать проблемное место приходится методом тыка.
> когда биты между собой не связаны, тогда хождение
> за этими флагами сможет вытеснять другие данные из кеша и влиять
> на производительность уже других частей программы.Это верно, я не рассматривал такой вариант, поскольку это надо специально умудрится так написать.
> Только в первом варианте сравнение с 0м должно быть (0 или не 0).Кроме сравнений...
1) Флаг еще надо и выставить/очистить. Черт знает как в x86 а в ARM-подобных условный MOV r0, #1 будет коротко и эффективно. Это лобовая, немедленная операция, в тот же такт. А чтобы вот именно в 15 бите поменять надо RMW, явно не 1 immediate операция.
2) Это еще и взаимодействует с оптимизером и соседними сегментами кода. Скажем оптимизер типа LTO может реюзануть вгрузку тех или иных констант для чего-то совсем побочного и неслабо оптимизнуть посторонний код. С простыми константами в регистр это работает лучше чем сложным битовым словом. Если компилер точно знает что в r0 сейчас 1, он может использовать r0 для каких-то побочных вычислений где надо было константу 1 - полностью удалив загрузку регистра вот там, для их нужд. Если бы этого не было - он бы конечно честно оформил, но раз оно есть, то может быть реюзнуто. В этом весь смысл глобальной оптимизации типа LTO и состоит.
Мне в 2007 году перестало хватать п3-1100@1466 с 512 оперативы.
Началось с моника на 23 - пришлось видяху новую ставить, и мышку, а потом я скачал рип 720р и не смог посмотреть - это был приговор.
> Мне в 2007 году перестало хватать п3-1100@1466 с 512 оперативы.Чем вы таким занимались что этого перестало хватать? На этой конфигурации и сейчас можно не просто выживать, а ещё и работать, если поставить какой-нибудь антикс линукс.
> рип 720р и не смог посмотреть
Похоже вы батенька фантазёр, 720p даже на первых пнях БЕЗ mmx играло, если видюха умела в аппаратный декодинг (а они почти все умели).
Компеляторв вижалстудии долго собирал, и кино в 720р не крутило.Поди найди видяху с AGP и аппаратным h.264, или ты DivX аппаратный где то видел?)
какие 720p? 720x576 может быть?
Видеокарты тогда хорошо если 24-битный цвет умели. Matrox Millenium был пределом мечтаний, а стандартом S3 Trio 64 V+.
DivX нормального разрешения тянул уже не любой Pentium-II.
да, ладно))) в 2007 S3 Trio 64 V+ ? Вот в 1997 это еще было.
> Чем вы таким занимались что этого перестало хватать?Ну, э, допустим в каде порисовать. Или скомпилять более-менее жирный проект размером с линукскернел.
Скомпилять его на п3 с 512 оперативы, конечно, можно. В 1 малохольный поток. А теперь пустим сборку на вооон том 16-ядернике с 32 гиг оперативки, подохренеем с разницы во времени этой операции. И подумаем - может, если этим заниматься всерьез, раз в жизни себе нормальный комп купить все же? Из соображений разгона эффетивности.
Или вот равка с камеры. Немного ее покрутить... эээ... она в байере более 20 мегов весит. А в RGB и того больше. А еще самой программе места в памяти надо. Undo всякое и кеши предппросмотра... без этого всего конечно можно, но работать будет как фотошоп на 95 винде с 16 мегами памяти, по тем же причинам. А на компе с 16 мегами памяти вы бы 20-метровую равку вообще обрабатывать не стали бы, из-за нереалистичного времени на свопление этого счастья.
> сейчас можно не просто выживать, а ещё и работать, если поставить
> какой-нибудь антикс линукс.Работать... ну смотря кем, конечно. Если просто ломовым сишным кодером, только мелкие проектики - еще можно попытаться. И даже так какой-нибудь плеер в фоне сборку тормознет ощутимо. Блин, у меня телефон мощнее чем это, может тогда лучше на телефоне билдовать?! Он и энергии в 100 раз меньше жрет.
> Похоже вы батенька фантазёр, 720p даже на первых пнях БЕЗ mmx играло,
> если видюха умела в аппаратный декодинг (а они почти все умели).Во первых, большая часть видях как раз никакого декодинга не умели. И форматов тогла были только мпег 1 и 2 которым чтобы не выглядеть как УГ надо ломовой битрейт. И справлялись с этим только отдельные хардварные карты акселераторов, которые мало у кого были. Потому что отдельная карта, за отдельную цену. Потом компы стали мощнее и всякие ранние Mpeg4 появились типа DivX ;) (смайлик в оном прозрачно намекает что это перепертый MS MPEG4v3). Ну а потом уже всякие xvid начались и проч, с довольно крутыми оптимизациями, и там уже третьепень имел некие шансы на не сильно жирном потоке. Что-то такое спраяляется с небольшими потоками XVID и VP8. H.264 даже самый ерундовый уже не потянет, так что даже торенты не посмотришь, разве что совсем олдовые.
ХР появилась в 2002 году вроде или 2003 весной.
Тогда было много п3 с 64-256 мб озу, но были и П4 уже.
Вылизанная ХР32 потребляла после загрузки 96-128мб озу, и на 256мб+ ей жилось неплохо.
В п3 вставало до 512/768мб в зависимости от чипсета.4+ гига это более менее массово началось после коредуо, те 2008+ год, до того у совсем энтузиастов, хотя всякие жмоты и в 2015 году жили на 1-2 гб оперативы.
Ставить ХР64 - большая глупость, когда можно было поставить 2к3х64 и не иметь никаких проблем вообще, да ещё и поддержку GPT получить и всякие зеркала софтварные.
> поддержку GPT получитьНафуя? Тогда диски были 20-40 гигов в среднем. И поголовно в fat32 чтобы ресурсы не тратить на ntfs потому что ntfs нафиг не нужна на домашнем компе. Я даже сейчас не знаю зачем нужно GPT если это не сервер.
Использовать FAT32 на ХР - огромная глупость.
40гб диски были в 2003-5 годах, к 2007-8 они уже переросли MBR.
GPT нынче везде, кроме странных лудитов, и она банально удобнее и понятнее чем мбр.
> огромная глупостьПисать подобные комменты будучи на айтишном сайте.
> лудитов
Ты ошибся сайтом, тебе к клоунам и петросянам.
На FAT32 сидели дурачки, которые сидели под админом и им было пофик что можно случайно снести систему неловким движением мышки в проводнике.
Про всякие вирусы я молчу.Активно пересаживал всех клиентов на ХР под обычного юзера, естессно на NTFS и оно работало у людей годами, и даже без всяких антивирусов с небольшим подтягиванием гаек в реестре (локальная политика безопасности) никакой гадости не разводилось.
Не знаю что вы там на своём FAT32 наэкономили, когда я отключал всё ненужное и получал после бута 128мб оперативы занятой системой.
И отдельно отмечу что NTFS был просто шикарен после FAT32 которому после каждого хард ребута нужна была проверка, можно сказать что он был неубиваемым из коробки.
В XP пользователь обычно был админом, вирус цеплял после необдуманого клика баннера. А если не админом - половина программ не работали. И уж 5 тулбаров в браузере обычное дело. Линуксы в руках профанов устойчивее, там случайно поставить софт сложно.
>> без всяких антивирусов с небольшим подтягиванием гаек в реестре (локальная политика безопасности) никакой гадости не разводилось.А потом вирусня начала ставиться в Local Settings (включаяя всякие Амиго-браузеры) и вся эта политика безопасности пошла по женской линии.
Для большинства пользлвателей что GPT что MBR монопенисуально потому что у большинства два раздела и дисков тоже штуки две максимум.
> Для большинства пользлвателей что GPT что MBR монопенисуально потому что у большинства
> два раздела и дисков тоже штуки две максимум.У MBR 2 ТБ ограничение, ты тут втираешь какую-то дичь. И как это большинство пользователей столкнётся с этой дос-разсеткой, если венда её давно закопала? Кстати насчёт двух разделов, у _большинства_ таки в районе десятка разделов, поскольку это стандартная тема. Тебе часто говорят, что ты некомпетентный, и тебе стоит воздержатся от ответов в интернете в принципе?
Для дисков больше 2TB, для легаси MBR это максимальный лимит.
А дисков сейчас много и до 20TB.
> Ставить ХР64 - большая глупость, когда можно было поставить 2к3х64 и не
> иметь никаких проблем вообще, да ещё и поддержку GPT получить и
> всякие зеркала софтварные.XP64 - это просто клиентская версия 2003 X64.
Так что работали бы они одинаково.
>>В п3 вставало до 512/768мб в зависимости от чипсета.Мой домашний CUBX-E с P3-750 и 1Гб RAM смотрит на это с ухмылкой :). Ну и под 98-й вантуз добрый человек сделал патчи для работы с такими объёмами, а его родственники выдали в бесплатный доступ их.
64-битная ОС нужна не для доступа за пределы 4ГБ. Там в 2 раза больше регистров проца. Но из-за того, что адреса памяти стали в 2 раза длинее, потребление ОЗУ у дистрибутивов в среднем поднялось на 30%, а у хромобраузера -- на 50%.
Если сейчас недопека(планшетное железо, или просто "старый пень"), которые хоть и умеют в 64 бита, но памяти имеют 4- гига, то даже win10 32 бита, т.к. значительно меньше жрётся памяти, и хватает даже браузеру на сильно больше страниц.
Только 4 гига-то вы не получите на 32 битах. Так что в производительности вы проиграете, а по памяти хорошо если в ноль выйдете.
> Только 4 гига-то вы не получите на 32 битах. Так что в
> производительности вы проиграете, а по памяти хорошо если в ноль выйдете.Бывают исключения.
В "золотой век" планшетов на одноядерном Атоме, с 2ГБ ОЗУ использовал Win7 64bit.
Для игр, которые к тому же 32х битные были тогда, это давало и строго проигрыш, и жор ОЗУ, и многое не вообще запускалось. Браузеру тоже это на пользу не шло.
А для программирования, 64 битная семерка работала быстрее.
Разница в быстродействии стоила двойной загрузки.
Там была такая проблема. 32 разрядное приложение в windows не могло адресовать более 2 Гб оперативной памяти, тогда в винде это считалось неким дополнительным фактором стабильности, ведь если вы не можете адресовать память выше 4 гигов и часть еще съели биос и встроенная видеокарта, то это угроза стабильности системы. А еще 32-битные приложения тогда занимали ощутимо меньше оперативной памяти, если не в 2 то уж в полтора раза точно. Но уже в XP был ключик для запуска ядра со снятием лимита в 2 Гб, но как говорится, на свой страх и риск, как отключение свопа. Этим пользовались 1С-ники в основном и позже игроманы, которые не хотели слезать с XP. Это было искусственное ограничение, так как со времен итаниума существовало PAE. Причем в 32 разрядных windows оно присутствовало в enterprise версиях (а значит за легальное использование простили деньги, а в linux/freebsd даром). PAE позволяло адресовать 32-битной системе до 32 гигабайт памяти. А это и сейчас для среднего пользователя идеал. Словом можно и в настоящее время жить на 32-битной системе. Есть 32-разрядные версии windows 10. Но вот половину приложений уже давно перестали собирать с поддержкой 32-разрядного режима.
>[оверквотинг удален]
> со снятием лимита в 2 Гб, но как говорится, на свой
> страх и риск, как отключение свопа. Этим пользовались 1С-ники в основном
> и позже игроманы, которые не хотели слезать с XP. Это было
> искусственное ограничение, так как со времен итаниума существовало PAE. Причем в
> 32 разрядных windows оно присутствовало в enterprise версиях (а значит
> за легальное использование простили деньги, а в linux/freebsd даром). PAE позволяло
> адресовать 32-битной системе до 32 гигабайт памяти. А это и сейчас
> для среднего пользователя идеал. Словом можно и в настоящее время жить
> на 32-битной системе. Есть 32-разрядные версии windows 10. Но вот половину
> приложений уже давно перестали собирать с поддержкой 32-разрядного режима.1. PAE was first implemented in the Intel Pentium Pro in 1995
2. винда, 1с-ники, промышленный софт :).
Наверняка дело в том, что где-то один раз использовали 32 битное со знаком, а потом просто для совместимости оставляли по умолчанию предполагая худший вариант
А смысл если большинство прогрпмм 32 разрядные?
Какое нафик большинство? Ненужный шлак.
Работают через сторонний софт WineVDM (https://github.com/otya128/winevdm).
В 32-х битных Windows 7 и Windows 10 работают
> их по сути никто уже нативно и не запускает со времёнПолно ещё профессионального и промышленного софта который написан под Win 3.x
Он продолжит работать на тех утюгах на которых работает, никому в голову не придет ставить туда современный процессор.
> Он продолжит работать на тех утюгах на которых работает, никому в голову
> не придет ставить туда современный процессор.Пока не сдохнет железо. Я так "бэст" "досовский" перетащил вместе со слепком hdd на рязаньку 2400 + мамка с lpt(ключ lpt), и запускаю в libvirt + kvm, с пробросом lpt и представлением что проц pentium 3(тогда win2003) не лагает.
Эта хрень нужна уже только как справка, а переносить в ту же 1С никто не хочет, сильно проще и дешевле было новое железо взять взамен посыпавшимся ide hdd и серверной мамке с дохнущими кондёрами и прочими проблемами.
Только рассчитаны они на столь слабые процессоры, что их можно в эмуляции запускать. В ReactOS 64-бит так сейчас DOS программы работают.
> Полно ещё профессионального и промышленного софта который написан под Win 3.xА примеры можно? Действительно промышленного, причем безальтернативного.
В поездах(аналогов сапсана, но из 90х), на некоторых европейских линиях, до сих пор софт внутри 16-bit DOS. Знаю, т.к. одно время занимался портированием этого всего на Windows 7 и Linux. Портирование на 2023 год ещё не завершено, так что ездят с 16-bit железом и молятся чтобы железо не сдохло пока не завершено портирование.
> В поездах(аналогов сапсана, но из 90х), на некоторых европейских линиях, до сих
> пор софт внутри 16-bit DOS. Знаю, т.к. одно время занимался портированием
> этого всего на Windows 7 и Linux. Портирование на 2023 год
> ещё не завершено, так что ездят с 16-bit железом и молятся
> чтобы железо не сдохло пока не завершено портирование.О, да, реально "полно" промышленного софта.
Обычный пример "внедрение ынтерпрайза" по европейски. Беедненькие.
> О, да, реально "полно" промышленного софта.
> Обычный пример "внедрение ынтерпрайза" по европейски. Беедненькие.Вдогонку. Китайцы с их маглевами плачут и курят бамбук :)
Ну так это просто пример. Того, который я видел собственными глазами. А так, подозреваю, что таких динозавров в мире ещё полно. И никто, кстати, не стал бы и переписывать все это(работает и ладно), если бы не отсутствие производства\возможности покупки того железа. А у поездов, кораблей и самолетов срок службы может и 50 лет легко быть.
> Ну так это просто пример. Того, который я видел собственными глазами. А
> так, подозреваю, что таких динозавров в мире ещё полно. И никто,
> кстати, не стал бы и переписывать все это(работает и ладно), если
> бы не отсутствие производства\возможности покупки того железа. А у поездов, кораблей
> и самолетов срок службы может и 50 лет легко быть.1. Транспорт - это сервис, часть логистической цепочки.
2. IBM PC+DOS/Win3.xx - персональный компьютер, не имеющий резервирования и возможностей систем реального времени бай дезигн, поэтому скорее всего используется в информационных системах типа покупки/резервирования билетов и отображения расписания, схем движения итд. То есть, использует субд и протоколы обмена. Проблема заменить?
3. Поезда, суда и самолеты НИКОГДА не управляются персоналками с DOS/win*, лицензию почитай, что-ли. Ни DOS ни винду нельзя использовать в сферах, которые связаны с безопасностью людей. А информационно-мультимедийную фигню можно заменить на что угодно, хоть на планшеты/телевизоры с андроидом :)
4. Динозавры обычно используют более другие системы IBM, DEC, Sun, HP, но это совсем другой уровень, промышленный, тсзть :)
> Ну так это просто пример. Того, который я видел собственными глазами. А
> так, подозреваю, что таких динозавров в мире ещё полно. И никто,
> кстати, не стал бы и переписывать все это(работает и ладно), если
> бы не отсутствие производства\возможности покупки того железа. А у поездов, кораблей
> и самолетов срок службы может и 50 лет легко быть.Надеюсь, что этот устаревший ПАК(программно-аппаратный комплекс) не установлен как система управления транспортом(стрелки/семафоры/итд). И не как система управления воздушным движением.
Нет, это всего лишь система оповещения пассажиров о расписании и станциях прибытия и всего вот этого. Но там нифига не примитивно, там и GPS и сетевые протоколы продвинутые и индустриальные шины(MVB вроде). Но оно работает 20 лет и переписывать приходится только потому что железа не купить для той системы.
> Нет, это всего лишь система оповещения пассажиров о расписании и станциях прибытия
> и всего вот этого. Но там нифига не примитивно, там и
> GPS и сетевые протоколы продвинутые и индустриальные шины(MVB вроде). Но оно
> работает 20 лет и переписывать приходится только потому что железа не
> купить для той системы.Почему-то не удивлен. А тем "внедрятелям" системы с "GPS и сетевые протоколы продвинутые и индустриальные шины(MVB вроде)" построенной на IBM PC+DOS/Win16 - бубенцы надо было отрывать еще при проектировании. Это не "динозавры", это обычная бюрократическая европейская практика выдаивания денег налогоплательщиков, у них всё так работает. Это же Европа, да?
> Почему-то не удивлен. А тем "внедрятелям" системы с "GPS и сетевые протоколы
> продвинутые и индустриальные шины(MVB вроде)" построенной на IBM PC+DOS/Win16 - бубенцы
> надо было отрывать еще при проектировании.Ну там всё же не совсем ПК, там плата с распаянным на ней процессором, памятью и в форм факторе размером с современную видеокарту. Т.е. ПК там все же промышленный. Но DOS там классический, это да.
> Ну там всё же не совсем ПК, там плата с распаянным на
> ней процессором, памятью и в форм факторе размером с современную видеокарту.
> Т.е. ПК там все же промышленный. Но DOS там классический, это
> да.Китайцам закажите. Если PCB файло осталось :)
> Китайцам закажите. Если PCB файло осталось :)Проще одноплатники взять и переписать 1 раз. Да так чтобы конкретная модель одноплатника была относительно похрен - линукс и линукс, какая ему разница на чем работать? Самый край проект пересобрать через i++ лет и все снова завертится, куда оно денется. Хотя есть и одноплатники с гарантированной долговременной доступностью, специально для такого.
Нет, это всего лишь система оповещения пассажиров о расписании и станциях прибытия и всего вот этого. Но там нифига не примитивно, там и GPS и сетевые протоколы продвинутые и индустриальные шины(MVB вроде). Но оно работает 20 лет и переписывать приходится только потому что железа не купить для той системы.
> Нет, это всего лишь система оповещения пассажиров о расписании и станциях прибытия
> и всего вот этого. Но там нифига не примитивно, там и
> GPS и сетевые протоколы продвинутые и индустриальные шины(MVB вроде). Но оно
> работает 20 лет и переписывать приходится только потому что железа не
> купить для той системы.Очень понравилось "сетевые протоколы продвинутые" это типа SPX более продвинутый, чем IPX? :)
> и индустриальные шины
Для которых уже не выпускается контроллеров и сделать новые уже никак? Ну бред же. Значит, это не "индустриальные шины", а бытовые, которые не привязаны к стандартам и делались на коленке. Трясите бабло с проектировщиков изначальной системы, это их косяк.
> Очень понравилось "сетевые протоколы продвинутые" это типа SPX более продвинутый, чем IPX?
> :)Это в смысле свои наколенные протоколы, по которым вся система работает.
> Для которых уже не выпускается контроллеров и сделать новые уже никак? Ну
> бред же. Значит, это не "индустриальные шины", а бытовые, которые не
> привязаны к стандартам и делались на коленке. Трясите бабло с проектировщиков
> изначальной системы, это их косяк.Я не думаю что одна часть Сименса будет трясти с другой части Сименса бабло за какие-то косяки в проектировании 30 лет назад.
Опять же, я не говорю что портировать невозможно, но это вынужденное мероприятие из-за отсутствия железа. Приходится тратить немалые деньги на это, вместо толь чтобы купить того железа 16-bit и ездить еще 20 лет.
И да, это Европа конечно. Железные дороги Германии, Словении и т.д.
> Это в смысле свои наколенные протоколы, по которым вся система работает.Ну это действительно по промышленному :)
> Я не думаю что одна часть Сименса будет трясти с другой части
> Сименса бабло за какие-то косяки в проектировании 30 лет назад.А, сименс - это да, монстр. Незря он еще и банк.
Много страдать, много плакать и постоянно платить. Только так :)
Новое поделие интела тут вообще не причем.> Опять же, я не говорю что портировать невозможно, но это вынужденное мероприятие
> из-за отсутствия железа. Приходится тратить немалые деньги на это, вместо толь
> чтобы купить того железа 16-bit и ездить еще 20 лет.
> И да, это Европа конечно. Железные дороги Германии, Словении и т.д.Страдать, плакать и платить. Это тот самый "тру энтерпрайз", вендорлок, абонплата и ремонт за овердофига. Даже по гарантии.
>> Это в смысле свои наколенные протоколы, по которым вся система работает.
> Ну это действительно по промышленному :)ну так 30 лет назад только такие и были - все делали свои протоколы под своё УСО, датчики, и т.д. Сейчас пересаживают на "стандартные" протоколы, которые просто какой-нибудь условный Сименс пропихнул в качестве стандарта, и которые 30 лет назад, а на самом деле и лет ещё 10, были такими-же наколенными.
>>> Это в смысле свои наколенные протоколы, по которым вся система работает.
>> Ну это действительно по промышленному :)
> ну так 30 лет назад только такие и были - все делали
> свои протоколы под своё УСО, датчики, и т.д. Сейчас пересаживают на
> "стандартные" протоколы, которые просто какой-нибудь условный Сименс пропихнул в качестве
> стандарта, и которые 30 лет назад, а на самом деле и
> лет ещё 10, были такими-же наколенными.Это проблемы тех, кто доверил "промышленный" проект NIH организмам.
И то, что в данный момент нет возможности обрабатывать "это промышленное" иначе, как старыми программами под DOS/Win3.*.А теперь внимание, вопрос: что изменилось, когда интел заявил о выпуске новой железки?
Ответ по умолчанию: ничего.
Можете добавить ваш вариант ответа, но высказывания "куча/полно/все используют" старого унылого "годамиработающего" уже не аргумент, а оправдание отсутствия планирования развития промышленного процесса. Как то так.
И то, что в данный момент нет возможности обрабатывать "это промышленное" иначе, как старыми программами под DOS/Win3.* уже не аргумент а отмазка "промышленников".
> А теперь внимание, вопрос: что изменилось, когда интел заявил о выпуске новой
> железки?
> Ответ по умолчанию: ничего.
> Можете добавить ваш вариант ответа, но высказывания "куча/полно/все используют" старого
> унылого "годамиработающего" уже не аргумент, а оправдание отсутствия планирования развития
> промышленного процесса. Как то так.Промышленные процессы, имхо, бывают разные. Есть системы, которые имеют длительность поддержки 20 лет, и регулируется это не разработчиком и, как ни странно, даже не пользователем.
>> А теперь внимание, вопрос: что изменилось, когда интел заявил о выпуске новой
>> железки?
>> Ответ по умолчанию: ничего.
>> Можете добавить ваш вариант ответа, но высказывания "куча/полно/все используют" старого
>> унылого "годамиработающего" уже не аргумент, а оправдание отсутствия планирования развития
>> промышленного процесса. Как то так.
> Промышленные процессы, имхо, бывают разные. Есть системы, которые имеют длительность поддержки
> 20 лет, и регулируется это не разработчиком и, как ни странно,
> даже не пользователем.О, вот тут и начинается самое интересное. Если хочешь, чтобы производство/сервис/услуга работали 20+ лет, занимайся его развитием.
Как? Тренинги помогут :)
И нечего тут оправдывать глупость планирования/проектирования/реализации "старое сыпецца, а на новом не работает". Да на этом умные люди бизнес делают, а не ноют. Причем, чем хуже ситуация, тем больше прибыль :)
P.S. Совместимость со старым и унылым им нужна, панимаешь :)
>> промышленного софта который написан под Win 3.xДа, есть такое. Но оно летает без намеков на баги под любым современным эмулятором.
Это лет 5 назад и более, были оговорки, а сейчас нет.
Не будут
> Прекращение ... и возможности переопределения размера адреса
Для старых программ используй старые процессоры
ВЫ видимо win9x/me не застали с её таблицей совместимости с dos-программами :)
98-то ладно, там на худой конец перезагрузка в режим DOS была, а вот с XP досовским программам пришёл песец.
> 98-то ладно, там на худой конец перезагрузка в режим DOS была, а
> вот с XP досовским программам пришёл песец.Перезагрузка в дос. Ха. Это 98 запускался поверх DOS как этакий DOS Extender переросточный. Ну а можно вот и не запускать виндовую часть было, то что до него называлось MSDOS 7.x, так то. Отдельно от виндов никогда не релизилось, но в целом было тем же самым MSDOS'ом, мало чем отличным от 6.x который релизили отдельно. Чуток заапгрейдили для LFN и проч, в остальном те же яйца.
Бьёт поклоны и поклоняется...
Опять заново изобрели IA64
Нет. IA64 была совсем другой архитектуройПо теме: НАКОНЕЦ-ТО!
IA64 это VLIW и не имеет никакого отношения ни x86 ни к x86_64
IA64 самое прямое отношения к AMD64 — продавался как его альтернатива, пока не купили лицензию.
то что он другой внутри - это лишние тех. детали ))))Более того, это был в девичестве P7 ))) его разработка шла с начала 90х.
И да, у него была мода совместимости с IA32, чтоб совсем не остаться без СуперОС - ms windows
Но не взлетел. Посмотрим на новое чудо - x86S
IA64 был VLIW процессором, как нынешний "эльбрус". Совместимость с x86/IA32 была достигнута бинарной трансляцией, т.е. ассеблер x86 транслировался в инстукции IA64. Скорость исполнения таких бинарников была ужастной.
IA64 был расчитан на использование в серверах, потому наверное было пофиг на совместимость с Windows. Только пользователи из проприетраного мира Unix тоже были не рады проблем с IA64. Бесшовной миграции не выходило. Нужно было перекомпилировать все под IA64, а значит найти исходники и иметь годные компиляторы под ADA, Module, PL, etc.
> IA64 самое прямое отношения к AMD64 — продавался как его альтернатива, пока
> не купили лицензию.
> то что он другой внутри - это лишние тех. детали ))))
> Более того, это был в девичестве P7 ))) его разработка шла с
> начала 90х.
> И да, у него была мода совместимости с IA32, чтоб совсем не
> остаться без СуперОС - ms windowsЧто за бредятина, IA64 это простые risc ядра c кучей регистров и VLIW, он не имеет никакого отношения x86 с его cisc ядрами. Они не совместимы вообще никак. Совместимость достигается двоичной трансляцией кода. И AMD не имеет никакого отношения ни к IA64 ни к VLIW.
Не путайте. IA64 - это печально известный "Итаник" из нулевых. А интеловский аналог amd64, на котором сейчас их массовые процы построены, называется EM64T.
Не аналог, а выкупленная у АМД через суды amd64 технология адресации памяти без потерь производительности. То что ее дополнительно кастрировали с 64 бит до 48-46 это загоны маркетолухов штеуда.
И да, итаниум использовал ворованные технологии Эльбрусов купив предателей из числа бывших сотрудников МЦСТ - все аналогично появлению первых пеньков, только тут они облажались и не смогли в компилятор и потому развитие заклинило и им пришлось придумывать ксеоны с кучей ядер, а лохам втюхивали до 4 ядер модели.
EM64T потом переименовали в Intel 64, как в пресс-релизе т стоит.
> IA64 самое прямое отношения к AMD64 — продавался как его альтернатива Какая же это альтернатива? Стоит как чугунный мост, у программистов его нет, софта нет, все тормозит.
Блестящий пример того как диванные "эксперты" генерируют тупые фейки в интернетах.
IA64 во времена, когда Intel бешено его пиарила подавался именно как "принципиально другая" архитектура.
"Ничего общего" с x86, "отказ от старого наследия", "сбросить оковы устаревшей архитетуры" и далее бла-бла-бла.
Теперь 'внезапно' "прямое отношение".. :-\
Мне кажется, что сейчас бы Itanium взлетел.
Но недалеко да все больше - вниз.
Он тормоз был, поскольку оптимизирующий компилятор интел как ни старался - ниасилил. И невзлетел в первую очередь по этой причине - выигрыш производительности был слишком незначительным, а ценник задран.
Он бы и в 2000тых взлетел, если б не гениальные маркетологи.
Тут тоже самое взлетит не взлетит, будет зависеть от цены, модели продвижения и договороспособности интел с производителями софта.
Но интел ужо давно не торт, так что в их движуху, лично я, не шибко верю.
Там дело не столько в маркетологах.
Хотя и в них тоже.Там дело в том, что компиляторы тогда не позволяли с минимальным вмешательством программиста перекомпилировать исходники подготовленные для других платформ в эффективный машкод для итаниума.
В смысле - он работал, но обескураживающе не так быстро как ожидалось.
А чтобы выжать производительность нужно было сидеть и усердно-усердно полировать стул.Кстати, и сегодня с бэкэндами для vliw у компиляторов не всё так уж гладко.
Производители ПО посмотрели на эту тему, прикинули во что им оптимизация встанет, и сколько они и так зарабатывают без продуктов на итаниуме - и кроме самого-самого кровавого энтерпрайза туда никто и не полез.
А потом и кровавый энтерпрайз понял, что попал куда-то не туда.
Ссылку не дам, но в памяти смутно осталось, что когда оракл и эйчпи попытались спрыгнуть и закруглить срок поддержки своих продуктов на итаниуме - то им пользователи их продуктов выкатили такой коллективный иск, что его даже пришлось частично удовлетворить.
Если проверите и оспорите - возражать не буду.Короче, коммерсанты - не ангелы, но там ещё и другие причины были.
Компиляторы тогда и для IA32 не очень хороший код генерировали. Приходилось кодить на асме в критичных случаях. Под Itanium, как я слышал, желающих было мало.
> Компиляторы тогда и для IA32 не очень хороший код генерировали. Приходилось кодить
> на асме в критичных случаях. Под Itanium, как я слышал, желающих
> было мало.Ну, речь-то о том идёт, что как бы они там для IA32 не генерировали - для Itanium получалось ещё хуже.
Мне кажется, что суть не в каких-то принципиальных ограничениях, просто все принципиальные оптимизации переползали в коммерческие компиляторы из академических работ.
А в тогдашних академиях vliw был как-то не очень в чести.
То есть и переползать оптимизациям в коммерческие компиляторы было неоткуда.
Банально компиляторам не хватало памяти. MSVC отключал оптимизацию для функций, если в теле количество строк превышало некоторый предел (цифры уже не помню; сталкивался, когда генерировал объёмный исходник на Си, пришлось дробить функцию на мелкие). Для Itanium памяти нужно больше.
> Банально компиляторам не хватало памяти. MSVC отключал оптимизацию для функций, если в
> теле количество строк превышало некоторый предел (цифры уже не помню; сталкивался,
> когда генерировал объёмный исходник на Си, пришлось дробить функцию на мелкие).
> Для Itanium памяти нужно больше.Ну, уж чего-чего, а в тех конфигурациях систем, которые поставлялись с итаниумами - памяти было побольше, чем в типичной системе на x86.
И намного побольше.Тем паче, что каждому пользователю такой системы не было нужды собирать ПО для себя самому.
А уж фирма-разработчик, если бы считала, что игра стоит свеч - думаю не сочла бы чем-то ненормальным купить себе станцию для сборки на итаниуме с действительно большим количеством памяти.Проблема была, всё-таки не в памяти.
Я вот даже залез в свои старые закрома, и оттуда Вам представляю цитату:
"..showed more realistic (and somewhat disappointing) results for the benefits of predication
on branches, in which short pipeline and small branch penalties of the Itanium
implementation make it much more difficult for predication to shine."Это из книги 2004 года - "Embedded Computing: A VLIW Approach to Architecture, Compilers and Tools"
421 страница.И то, что они пишут "somewhat disappointing" - так это они ещё очень сильно смягчили.
Так не "disappointing" местами с производительностью было с предсказаниями ветвлений, а, буквально целый "disastering".
>[оверквотинг удален]
>> когда генерировал объёмный исходник на Си, пришлось дробить функцию на мелкие).
>> Для Itanium памяти нужно больше.
> Ну, уж чего-чего, а в тех конфигурациях систем, которые поставлялись с итаниумами
> - памяти было побольше, чем в типичной системе на x86.
> И намного побольше.
> Тем паче, что каждому пользователю такой системы не было нужды собирать ПО
> для себя самому.
> А уж фирма-разработчик, если бы считала, что игра стоит свеч - думаю
> не сочла бы чем-то ненормальным купить себе станцию для сборки на
> итаниуме с действительно большим количеством памяти.Толку мало от этой памяти, если транслятор не может её адресовать. Структуры типа абстрактного синтаксического дерева проектировались с расчётом 32-х разрядных указателей и соответствующего адресного пространства. Вот мы и приходим к тому, что компилятор надо перепроектировать, а это не быстро.
> Проблема была, всё-таки не в памяти.
> Я вот даже залез в свои старые закрома, и оттуда Вам представляю
> цитату:
> "..showed more realistic (and somewhat disappointing) results for the benefits of predication
> on branches, in which short pipeline and small branch penalties of the
> Itanium
> implementation make it much more difficult for predication to shine."
> Это из книги 2004 года - "Embedded Computing: A VLIW Approach to
> Architecture, Compilers and Tools"
> 421 страница.И в результате появилась архитектура NetBurst со сверхдлинным конвейером и префиксами к командам условных переходов, которые "помогали" предсказателю, и кучей правил в IA SDM Optimization Manual. В реальном мире это было названо "кукурузные мегагерцы" и 4-й Пентиум начал неожиданно проигрывать 3-му на меньшей частоте.
> И то, что они пишут "somewhat disappointing" - так это они ещё
> очень сильно смягчили.
> Так не "disappointing" местами с производительностью было с предсказаниями ветвлений,
> а, буквально целый "disastering".Как я слышал, в Эльбрусе с предсказанием ветвлений поступают так - транслятор генерирует код, исполняющий обе ветки условного оператора параллельно. Вот эта операция требует больше памяти при трансляции, и зависимости не всегда линейна.
> И в результате появилась архитектура NetBurst со сверхдлинным конвейером и префиксами к
> командам условных переходов, которые "помогали" предсказателю, и кучей правил в IA
> SDM Optimization Manual. В реальном мире это было названо "кукурузные мегагерцы"
> и 4-й Пентиум начал неожиданно проигрывать 3-му на меньшей частоте.Пентиум 4 - это, конечно, ностальгично.
Но ведь vliw итаниума от этого легче не стало, верно?> Как я слышал, в Эльбрусе с предсказанием ветвлений поступают так - транслятор
> генерирует код, исполняющий обе ветки условного оператора параллельно. Вот эта операция
> требует больше памяти при трансляции, и зависимости не всегда линейна.Не знаю, как там с этим в Эльбрусе, но некоторые компиляторы для vliw, судя по статьям, так и делали.
Помогло ли это с производительностью - не знаю, потому что, как я уже здесь писал, не настолько глубоко погружён в вопрос.
Итаниуму, опять-таки, от этого легче не стало, это точно.
>> И в результате появилась архитектура NetBurst со сверхдлинным конвейером и префиксами к
>> командам условных переходов, которые "помогали" предсказателю, и кучей правил в IA
>> SDM Optimization Manual. В реальном мире это было названо "кукурузные мегагерцы"
>> и 4-й Пентиум начал неожиданно проигрывать 3-му на меньшей частоте.
> Пентиум 4 - это, конечно, ностальгично.
> Но ведь vliw итаниума от этого легче не стало, верно?А надо было не удалять свою же реплику про "short pipeline" и "small branch penalties", которые, якобы, были проблемой Итаниума.
Пенальти - это когда процессор вынужден простаивать из-за неверного предсказания перехода.
При этом происходит декодирование операций (альтернативной ветки) и загрузка конвейера.
В этом случае короткий конвейер тоже плюс.Интел посчитала ошибкой, сделала иначе и пролетела.
>> Как я слышал, в Эльбрусе с предсказанием ветвлений поступают так - транслятор
>> генерирует код, исполняющий обе ветки условного оператора параллельно. Вот эта операция
>> требует больше памяти при трансляции, и зависимости не всегда линейна.
> Не знаю, как там с этим в Эльбрусе, но некоторые компиляторы для
> vliw, судя по статьям, так и делали.
> Помогло ли это с производительностью - не знаю, потому что, как я
> уже здесь писал, не настолько глубоко погружён в вопрос.
> Итаниуму, опять-таки, от этого легче не стало, это точно.Начало ветки обсуждения "Мне кажется, что сейчас бы Itanium взлетел".
_Сейчас_ вполне мог бы взлететь, поскольку преодолены детские болезни трансляторов и ограничения железа, на котором те трансляторы приходилось запускать.
И если бы не повторилась борьба отделов внутри Интел.Эльбрус взлетают совсем по другой причине - раздельные стеки и безопасный режим.
Потому Интел или кто-то ещё не будет делать VLIW - это поставит противников Эльбруса в неудобное положение,
поскольку священная война перейдёт с повестки "VLIW проив остальные" в "безопасность против фуфло".
> А надо было не удалять свою же реплику про "short pipeline" и
> "small branch penalties", которые, якобы, были проблемой Итаниума.Вы тут с кучей народа, я смотрю, одновременно общаетесь.
И, видимо, из-за этого Вы уже немножко путаете кто Вам чего тут писал.
Я не удаляю свои реплики.
И не редактирую их.
Никогда.Могу удалить, если случайно отправил незаконченное, но потом сразу отправляю дописанное до конца.
Итаниум обладал плохой производительностью на одном и том же наборе ПО по сравнению с другими архитектурами.
Тчк.
>> А надо было не удалять свою же реплику про "short pipeline" и
>> "small branch penalties", которые, якобы, были проблемой Итаниума.
> Вы тут с кучей народа, я смотрю, одновременно общаетесь.
> И, видимо, из-за этого Вы уже немножко путаете кто Вам чего тут
> писал.
> Я не удаляю свои реплики.
> И не редактирую их.
> Никогда.Когда нажимаете "Ответить", движок сайта цитирует предыдущее сообщение.
В моём сообщении, на которое Вы отвечали, Ваша реплика была, соответственно и в цитате.
Из цитаты её Вы вырезали.
Мой ответ на неё оказался вырванным из контекста.
Что позволовило Вам сменить тему.> Могу удалить, если случайно отправил незаконченное, но потом сразу отправляю дописанное
> до конца.
> Итаниум обладал плохой производительностью на одном и том же наборе ПО по
> сравнению с другими архитектурами.
> Тчк.Достойный ход - нафантазировать и умыть руки.
> И, видимо, из-за этого Вы уже немножко путаете кто Вам чего тут
> писал.Если не помните, что сами и писали "short pipeline", нажмите Ctrl+F в браузере. Поскольку не набивали это сами ручками, а копировали из книжки - для меня это звоночек. Попрошу впредь не цитировать тексты без предварительного их осмысления.
>> А надо было не удалять свою же реплику про "short pipeline" и
>> "small branch penalties", которые, якобы, были проблемой Итаниума.
> Если не помните, что сами и писали "short pipeline", нажмите Ctrl+F в
> браузере. Поскольку не набивали это сами ручками, а копировали из книжки
> - для меня это звоночек. Попрошу впредь не цитировать тексты без
> предварительного их осмысления.Сие есть Ваши два предыдущих комментария.
Это не звоночек, любезный собеседник.
Это - гудок.
>>> А надо было не удалять свою же реплику про "short pipeline" и
>>> "small branch penalties", которые, якобы, были проблемой Итаниума.
>> Если не помните, что сами и писали "short pipeline", нажмите Ctrl+F в
>> браузере. Поскольку не набивали это сами ручками, а копировали из книжки
>> - для меня это звоночек. Попрошу впредь не цитировать тексты без
>> предварительного их осмысления.
> Сие есть Ваши два предыдущих комментария.
> Это не звоночек, любезный собеседник.
> Это - гудок.Специально для неосиливших поиск, цитирую комментарий №355
Заголовок полностью, текст - частично.
Intel развивает упрощённую архитектуру x86S, работающую толь..., Quad Romb, 19:33 , 22-Май-23 (355)Проблема была, всё-таки не в памяти.
Я вот даже залез в свои старые закрома, и оттуда Вам представляю цитату:
"..showed more realistic (and somewhat disappointing) results for the benefits of predication
on branches, in which short pipeline and small branch penalties of the Itanium
implementation make it much more difficult for predication to shine."Это из книги 2004 года - "Embedded Computing: A VLIW Approach to Architecture, Compilers and Tools"
421 страница.
>>>> А надо было не удалять свою же реплику про "short pipeline" и
>>>> "small branch penalties", которые, якобы, были проблемой Итаниума.Не надо было.
И её никто не удалял.> Специально для неосиливших поиск, цитирую комментарий №355
Да, умение пользоваться поиском - полезный навык.
Тут сложно не согласиться.
Если Вы им овладеете, это может Вам помочь в ситуациях подобных этой.
>>>>> А надо было не удалять свою же реплику про "short pipeline" и
>>>>> "small branch penalties", которые, якобы, были проблемой Итаниума.
> Не надо было.
> И её никто не удалял."Сие есть Ваши два предыдущих комментария.
Это не звоночек, любезный собеседник."Осталось как-то согласовать оба этих выпада.
К "про удаление сформулировали двусмысленно" прибегать поздно.
Кому был интересен предмет обсуждения,
а не согласие с топорной манипуляцией "верно?" - тот бы продолжил по существу.>> Специально для неосиливших поиск, цитирую комментарий №355
> Да, умение пользоваться поиском - полезный навык.
> Тут сложно не согласиться.
> Если Вы им овладеете, это может Вам помочь в ситуациях подобных этой.Мне в этой ситуации ничего не надо.
Я не забывал о собственноручно скопированном из книжки тексте.
И не заявлял на основании забывчивости, что кто-то что-то путает.Если всё ещё не понятно объясняю - извинений я не жду.
Не от кого.
> Банально компиляторам не хватало памяти. MSVC отключал оптимизацию для функций,А сейчас ему еще чего-то AFAIK не хватает. Так что воооон там господа забили для студии персональный костыль снижающий время компила с 15 до 1 минуты. Как вы уже поняли GCC и Clang такие времена и без костылей показывали...
Нет. Итаник погубила плохая производительность на среднестатистическом выхлопе компиляторов и отсутствие обратной совместимости с x86. И то, и другое актуально и сегодня.
И как там у M1 с обратной совместимостью? Вот именно, что никак.Нахрен покупателям не нужна была такая совместимость. Но переплачивать вдвое за где на копейку большую, а где-то вообще меньшую производительность они почему-то не захотели.
Глупости. Как и в прошлый раз, когда Apple переходила с PowerPC на Intel, почти всё старое ПО (читай: ПО под Intel) отлично и без всяких тормозов работает через Rosetta.
> Глупости. Как и в прошлый раз, когда Apple переходила с PowerPC на
> Intel, почти всё старое ПО (читай: ПО под Intel) отлично и
> без всяких тормозов работает через Rosetta.то есть совместимость процессора - совершенно и не нужна. О чем и речь.
(ну и насчет без тормозов - это тебя, гм-гм, нае...ли. С другой стороны - этот интел и в режиме эмуляции будет в разы быстрее того что он эмулирует, поскольку там совсем уже каменный век.)
нужна не совместимость процессора а совместимость софта.
> когда Apple переходила с PowerPC на Intel, почти всё старое ПОТогда они колдовали только с запуском своего ПО, и то от таки сырой ОС Х, и весьма в малых количествах того самого ПО. Что подтверждается тем, что когда похерили Розетту, мир не перевернулся от "массы пропавшего ПО".
Объёмы не те были, и разнообразие не то.А с Rosetta2 не всё так хорошо. Да, конечно в мире эмуляторов это гигантский шаг, но для конечного пользователя маловато. Для intel ПО брать Мак почти извращение.
Плюс дохлое железо в ранних М1, мало ОЗУ, и почти без дисковой памяти, и не массовые из за цен вменяемые конфигурации, что тоже насолило Розетте2.
Так M1 это для apple фанатиков, которым опенсурс продают за деньги.
А в 2000х не было ни фанатиков, ни такого влияния опенсурса.
> И как там у M1 с обратной совместимостью? Вот именно, что никак.Это другая экосистема. В Windows же обратная совместимость возведена в культ.
В винде времен итаниумов с обратной совместимостью (не на итаниумах а на обычных x86) было не плохо, а совсем никак - досовские программы не работали почти все, win16 - работали...msовские. Которые быстренько перестали быть нужны поскольку первыми же и получили версии под win32. Остальное - все что посложнее калькулятора - толком не работало или глючило.При этом был лучший дос-чем-windows, и чем он закончился мы все прекрасно знаем. Там совместимость была прекрасная, но почему-то это не помогло. (Почему-то - да потому что опять уе...щные компиляторы, на сей раз от ibm, помимо прочих проблем.)
Культ - это когда пользователи веруют, что совместимость есть. С Итаником потребовалась бы помощь десятка Кашпировских.
> Культ - это когда пользователи веруют, что совместимость есть.ну это да.
> С Итаником потребовалась бы помощь десятка Кашпировских.или гений уровня Белларда (потому что у маков вполне получилось в те же самые годы - но у них была своя атмосфера). Мощности-то наверное и хватило бы.
Но с интелом у него почему-то дружба не сложилась.
> При этом был лучший дос-чем-windows, и чем он закончился мы все прекрасно
> знаем. Там совместимость была прекрасная, но почему-то это не помогло. (Почему-то
> - да потому что опять уе...щные компиляторы, на сей раз от
> ibm, помимо прочих проблем.)потому что лучший дос-чем-windows был написан под определенное аппаратное обеспечение, и хотя частично был совместим с ibm-pc, работал на них не раскрывая всей мощи.
Небольшая просьба:> В винде времен итаниумов с обратной совместимостью (не на итаниумах а на обычных x86) было не плохо, а совсем никак - досовские программы не работали почти все
Не затруднит ли Вас написать название этого невиданного Windows?
(
Чтобы "два раза не вставать": Windows NT 4.0 ( м.б. и NT 3.51 )
выполнял DOS ПО весьма близко к идеалу.)
ваше "dos по" это которое использовало int21h (желательно только документированную его часть) и ни в коем случае никуда не лазило напрямую? А вы можете конечно же назвать такое ПО, актуальное во времена nt4.0 посложнее команды more ? dbase было уже немного немодно.А с актуальным к примеру для нас тогда clarion все было именно даже не плохо а очень плохо. (Он уже научился в сети и в dos4Gw к тому времени)
> ваше "dos по" это которое использовало int21h (желательно только документированную его часть) и ни в коем случае никуда не лазило напрямую?Да, к четырём ( по количеству) COM-ports
> А вы можете конечно же назвать такое ПО, актуальное во времена nt4.0 посложнее команды more ? dbase было уже немного немодно.Да, могу.
См. ниже>А с актуальным к примеру для нас тогда clarion все было именно даже не плохо а очень плохо. (Он уже научился в сети и в dos4Gw к тому времени)
( как бы это написать повежливее... )
Поздравляю:именно про Кларион можем плотно пообщаться. Работал с ним со второго курса ВУЗа.
Clarion умел в сеть всегда. В CFD 2.X тоже.
В DOS Extenders стал уметь с CDD 3.X
Их там - несколько. Скорее, несколько режимов.У меня "на полке" лицензионные комплекты документации и прочее.
Так что ставить в AMD SimNow?
И принципе, можем и в те эмуляторы, где есть CPU энского года. ( Какого кстати?)
> Да, к четырём ( по количеству) COM-portsCOM порты это единственное что в NT4 работало в досовых прогах. А, еще кажется порты SoundBlaster и WindowsAudio. Остальное было порублено и не работало никак, соответственно. Какой-нибудь прямой доступ к диску? Win95: показывает специфичный диалог, мол разрешить, запретить? В NT4 просто наглухо обламывается и программа не работаает в принципе. Как-то так.
И совместимость NT4 с досовыми программмами была в общем то - по сути никакой. Сильно некоторые вещи типа _некоторых_ досовых игр и терминалок даже работали. Остальное - фигвам.
> COM порты это единственное что в NT4 работало в досовых прогах. А, еще кажется порты SoundBlaster и WindowsAudio. Остальное было порублено и не работало никак, соответственно.Были нужны именно COM порты.
Они работали.
Я лично не помню ужасов с совместимостью с DOS. М.б. у кого-то они и были.(
Мы же начали с вопроса нужна ли совместимость?Ответ Microsoft на тот момент был - нужна. Если что-то не работало, то они это стрались исправить
)
> Так что ставить в AMD SimNow?NT 3.1, для начала. Ну или хотя бы 3.51 (не, не знаю где взять. не хранил)
А потом пытаться установить, запустить clarion и скомпиленный им код. Код я увы, за почти тридцать лет все таки прое...л, но там ничего сложного не было, складской учет.При этом под win95 оно работало. Да, могло конечно повиснуть при отладке (все же dos4g апликуха) - но происходило это достаточно редко. С сетью тоже все ок - база лежала на новеловской шаре. Локи работали. Это сейчас не потестишь, конечно, но у меня до этого и не доходило никогда (с новелом у NT 3 было все особенно хреново).
> NT 3.1, для начала. Ну или хотя бы 3.51 (не, не знаю где взять. не хранил)А потом пытаться установить, запустить clarion и скомпиленный им код.
> При этом под win95 оно работало. Да, могло конечно повиснуть при отладке (все же dos4g апликуха) - но происходило это достаточно редко. С сетью тоже все ок - база лежала на новеловской шаре. Локи работали. Это сейчас не потестишь, конечно, но у меня до этого и не доходило никогда (с новелом у NT 3 было все особенно хреново).
Однако, я в 2000-ом году застал уже NT 4.0 TS ...
NT 3.51 недавно где-то видел.
Novel Netware можно запустить в Virtual PC. И одну из версий NW в Hyper-V.
Сам IDE Clarion -а использует локальный Btrieve.
Откомпилированное, как правило, просто клиент Btrieve или файловую "шару".
Итого: проверить всё это "в сборе" реально, вопрос в сроках...Я тут рядом написал ( туда и переадресую Ж-) ), что MS старалась сделать совместимость и т.д.
> Однако, я в 2000-ом году застал уже NT 4.0 TS ...И мы радостно выбросили клэрион в помойку, и перенесли все проекты на oracle - который для нее уже был. Даже несколько раньше - в 98м, наверное.
Ну а мне пришлось переквалифицироваться окончательно в админы, поскольку такое программирование ничуть не увлекало.
> Я тут рядом написал ( туда и переадресую Ж-) ), что MS старалась сделать совместимость и т.д.
старалась, но это получилось именно к четверке и 2000. Когда как раз окончательно стало никому не надо - в 2000м у меня уже ничего не было из досовских программ для работы.
А у ранних версий с совместимостью все было крайне странно (особенно на фоне тогдашних лидеров рынка), и MS явно совершенно сознательно принесла ее в жертву.
ничего, что кастомеры M1 и кастомеры Intel - это не то что не муж и жена, а вообще четыре разных человека?кастомеры М1 сглотнули, и когда им явочным порядком 32-битный софт усекли. зачем им совместимость, если их насильно через аппстор апгрейдят и каждый год выпускают новое OOOH SHINY!!!1
валяйте, расскажите какому-нито заскорузлому интеловскому кастомеру, что совместимость не нужна. вас за это даже из окна не выкинут - вас в здание не впустят, шуз контроль не пройдете.
Itanium не был плох в абсолютном смысле, он был плох по сравнению с x86-64. Itanium имел высокую производительность в вычислениях с плавающей запятой и параллельных задачах, благодаря своей VLIW-архитектуре и большому количеству регистров. ¹² Он также имел преимущества в надёжности и безопасности, такие как ECC и RAS. ¹³Однако Itanium страдал от низкой производительности в целочисленных вычислениях и последовательных задачах, из-за своей низкой частоты и сложности компиляции оптимального кода. ² Он также не имел обратной совместимости с x86, что означало, что он не мог запускать большинство существующих приложений и операционных систем без эмуляции или перекомпиляции. ¹ Это снижало его привлекательность для потенциальных клиентов, которые предпочитали более дешёвые и универсальные решения на базе x86-64.
Таким образом, Itanium не был погублен только плохой производительностью или отсутствием обратной совместимости, а комбинацией этих факторов и других проблем, таких как высокая цена, низкая доступность и слабая поддержка со стороны разработчиков ПО.
Источники:
(1) Itanium - Wikipedia. https://en.wikipedia.org/wiki/Itanium.
(2) Intel’s Itanium Takes One Last Breath: Itanium 9700 ... - AnandTech. https://www.anandtech.com/show/11372/intels-itanium-takes-on....
(3) Intel® Itanium® Processor Product Specifications. https://ark.intel.com/content/www/us/en/ark/products/series/....
Каким боком itanium к x86_64. Itanium это интеловский Эльбрус.
Скорее интеловская Transmeta
Ну да, возможно это лучшая аналогия. Просто судя по комментариям тут большинство не понимает что итаники были типичными VLIW процами со всеми их достоинствами и недостатками. Про трансмету эти комментаторы скорее всего еслии слышали то не знают что это такое. А с Эльбрусом эти "специалисты" давно выработали условный рефлекс поливать говном при одном только упоминании.
VLIW нежизнеспособна, забудьте. Оптимизации в рантайме статическими оптимизациями не заменяются.
Потому и не взлетело.
Точнее - жизнеспособна, но только в самом-самом ядре проца, когда более сложный код развёрнут _вместе с данными_ (статическим оптимизациям сие как раз таки недоступно) и передан для выполнения на VLIW.
Фанаты e2k по ходу отминусовались, но - лошадь лает, а караван лежит в канаве. Такие дела.
> VLIW нежизнеспособна, забудьте. Оптимизации в рантайме статическими оптимизациями не
> заменяются.
> Потому и не взлетело.vliw отлично себя сегодня чувствует в dsp.
Так что не стоит так категорично заявлять.Сама по себе идея vliw очень элегантна, но в чистом виде, видимо, не очень практична.
Ну, так и x86_64 сегодня совсем не cisc, каковым, по старой привычке, его считают.Какой же это cisc, если 10 машинных мнемоник разваливаются внутри процессора на несколько сотен уопов, и переопределяются, даже без механизма кэша, каким-то совершенно чудным образом?
Так и vliw, для успешного широкого применения в системах общего назначения если и взлетит, то в сочетании ещё с каким-то механизмом.Но не в чистом виде.
> vliw отлично себя сегодня чувствует в dspЯ там не зря дополнил :)
DSP и generalized CPU - совершенно разные вещи.> Сама по себе идея vliw очень элегантна
Но к сожалению годится только для непосредственно исполнительной части, упаковка в неё команд требует наличия данных.
(плотная упаковка)
>> vliw отлично себя сегодня чувствует в dsp
> Я там не зря дополнил :)
> DSP и generalized CPU - совершенно разные вещи.
>> Сама по себе идея vliw очень элегантна
> Но к сожалению годится только для непосредственно исполнительной части, упаковка в неё
> команд требует наличия данных.Ну, вот на ту часть, которая связана с данными - явно напрашивается присутствие какого-то дополняющего решения.
А, может быть, даже не дополняющего, а переосмысляющего vliw как некую штуку с управляющим потоком идущим командами перехода от одного функционального блока процессора к другому.
Была такая вещь, как TTA-архитектура в которой делали нечто подобное.Дальше лезть не буду, ибо с моей стороны это, безусловно, дилетантские рассуждения.
Всё это очень интересно, но чтобы об этом судить квалифицированно - нужно залезать слишком глубоко в непрофильную (для меня) область.
> Ну, вот на ту часть, которая связана с данными - явно напрашивается
> присутствие какого-то дополняющего решения.Угу. И называется оно конвеер, который увязан с транслятором команд, спекулятивным выполнением и соответствующими оптимизациями, и получается x86.
>> Ну, вот на ту часть, которая связана с данными - явно напрашивается
>> присутствие какого-то дополняющего решения.
> Угу. И называется оно конвеер, который увязан с транслятором команд, спекулятивным выполнением
> и соответствующими оптимизациями, и получается x86.Про его издержки конвейра со спекуляцией тут уже все осведомились.
В том виде, в котором он есть, про безопасные архитектуры можно забыть - и Вы это знаете.
> Про его издержки конвейра со спекуляцией тут уже все осведомились.
> В том виде, в котором он есть, про безопасные архитектуры можно забыть - и Вы это знаете.Поскольку in vitro в лабораторных условиях с side channel не играюсь - как-то абсолютно не интересно.
>> Про его издержки конвейра со спекуляцией тут уже все осведомились.
>> В том виде, в котором он есть, про безопасные архитектуры можно забыть - и Вы это знаете.
> Поскольку in vitro в лабораторных условиях с side channel не играюсь -
> как-то абсолютно не интересно.Удобно, согласен.
А вот некоторым организациям интересно, чтобы у них ин виво это не происходило.
Ну, да это их проблемы, верно?
> А вот некоторым организациям интересно, чтобы у них ин виво это не происходило.In vivo шанс эксплуатации спектров - около 0. Интересно разве что каким-либо DoD, и да - это их проблемы.
Смотри, на улице можно оступиться, упасть, и сломать себе хвост.
Как часто это происходит?
Будешь каждый день снижать скорость хода до шага в минуту и обвязываться матрасами ради исключения такой вероятности?
> Смотри, на улице можно оступиться, упасть, и сломать себе хвост.
> Как часто это происходит?
> Будешь каждый день снижать скорость хода до шага в минуту и обвязываться
> матрасами ради исключения такой вероятности?Вы же не ходите по улице.
Вы же сидите в лаборатории и перекладываете пробирки в интвитро режиме.
С Ваших, подчёркиваю, слов.Понятное дело, что Вашему-то хвосту ничего не угрожает.
Но везёт так далеко не всем, знаете ли.
> Вы же сидите в лаборатории и перекладываете пробирки в интвитро режиме.
> С Ваших, подчёркиваю, слов.Я бы это, апдейт парсеру сообщений поставил в вашем случае.
Апдейт - это штука, наверное, полезная.
Но не имеющая никакого отношению к тому, что если Вас безопасность не интересует - то она не должна интересовать и кого-то еще.
> DSP и generalized CPU - совершенно разные вещи.И даже там AMD задолбался и сделал для GPGPU нечто более похожее на обычный проц. Потому что VLIW в чистом виде - достаточно мучителен и обладает специфичными проблемами. Особенно прикольно что любое изменение микроархитектуры "бэкэнда" переклинивает все ABI потому что фронтэнда же вообще нет и это проблемы програмера сразу. Ну или кого там - если ABI отъехало то весь код надо пересобирать, от и до.
Скорее из-за того, что у GPU объём L1I минимальный (32k/4CU в GCN например), да, треды часто одно и то же выполняют, но L1I при этом должен быть очень шустрым.А так всё равно всё через драйвер транслируется, между моделями код всё равно толком не совместим, т.е. в этом плане можно что угодно городить.
Transmeta это компания, где долгое время платили зарплату Линусу.
> Transmeta это компания, где долгое время платили зарплату Линусу.а потом обанкротились ;-)
Но помимо этих сведений, которые знает каждый пингвиноид, у них был еще ан...нетный процессор. Ну оооочень странный. Нивзлетело, да и не должно было.
Отдельно забавно что линукс на них толком никогда не работал.
> у них был еще ан...нетный процессор. Ну оооочень странный. НивзлетелоУ Трансметы был, на своё время перспективно выглядящий (на то время) процессор - VLIW с эмулятором intel кода.
Плюс, тогда была свободна ниша низкопотребляющих процессоров, которую можно было занять.
Народ следил с интересом и ждал.
Ни что не предвещало беды. Но, как водится с VLIW, производительность подкачала, с экономичностью тоже чуда не произошло, а деньги потрачены.Баловстово с VLIW пока всегда заканчивалось печально.
Itanium не имеет ничего общего с Эльбрусом, кроме того, что оба процессора используют VLIW-архитектуру. Itanium - это совместный продукт Intel и HP, который реализует архитектуру IA-64. Это совершенно другая архитектура, чем x86_64, которая является расширением x86 для поддержки 64-битных адресов и регистров. Itanium не совместим с x86_64 и требует специальных компиляторов и операционных систем. ¹²Я упомянул Itanium в связи с новостью о x86S, потому что это был ещё один пример того, как Intel пыталась создать новую архитектуру для серверов и высокопроизводительных систем, но не смогла конкурировать с x86-64 от AMD и своих собственных Xeon. Itanium обещал высокую параллельность и производительность за счёт VLIW-инструкций и большого количества регистров, но столкнулся с проблемами в маркетинге, техническими сложностями и низкой поддержкой со стороны разработчиков ПО. ¹³
Источники:
(1) Itanium - Wikipedia. https://en.wikipedia.org/wiki/Itanium.
(2) Itanium — Википедия. https://ru.wikipedia.org/wiki/Itanium.
(3) Itanium – Wikipédia, a enciclopédia livre. https://pt.wikipedia.org/wiki/Itanium.
В 2000-х наверное VLIW мог бы взлететь, сейчас нет, из-за вездесущего JIT. Теперь почит все компилиться в бинарники на лету, от JavaScript в браузерах до "шейдеров" видеокарт.
У VLIW очень сложные компиляторы, да и сами процессоры компилируют код медленно потому как сильно не любят ветвлений.
Основная фигня упирается в то, что условные инструкции, в т.ч. ветвления, нормально не распараллелить - не известны данные, которые придут.
да. Но и то же самое можно сказать вебмакакам и прочим пожирателям тактов: большое кол-во ядер еще нужно суметь задействовать и не везде это возможно.
Ну вот VLIW и есть то самое большое число блоков, которое хз чем занять.
На этапе статической оптимизации мы не имеем данных, а значит всё неизвестное придётся упаковывать позже.
из VLIW можно сделать хороший DSP хотя бы под конкретный алгоритм
Можно. Ну случай слишком специфичный. И случаев таких не так уж много. Лучше много маленьких ядер тупых и быстрых, чем одно большое и сложное.
Выживают всегда более мелкие.
DSP - это DSP.
В тех же GPU VLIW вполне может зайти.
Но проц общего назначения - это другое (tm)
> В тех же GPU VLIW вполне может зайти.Для игровоых GPU не может. Лет 5 назад игры еще компилили шейдеры при первом запуске (10 минут загрузки), а теперь они это делают на лету, прямо во время игр. Из-за этого на свободных дравах в Linux раньше были лаги при первом запуске игр (пока дисковый кеш шейдеров не заполнится уже скомпилированными шейдерами). Потом Steam разработала замену LLVM компилятора -- ACO. Он компилировал намного быстрее и лаги почти исчезли, теперь еще Vulakan доработали и по бенчмаркам вообще все хорошо стало.
Короче, теперь компиляторы шейдеов работают прямо во время исполнения игр, логика вызова компиляции шедеров находится в игровых бинарниках, а значит компилятор не может работать медленно. VLIW упращает IC но кучу сложности переносит в компиляторы, компиляция VLIW намного дороже. Короче VLIW для игровых GPU вроде как не актуален, либо культура разработки должна поменяться.
> В тех же GPU VLIW вполне может зайти.Да даже там AMD задолбался. Так вместо VLIW стал GCN. Более похожий на обычный проц. Потому что пошла мода на GPGPU и с VLIW "generic" акселерация вычислений - ну вы поняли. Конечно кому сильно надо было (майнеры, etc) чуть не hex-эдитором эффективный поток команд генерили, и там было относительно прилично. Но их таких вообще сколько так смогло? Аж штук пять проектов с кастомными "compute kernel"?
> Но проц общего назначения - это другое (tm)
GPU нынче тоже видите ли больше "акселератор общего назначения". Супермассовый, суперпараллельный SIMD, или типа того.
> с VLIW "generic" акселерация вычислений - ну вы понялиДа, тут можно не объяснять :)
Спекулятивки правда в GPGPU пока нет, но можно ожидать.
Когда уже появятся 128 разрядные компы?
Когда надо будет это адресовать, наверное.
Удваиваю, для арифметических операций есть расширения, а 64-битная шина адресует до 16 млн терабайт памяти.
128 бит это также цисловые операции
Уже давно есть даже 512 битные. Гугли SSE и AVX
Вы бы сами погуглили для начала.
Когда дело доходит до работы с 256 регистрами то быстро выясняется что они в лучшем случае обрабатываются как 4 регистра по 64 бита, те если нужно сложение/умножение/сдвиг и прочее то это не одна инструкция а набор который обрабатывает переход через границу 64 бита.
128-битными CPU считаются, когда у них РОНы 128-битные.
> Когда уже появятся 128 разрядные компы?Примерно когда появится IPv7 или другой номер, если будет 7 занято, как было с IPv5. Номер 5 уже был занят в заголовке в другом RFC.
Никогда не понимал про ipv1 ipv2 ipv5
Эльбрусы в "защищенном режиме" 128-битные. Уже сейчас.
Где!?
На амазоне нет, на ебее нет, на алишке тоже нет.
У того разработчика ОС много интересных гипотез, например, #define в языке Си объявляет переменную.
на Авито посмотри
а, ну да, ты же не в России
Там теоретические выкладки, так что там в военное время 512 битные процессоры бывают...
> Эльбрусы в "защищенном режиме" 128-битные. Уже сейчас.Кто допустил этого программиста на баш до разработки операционных систем и почему эти люди ещё на свободе?
"""
В архитектуре E2K представлен сверхбольшой файл регистров. Все регистры E2K являются универсальными и могут содержать как целочисленные данные, так и числа с плавающей запятой. Всего имеется 256 регистров длиной по 64 разряда каждый. В E2K есть два почти симметричных кластера, каждый из которых содержит по 256 регистров.
""">> регистров длиной по 64 разряда
64 разряда - это 64 бита, если выражаться на твоей мове.
А как они стэк сохраняют в таком монстрятнике? И сколько времени в этой штуки переключение контекста вообще занимает с такими регистровыми файлами?
> А как они стэк сохраняют в таком монстрятнике? И сколько времени вты бы сперва уточнил, есть ли у них вообще этот самый стек.
А то ж это изобретали во времена всеобщей любви к 360.
> этой штуки переключение контекста вообще занимает с такими регистровыми файлами?Если стека нет и второго регистрового файла для ring0 тоже нет - то доооолго.
Так сохранять надо не при переходе в ядро (что надо, и так сохраняется в прологе функции, которая вызывает шлюз). Сохранять и восстанавливать надо при переключении на другой поток. На каждый поток теневых регистров не напасёшся.
Из нижеследующего я понял, что сохранять надо 32 регистра, остальные (стековая часть) отображены в память (представляют собой вариант быстрого кеша, ячейки которого адресуются явно)."9.3.1 Рабочие регистры
...
Рабочие регистры составляют регистровый файл. Размер регистрового файла - 256 регистров. Ну-
мерация регистров и их форматы приведены выше на рисунке D-2. Регистровый файл разделен на
две части: глобальную и стековую. Глобальная область находится в верхней части регистрового фай-
ла (младшие номера) и состоит из 32 регистров. Остальные 224 регистра составляют стековую часть
регистрового файла. Глобальная часть регистрового файла доступна во всех процедурах и не участ-
вует в процедурных механизмах. Стековая область регистрового файла используется в процедурных
механизмах и может быть аппаратно откачана в память или загружена из памяти."
Однако в другом месте пишут (см. ниже), что регистры не отображаются. Вероятно, это относится к первым 32-м регистрам. Это цитаты из "Руководство по эффективному программированию на платформе «Эльбрус» Выпуск 1.0". Талмуда по системному программированию у меня нет, это надо вон того программиста операционных систем спрашивать (кто 64 разряда адреса + 64-х разрядный тег назвал "Эльбрусы ... 128-битные").
"8.2 Виды локальности данных...
ˆ простые локальные данные без взятия адреса:
– местоположение - регистры;
– время жизни - до выхода из процедуры;
– регистры не отображаются в память, ни с кем не конфликтуют;"
> Эльбрусы в "защищенном режиме" 128-битные. Уже сейчас.Только, это WLIW, под который никак не осилят вменяемые компиляторы, иначе б о проблемах переноса ПО не знал только ленивый. А если нет возможности даже простой перетрансляции, без конского падения производительности, то считай, что процессора и нет.
Берешь ПЛИС, берешь спецификацию RISC-V в частности RV128I добавляешь к этой базе все нужные расширения и не забываешь про расширение Q которое позволяет работать с 128 битными числами с плавающей запятой. Потом пишешь софтовое ядро вот с этим всем для плис и вот он 128 битный процессор.
Fabrice Bellard сделал софтовый эмулятор RV128IMAFDQC https://bellard.org/tinyemu/
А как же святая скрепа интел-мира - ОБРАТНАЯ СОВМЕСТИМОСТЬ?
Что же скажуть УВАЖАЕМЫЕ КОРПОРАТИВНЫЕ КЛИЕНТЫ с аппами на коболе?Не из-за этого же похоронили итаниум, не?
Или они необучаемые, или одно из двух.
Одно из трех.
как запускали в виртуалках, так и дальше будут.
Ахиллесова пята итаника была не в том что они там напрямую не запускались, а в том что он и виртуализацию не умел. Но и это только вторично - первично что компиляторы для него у интела не получились, а MS было неинтересно.
Не, тут уже будет тяжелее, тут придётся старые приложения через QEMU гонять :), в режиме эмуляции CPU, со всеми вытекающими.
Нет, не придётся. Читайте внимательнее. Старые ядра придётся гонять в режиме эмуляции. Приложениям придётся от некоторых инструкций отказаться, типа строковых, да от доступа к портам ввода/вывода (кто-то этим пользовался из ring-3?).
> Приложениям придётся от некоторых инструкций отказаться, типа строковыхИ как вы предлагаете это с легаси в режиме эмуляции делать?
Короче только виртуализация инструкций, такие дела. Со всеми вытекающими.
А никто не использует сейчас строковые инструкции. Они -- пережиток 70-х и 80-х. Загляни в любой memcpy или strlen и ты увидишь. Я не уверен, что можно написать такой код на C, который gcc будет компилировать с использованием строковых инструкций, мне кажется надо на асме писать, чтобы так получилось.
Расскажи это Линусу. И Intel, которые планомерно уже лет 10 эти самые строковые инструкции оптимизируют.
Префикс размера адреса тоже предлагается убрать. Т.е. читайте внимательнее, да.
А он зачем нужен? Когда-то давным давно, когда я миксовал 16-битный код с 32-битным, я не просто знал, зачем он нужен, но даже пользовался им. А вот сейчас я не совсем помню, и даже не уверен как он работает в защищённом режиме. Им кто-то пользуется ещё?
https://man7.org/linux/man-pages/man2/ioperm.2.html
> Приложениям придётся от некоторых инструкций отказаться, типа строковых...Вот вы бы внимательнее и читали. Строковые инструкции никуда не денутся.
> Не, тут уже будет тяжелее, тут придётся старые приложения через QEMU гонять
> :), в режиме эмуляции CPU, со всеми вытекающими.Учитывая насколько они старые, оно "и так сойдет!"
> Ахиллесова пята итаника была не в том что они там напрямую не запускались, а в том что он и виртуализацию не умел.Виртуализация там есть.
ПО в полном комплекте OS HP-UX.
>> Ахиллесова пята итаника была не в том что они там напрямую не запускались, а в том что он и виртуализацию не умел.
> Виртуализация там есть.
> ПО в полном комплекте OS HP-UX.виртуализация возможна даже на 8086 - просто работать это будет чудовищно медленно.
А паравиртуализационных технологий в том древнем итанике не было от слова совсем.То есть их тогда нигде вообще не было кроме пресловутой дос-виртуализации в 386 и выше, которой в итанике тоже не могло быть.
Да, вполне возможно что белок-истеричек убедила бы и такая, целиком софтовая виртуализация в режиме лишь бы запускалось. Но тогда это мало кто умел из крупных игроков. Джобс был гений, что понадеялся на настолько сырые и непроверенные методы.
>> Виртуализация в Itanium есть.
>> ПО в полном комплекте OS HP-UX.
> виртуализация возможна даже на 8086 - просто работать это будет чудовищно медленно.Не исключено: так и не сумел заполучить системный блок в монопольное использование.
Соответственно - не проврил ту виртуализацию в деле.
Но: в Virtual PC на "обычном Intel" всё работало быстро. С VPC Addition
> виртуализация возможна даже на 8086 - просто работать это будет чудовищно медленно.Потому что Вы говорите не о виртуализации, которая таки не возможна,
а о эмуляции, той что адски медленная, но возможна. На все 640 кб.
На продажи Интела посмотри за последние овердофига лет. Даже закон Мура уже много лет не выполняется. А это была маркетинговая основа Интела. Пора сбрасывать этот баласт и это делает невидимая рука рынка.
Продажи интела занимают десятки процентов рынка. AMD в какой-то момент единицы процентов имел, и это не помешало ему подняться вновь. Ты рано списываешь Intel со счетов.
Вот только АМД единицы процентов имела тогда, когда Интел давил её антирыночными способами вроде подкупа торговых сетей и производителей готовых сборок, чтобы они не продавали/использовали процессоры АМД и/или никак их не рекламировали и не продвигали. Плюс откаты за закупку именно камней Интел. Плюс мощнейший маркетинг. При этом, АМД выпускала вполне годные процессоры и фразу "FX тащит" хоть в камне высекай.А что у Интела сейчас? Он сливается сугубо по техническим причинам, будучи неспособным создавать продукцию лучше, а зачастую даже на уровне конкурента. АМД как выпускала хорошие процессоры, так и выпускает, а Интел просаживается в качестве вместе с потерей рынка и рекордными убытками. У Интела ситуация совсем не та же, что у АМД десять лет назад.
> Вот только АМД единицы процентов имела тогда, когда Интел давил её антирыночными способами вроде подкупа торговых сетей и производителей готовых сборокВот-вот. И это не помешало AMD подняться. Они выпустили пару линеек неудачных процессоров, но потом выровнялись.
> будучи неспособным создавать продукцию лучше, а зачастую даже на уровне конкурента.
AMD тоже не мог, лет 10-15 или около того.
> Интел просаживается в качестве вместе с потерей рынка и рекордными убытками
У тебя данные какие-то корявые. Рынок Intel не потерял, лишь часть рынка. И Intel продолжает быть прибыльной компанией с миллиардными доходами. Более того, они продолжают привлекать инвестиции.
Загляни сюда: https://www.intc.com/news-events/press-releases/detail/1615/...
Net income: $2.8 миллиарда.
Хе-хе, вы серьезно думаете, что там есть конкуренция?Интел создал амд и выкормил его грудным молоком просто чтобы он был, чтобы военные контракты можно было получать имея конкурента.
> А что у Интела сейчас? Он сливается сугубо по техническим причинам,
Сейчас у интела есть все, как и было, если захотят они выпустят 17е поколение уже завтра, только зачем им это? зачем продавать за 100 рублей 3 пары носков, когда каждый можно продать за пару тысяч, более того там разработкой занимаются одни и теже люди, что у амд что у интела, просто ходят туда сюда и разрабатывают одно и тоже, амд может и лучше, гдето и это компенсируется оптимизацией софта, так что в среднем они братья близнецы, и да если вдруг, случится чудо, и амд каким-то образом перестанет быть альтернативкой для гиков, то что поменяется? все менеджеры уволятся из интел и устроятся в амд, потомучто опыт, связи и тд и тп, ну будет интел альтернативкой и что дальше то.
> Сейчас у интела есть все, как и было, если захотят они выпустят 17е поколение уже завтра, только зачем им это?Во времена «бульдозеров» это ещё могло более-менее убедительно звучать.
> Интел создал амдНекоторые дурачки так полагают, но на то они и дурачки, чтобы чушь нести.
> если захотят
Только что-то "не хотят" и теряют рынок.
Простите, не знал что вы из этих, плоская земля, рептилоиды, независимый амд
> Простите, не знал что вы из этих, плоская земля, рептилоиды, независимый амдДавай ты пруфанёшь про созданную интелом амд или ты будешь просто очередным треплом.
а давай ты хоть на википедию сходишьIn 1976, Intel needed a second source to produce its 8085 processor for IBM PCs so it turned to AMD. In 1982, Sanders was responsible for a renegotiated licensing deal that would enable AMD to copy Intel's processor microcode to make its own x86 processors, a deal that eventually made the company the only real competitor to Intel.[2][3] The open-ended legal language of the deal was used by Sanders to lead efforts for AMD to reverse-engineer and clone Intel's 8086 processor. Intel successfully countersued AMD which caused AMD's stock to collapse and nearly killed the company.[9]
> а давай ты хоть на википедию сходишь
> In 1976, Intel needed a second source to produce its 8085 processor
> for IBM PCs so it turned to AMD. In 1982, Sanders
> was responsible for a renegotiated licensing deal that would enable AMD
> to copy Intel's processor microcode to make its own x86 processors,
> a deal that eventually made the company the only real competitor
> to Intel.[2][3] The open-ended legal language of the deal was used
> by Sanders to lead efforts for AMD to reverse-engineer and clone
> Intel's 8086 processor. Intel successfully countersued AMD which caused AMD's stock
> to collapse and nearly killed the company.[9]Тебе на русский перевести или сам в гугл переводчик скопируешь?
корпоративные клиенты с аппами на коболе сидят на IBM System/Z
Айбиэмовский компилятор кобола самый трушный. Только дома не нём не по программируешь вот программисты и закончились.
Они выкинули 2/3 ядра процессора, это значит энергопотребление снизится пропорционально?
Тебе бы матчать подучить. Чтобы не задавать мудатские вопросы.
Они выкинули 0,01% ядра. Поэтому правильный вопрос: а зачем?
Они выкинули 2/3 ядра процессора, это значит цена снизится на 2/3, за счет сокращения количества транзисторов и отчислений за устарелые патенты?
Нет это значит цены вырастет на 3/2.
Нет.
Это значит что бивисо писателям станет жить легче уже сейчас.
Всем остальным лет через 10-15, когда скажут что совместимость со старьём мы больше не поддерживаем и выкинут из загрузчиков и из ОС поддержку старья.Возможно будет прирост производительности в пределах 10% из за упрощения декодера и ещё чего то.
Это простор для написания нового 64-битного кода во всем. Покупателям это еще придется раскошелиться и на софт, если они использовали 32-х битный.
Написано же: х32 приложения продолжат работать, а всякие х32 и х16 ОС гоняйте теперь в виртуалках.
х32 приложения никогда толком и не работали.
32-х разрядная архитектура официально именуется IA32.
х32 называли 64-х битный режим с указателями размером 32 бита.
64-х битный режим изобрела AMD, соответственно называется он AMD64.
Intel-ам это очень не нравится, они придумали IA32-EMT64, "сообщество" сошлось на компромиссе - x64.
Вся эта затея больше про переименовывание, видимо AMD их немножко двигает на рынке.
Что значит не работали? А если у меня работали?
> Что значит не работали? А если у меня работали?Не все. Драйверы ушли лесом, и системное ПО и активно взаимодействующее с ОС , ушло вдогонку.
Пользователи офисов и игр не должны были ничего заметить, а с системным ПО несовместимость есть.
В x32 системе linux ядро 64-х разрядное, как и приложения. Но адресное пространство последних ограничено 4 гигабайтами. https://opennet.ru/34065-x32
> В x32 системе linux ядро 64-х разрядное, как и приложения. Но адресное
> пространство последних ограничено 4 гигабайтами. https://opennet.ru/34065-x32И это 1 из самых глупых вещей которые можно сделать. Ну например mmap() становится почти бесполезен для работы с вот именно файлами.
Так mmap() не Уних-вей же, а виндузятничество.) Но согласен, что больше пользы бы было, если где это критично, в исходниках заменили 64-х разрядные указатели на индексы. Глядишь, даже на Rust бы написали двусвязный список без unsafe. :)
> Что значит не работали? А если у меня работали?Вы вероятно путаете x32 (это вариант 64-х разрядного) с 32-х разрядным режимом https://opennet.ru/34065-x32
Нет, я как раз ту генту из той новости и внедрял примерно в то время. Были некоторые сложности с ассемблерными вставками и косяками препроцессора в той же libjpeg-turbo, но сишный код был без проблем в основном. В итоге, для десктопа не очень, и нужны патчи (их вроде подвезли, первое время приходилось самостоятельно разгребать), но на типичных околопромышленных применениях вполне работало уже тогда. Ну и потом, с точки зрения экономии памяти дополнительный тулчейн и либы в памяти это может не слишком эффективно (та же проблема со смешением 32 битного кода с 64 битным), но такой код работал ощутимо быстрее обычного 64 битного и понятное дело 32 битного. Конечно, не когда всё завязано на simd, которые отключаешь, чтобы хоть как-то работало.
Околопромышленное применение, это, грубо говоря, запустили некий сервер и админится специалистом по ssh? Под "приложениями" обычно понимаются какие-то программы для пользователей. Для десктопа там очень не очень, отваливалось почти всё, где есть Джаваскрипт, из-за JIT-а: polkit, браузеры. Это было лет через пять после той новости и вряд ли стало лучше.
> Что значит не работали? А если у меня работали?Виноват, поторопился выше. Нашёл Ваш другой комментарий. Ну у меня тоже работали всякие ls и cat, и возможно даже какой-то текстовый браузер, но толку от них не много. Потому у меня и написано "никогда ***толком*** и не работали".
Бивисописателям вообще фиолетово уже давно, с EFI начиная, потому что они прыгают в расширенный режим, и оттуда работают. Другое дело что приходится держать прослойку для легаси интов, но она как бы давным давно написана, и особых проблем уже ни у кого не вызывает.
С нынешней частотой вфхода новых версий 10 лет слишком много.
То, что они выкинули - это тысячная часть, а то и меньше. Все эти устаревшие режимы давно реализованы по остаточному принципу. По большей части, это упрощение жизни для писателей современных ОС и BIOS.> отчислений за устарелые патенты?
Отчислений самим себе, разве что.
> То, что они выкинули - это тысячная часть, а то и меньше.
> Все эти устаревшие режимы давно реализованы по остаточному принципу. По большей
> части, это упрощение жизни для писателей современных ОС и BIOS.
>> отчислений за устарелые патенты?
> Отчислений самим себе, разве что.В пентиумах 3, 4, Core и современные примерно 2/5 состоит из патентов сторонних компаний. 1/3 патенты АМД, и еще немножка патенты других компаний.
Часть лицензионных платежей удалось сократить скупив и поглотив сторонние компании, часть как с АМД - взаимно "обменяться патентами" с правом пользоваться без роялити. при этом за некоторые патенты, которые АМД получила путем поглощения иных компаний, intel им "отстегивает".
Отказ от 16/32 битного легаси не иллюзорно сократит патентную нагрузку.
Там самый прикол был, что патентом на Hyperthreading владела AMD.
https://patents.google.com/patent/US5944816
> Там самый прикол был, что патентом на Hyperthreading владела AMD.
> https://patents.google.com/patent/US5944816Это самое известное. Знакомое хомячкам слово, которое они где-то встречали в рекламе.
В процессоре под крышечкой много патентов, но незнакомые названия ничего не говорят широкой публике.
> Отказ от 16/32 битного легаси не иллюзорно сократит патентную нагрузку.16-битное легаси давно вышло из под всех патентов по сроку годности. 32-х битное если не вышло, то скоро.
> Отказ от 16/32 битного легаси не иллюзорно сократит патентную нагрузку.Какая нагрузка? Патенты действуют 20 лет, через 20 лет ты можешь делать на их основ что угодно и с тебя никто не потребует отчислений.
Даже тут человек кинул ссылку на патент HT и там черным по белому написано Expired. Патент выдан в 1996, и Anticipated expiration в 2016.AMD64 был преставлен в 2000-ом году, это значит что прямо сейчас можно выпускать AMD64 совместимые процессоры без страха судебных преследований, и без необходимости уплаты отчислений. Другое дело что тот же AVX нужно лицензировать, как и все прочие наработки последних десяти лет.
Кстати h.264/AVC part 1 исполняется 20 лет 30 мая этого года, так что если использовать его без новых фичь то через 9 дней это будет роялтифри кодек :)
> Кстати h.264/AVC part 1 исполняется 20 лет 30 мая этого года, так
> что если использовать его без новых фичь то через 9 дней
> это будет роялтифри кодек :)как раз когда все прогрессивное человечество перешло окончательно на 265/hevc :-(
У нового и прогресивного есть выбор между HVEC и лоялти фри AV1.
>> Отказ от 16/32 битного легаси не иллюзорно сократит патентную нагрузку.
> Какая нагрузка? Патенты действуют 20 лет, через 20 лет ты можешь делать
> на их основ что угодно и с тебя никто не потребует
> отчислений.JFYI патенты продлеваются и отсчет строка начинается заново.
JFYI -- нет, патенты не продеваются, 20 лет! Патент на продукт не может привышать 14 лет с момента его выхода на рынок.
reexamination и reissue не влеяет на срок действия патаента. Все это гуглится. Ненужно распостронять заблужения.
Какая нахрен патентная нагрузка, у патентастов из Intel соглашение о кросслицензировани патентов с другими патентастами.
> Какая нахрен патентная нагрузка, у патентастов из Intel соглашение о кросслицензировани
> патентов с другими патентастами.Соглашение о одном патенте не отменяет платы за тысячи других патентов.
.
.
.специально для людей с коротким буфером ввода, вмещающим половину первого предложения сообщения и бросающимся отвечать, я буду писать короткие сообщения в одно предложение.
> Отказ от 16/32 битного легаси не иллюзорно сократит патентную нагрузку.Тебя не смущает собственное существование?
Ведь патента на РНК/ДНК до сих пор нет.
А результатом реализации пользуются все, бесплатно, по праву рождения. Еще и с удовольствием :)
>Они выкинули 2/3 ядра процессора, это значит цена снизится на 2/3Нет, это значит, что они смогут впихнуть ещё пару ядер и соответственно увеличить цену. Это же Intel.
По цене дешевле АРМ будет?
Интел могли бы уже и свою RISC архитектуру сделать давно.
> Интел могли бы уже и свою RISC архитектуру сделать давно.i960 ?
Pathfinder ?
У них и так все процессоры это RISC, но прикрытые эмулятором x86
Вот это эмулятор/транслятор выкинуть первым.
Угу. И останется неоптимизируемое ядро. Данных вам кроме как в рантайме ниоткуда для оптимизации расстановки потока команд не дадут.
А что, ARM дёшев? Что-то не особо заметно.
M1, M2 не дёшевы.
> А что, ARM дёшев? Что-то не особо заметно.Вон там одноплатник с 4 ядрами за 10 баксов за все лежит. Размером с кредитку, 512 оперативы, питается от зарядки для мобли. Удачи на x86 что-то сравнимое за те же деньги взять вообще.
А весь проц, с чипом power manager внагрузку - пять баксов. При этом управление питанием там уже сильно лучше любых атомов. Итог? Тихая, холодная, практически вечная система (ни 1 электролита который может забеременеть) задешево. А микроконтроллеры так и вообще менее доллара на ARM уже.
Они Итаниум переизобрели?
Просто они пытаются наконец все сделать правильно. Посмотрим что у них получится.
> Просто они пытаются наконец все сделать правильно. Посмотрим что у них получится.Идеальные процессоры уже были, и они не стали коммерчески успешными.
Когда появился Athlon 64, прирост в 5-10% при использовании тяжёлых приложений, вроде Maya и Nuke, обеспечивался даже без правки кода. Чисто засчёт использования регистров большего размера.
Но специалисты в то время сказали, что прирост мог бы стать выше, если бы решили прекращать совместимость с 32 бит.
Но такой процессор уже был, и это был Итаниум. Там совместимость с 32 бит дропнули на аппаратном уровне.
Он мог бы "взлететь", если бы AMD64 не появился. Когда в какой-то момент пользователя уже прижмёт ограничение в 4 Гб ОЗУ.
Однако вышел Athlon 64. И рынок выбрал его.
Так тогда интел и сделали всё неправильно. И Итаниум не мог взлетел его не туда позиционировали.
> Так тогда интел и сделали всё неправильно. И Итаниум не мог взлетел
> его не туда позиционировали.ИМХО, если бы AMD не выпустили свой 64-битный процессор - время Итаниума рано или поздно пришло бы.
Нет, не пришло бы. Итаник - мертворожденный проект.
С чего бы? Представь: 2003 год. Мы находимся в некоей параллельной реальности, в которой AMD64 никогда не релизился. Есть два процессора: Pentium IV и Itanium. Какой выберешь? Ты выбираешь Pentium IV, потому что Итаниум не очень хорошо запускает твою Win98SE. Плюс ко всему, зачем тебе IA64, когда у тебя до сих пор 256 Мб ОЗУ на компе? Ведь, согласно этой табличке, опубликованной кстати в 2003 году:https://www.ixbt.com/news/hard/index.shtml?00/30/14
Массовое использование 4 Гб оперативки будет лишь в 2007 году.
2006 год, виста. Продолжишь сидеть на Pentium IV, или таки перекатишься на Итаниум? И ты перекатываешься. А старый легаси-софт уже не так критичен.
Мне кажется, что всё так и планировалось. Но релиз AMD64 спутал интелу все карты.
P.S. По поводу того, что Itanium никогда не позиционировался, как массовый проц. Так и Centrino и Pentium M тоже никак не продвигались, однако какой из них красивый Core2 получился.
Не, IA64 должен был рано или поздно прийти на смену IA32. Это даже следует из его названия. Но кто же знал, что AMD сделает свой 64-битный процессор, который не совместим с IA64?
> Не, IA64 должен был рано или поздно прийти на смену IA32. Это
> даже следует из его названия. Но кто же знал, что AMD
> сделает свой 64-битный процессор, который не совместим с IA64?Ну, скорее даже, не то, что "AMD сделает свой 64-битный процессор, который не совместим с IA64", а "AMD сделает свой 64-битный процессор, который совместим с IA32".
А так ещё - и разработку у Intel-а затянули, и компилятор не смогли нормальный написать.
А как же Apple Silicon...
>Идеальные процессоры уже были, и они не стали коммерчески успешными.Про SPARC64 ты, наверное, не в курсе? Не идеал, но получше x86 тормозинтела.
Кстати, можно было по лицензии выпускать, но интелу прибыль важнее, если их выпердыши с 8086 совместимостью покупают, зачем делать лучше. Любой самый современный x86_64 до сих пор умеет реальный режим 16bit, нафейхуа?
Для задач реального времени? У Шаттла были 8086 и реальное время и все работало всем всё нравилось.
Ну да, а виртуальный режим для задач виртуального времени, жги исчо :)
>>прибыль важнееА на что же тогда выпускать процессоры, с чего финансировать разработки..
Это стремление неизбежно.
> Про SPARC64 ты, наверное, не в курсе? Не идеал, но получше x86 тормозинтела.Плохо поддерживается софтом и огроменный очень. Без вертикального масштабирования. Сани вывалили один из спарков опенсорс. А толку? В FPGA за потребные деньги такой монстр не зальешь, уменьшить его - уй, а это не предусмотрено, а пары миллионов зелени чтобы хзчто на фабу выгрузить, посмотреть в железе, у вас тоже наверное нет...
И в результате вроде крутой артефакт - но вот что с ним делать хрен его знает?! RISCV в этом смысле народу сильно лучше зашел, есть куча разных ядер от мелких и лайтовых которые на совсем копеечной FPGAхе запустятся, до огроменных высокопроизводительных монстров которые даже в сервера ставят.
SPARC Version 9, the 64-bit SPARC architecture, was released by SPARC International in 1993.Не напомнишь, у какого интела в 93 году был 64bit? А насчет масштабируемости - непонятно, что ты имел в виду, но SPARC = Scalable Processor Architecture, есличо.
Насчет поддержки софта и "огроменности":
1. Архитектура, железо и софт изначально работают в защищенном режиме, причем переключение контекста на порядок дешевле, чем у выпердыша x86++. Кстати, Windows NT 3.* была для SPARC, если кто не в курсе. По стоимости да, очень дорого в сравнении с x86+win, особенно в версии с OEM. Ну и еще, клоны x86 были у Cyrix, AMD, NEC, итд. Но это уже лицензионная поликика, к архитектура проца тут не причем. Тем более, что IPM PC тогда тоже клепали все, кому не лень, потому, что можно было.
2. Размеры cpu не имеют значения, motherboard(в некоторых случаях fatherboard, кстати) все равно больше. Тем более, уменьшение техпроцесса никто не отменял. Ну не получится у тебя одноплатник 10X10 см в конце 90-х, начале 2000-х. Разве что 80186, который SoC.А насчет fpga - ну да, запихнуть 386/486/Pentium было гораздо проще, ага :)
Просто в то время x86+win - для захвата рынка пропихивалось на всех уровнях.P.S. IBM Power/PowerPC вполне себе коммерчески успешен, кстати, рыночек порешал :)
>Просто они пытаются наконец все сделать правильно.Ты с какой планеты?
Интел и правильно - это нонсенс.
Это же ты со мной спорил в защиту то ли ноды жс, то ли шарпов? Не удивительно
Нет, это был не я
Вопрос к сведущим, если такие внезапно оказались на сайте: это сильно поможет программистам? Скажется ли подобное упрощение положительно на производительности из-за отсутствия нужды переходить в 32-битный режим работы?
99.9% программистов на это наплевать. Они всё равно используют готовые компиляторы и операционные системы. По большому счёту, современному программисту абсолютно всё равно, компилировать под Интел, АРМ, PowerPC или Эльбрус.Немного повлияет на писателей BIOS и загрузчиков ОС.
Есть косвенные эффекты.
> Есть косвенные эффекты.для программистов на Pyton PHP perl 1c?
Например, груб запускается в 16-битном режиме. НУ придётся переписать на 64 бита. А для чего ещё может понадобиться 16 бит -- даже не знаю.
Нет, на системах с efi grub НЕ работает в 16-битном режиме.
Явно на новых процессорах загрузка в режиме legacy не будет подерживаться, останется только uefi.
> это сильно поможет программистамТолько некоторым системщикам и то не сильно. Смогут костыли убрать, grub сможет похудеть, учиться будет проще.
> Скажется ли подобное упрощение положительно на производительности из-за отсутствия нужды переходить в 32-битный режим работы?Включение станет чуть быстрее, но скорее всего вы этого не заметите.
Нет и нет. Если ты будешь код под голое железо писать без ОС, то надо полагать тебе станет проще (со временем станет, когда в интернете накопится опыта как писать, которым можно дополнить документацию, разбираясь в нюансах). На производительности это вряд ли скажется. Может быть Intel количество транзисторов таким образом смог снизить, но это не повысит тактовую частоту или ещё что, может быть чуть больше ядер удастся впихнуть на кристалл или кеша добавить, но даже если это случится, вряд ли настолько чтобы быть заметным.Загрузка может стать чуть быстрее, но никто не заметит этого. Все эти заполнения таблиц страниц и переключения между режимами хоть и выглядят вечностью для выполняющегося кода, но это больше о том, что конвееры сбрасываются, кеш обнуляется и тп. Займёт это 10k тактов процессора, и чё? 10k тактов/гигагерц, это сколько в секундах? Это конечно же оценка +- порядок, но ты посчитай и прикинь: оно ни на что не влияет заметным образом.
Люди охладели к 64-х гиговым модулям памяти. Надо подстегнуть.
ИИ выдал ТЗ: зачем мне заморачиваться в 16 и 32 битных клетках.
Мне нужен простор без преград.
он не работает на cpu
Прекрасно работает, погуглите llama.cpp
Медленно, хреново и ненужно работают. Надо Нвидию она умнее Линуса.
И не слова о том, как они учли свои прошлые промахи с Meltdown и Spectre.
> И не слова о том, как они учли свои прошлые промахи с
> Meltdown и Spectre.Учли. Новые фичи будут тщательнее скрываться от неквалифицированной публики.
И проц самостоятельно в фоне будет обновлять микрокод, ага.
Ну чтобы пользователи не сильно переживали.
Меньше знаешь - больше прибыль производителю.
По HTTP.
а какая разница, на уровне протокола или же на уровне подписанного микрокода выполняется проверка подлинности подписанного обновления? хоть вручную вбивай с распечаток газет, лишь бы распаковалось корректно
С подписанным микрокотом осторожнее - может оцарапать при утечке ключа очередной :)
> И проц самостоятельно в фоне будет обновлять микрокод, ага.
> Ну чтобы пользователи не сильно переживали.
> Меньше знаешь - больше прибыль производителю.Не "будет" а "продолжит". в остальном всё верно.
Не, производителю прибыль больше, когда пользователь в магаз бежит за обновлением.
Наши процессоры быольше не тормозят на ваших 32-битных программах с 2 Гигабайтами данных? Ну они точно затормозят на only-64-битных с 2 Терабайтами данных :)
Годно, как раз под Gentoo nomultilib.
Всё 32 и 16 битное старые можно вполне запускать в эмуляторе, оно уровня пентиум 2 максимум, когда 256 мегабайт памяти хватало всем, а сейчас новый комп меньше чем с 32 гигами покупать смысла нет
А как быть с играми? Сталкер или Half-life.
Можно в них просто не играть.
Использовать современные движки с поддержкой x64. Для Сталкера это OpenXRay, для Халфы это Xash3D (да и порт на Source есть). Да и скорее всего современные процессоры (и тем более будущие) на изи вытащат эмуляцию x86 игр.
А эти современные движки будут поддерживать такие штуки как EAX, A3D? А как на этих движках будет аыглядеть сама игра? Не измениться ли графон?
у тебя ЭЛТ монитор, что тебе так нужен тот картофельный графон из прошлого?
> А эти современные движки будут поддерживать такие штуки как EAX, A3D? А
> как на этих движках будет аыглядеть сама игра? Не измениться ли
> графон?Будут, если не запилят что-то лучше. И графон можно оставить без новых фич, просто не включая их в настройках (хотя и зачем бы это делать?).
> такие штуки как EAX, A3DТакие штуки сейчас где-то поддерживаются?
Игры уже лет десять как 64-битные, а для старья и эмуляции хватит.
А в сторону 128 битных процессоров они пока не смотрят!?
Нет. Никому не нужен такой утюг.
Не прошло и 20 лет. Совместимость им, блдЪ, мешала. Ну так выпускали бы две архитектуры, одну для совместимости со старым "бизнес" софтом и новую. Армы и итаники отдельно осилили, а отдельную линию для 64бит онли - не смогли, ага. И биосу заранее надо было заранее альтернативу сделать.
А сейчас петух реально клюнул, от армов, амуде и прочих рисков, засуетились. Поздновато.
Ещё раз - камень без совместимости не взлетел бы. Ты можешь взять программу от Windows 3.1 и запустить на 11ке. Я я реально до сих пор использую несколько программ времён Windows 95. Проприетарных, но freeware, скачанных из web.archive.org. Они маленькие, свою работу делают, шпионов не содержат. При этом "современные" аналоги требуют оплату.И таких пользователей много. У кого диск с софтом к аппаратуре, у кого программа на бейсике, написанная давно уволенным человеком, и без исходников. Не говоря уже о тех, кто такие программы реверсит и переписывает с нуля - тем вообще аппаратная поддержка x86 жизненно необходимо. Есть куча геймеров, играющих в старые игры. Есть куча пользователей Office XP/2003.
Обратная совместимость - это killer feature. Если бы её не было, то не было бы Винды - системы, созданной для того, чтобы
* можно было установить ВСЕ НУЖНЫЕ ПОЛЬЗОВАТЕЛЮ ПРОГРАММЫ (а не только те, что есть в пакетах в канале портов для нужной архитектуры) и чтобы они РАБОТАЛИ;
* можно было разрабатывать программы под систему, проприетарные, и продавать их, и чтобы их покупали, ибо чтобы покупающий был уверен: программа заработает и у него, и, что немаловажно, у его знакомых, друзей, клиентов и контрагентов (так что файлы, созданные этой программой они смогут о крыть).Вместо одной большой винды была бы куча пердольных экосистем, каждая со своим набором софта, и никакого будущего с AGI в 2023 году бы не было, потому что индустрия бы задерхалась в развитии.
>Обратная совместимость - это killer feature. Если бы её не было, то не было бы Винды - системы, созданной для того, чтобыЗахватить рынок персональных компьютеров.
Связка IBM PC+Win* - киллерфича для монополизации персоналок. Всё остальное - чистая демагогия.При этом угробили действительно грамотные альтернативные архитектуры: DEC, Sun Microsystems, SGI.
По поводу старого софта и железок - ну смешно, бизнес покупает не софт и железо, а программно-аппаратный комплекс, готовое решение, со всеми гарантиями и рисками. Остальное - плач нищебрoдoв(без обид, это бизнес).
Если интересно, поищи в инете инфу, когда появились AMD64 и 64 ос и софт для него. Всякие офисы, адобы и прочие 3дмаксы с катями.
P.S. На всякий случай напоминаю, я писал про то, что интелу было бы несложно выпускать ДВЕ архитектуры x86-64 и x64-only, выпускали же итаник. А рыночек уже порешал бы :)
( вопрос был не ко мне лично, ну да ладно...)> когда появились AMD64 и 64 ос и софт для него.
Первым был Microsoft Exchange 2007.
Помнится, что системный блок под него так и нашёлся в то время. Т.е. x64 был первые пару лет экзотикой.
Нужно понимать что это следствие монополии Интела. Экономические последствия и даже действия компании после исчезновения монополии в экономике давно известны. Все просто действуют по известным шаблонам.
На Хабре есть отличная серия статей Made at Intel. В ней рассказывается, в частности, про баталии вокруг системы команд — https://habr.com/ru/articles/664682/«И все же важнейшей религией компании является сама x86 Instruction Set Architecture. Intel изначально свято придерживался принципа backward compatibility - программы написанные для предыдущих поколений процессора работают на следующих без изменений (ну разве что требуют эмулятора операционки). Без этого нельзя построить никакой экосистемы, ибо ее формирование процесс занимающий многие годы. И именно благодаря последовательности Intel x86 ISA стала для компьютерного мира чем то вроде христианства.»
И как всегда, старое гуано с кешем в новую обертку занесут. Штеуд, ёп.
И как обычно, переключение контекста опять дорогое по выполнению получится.
Что они там эстонское курят, интересно.
Только системная архитектура IBM PC никуда не делась, со всей стародревней фигней типа системы прерываний, говношин PCI* и идиотской(в сравнении с другими архитектурами) реализацией защищенного режима. В какие материнки будут ставить это "новое"?
Не взлетит, системные "гири" от старой архитектуры никуда не денутся.
На самом деле да, можно упростить, но выигрыш это даст только в плане сложности транслятора, т.е. это удешевление производства скорее. Никаких особых выигрышей для юзера сие не несёт.
И да, у этой фигни будет одна малюсенькая проблема - совместимость с оборудованием. Часть оборудования включает в себя собственные биосы / модули EFI, не все из которых смогу работать на упрощённом варианте CPU.
> И да, у этой фигни будет одна малюсенькая проблема - совместимость с
> оборудованием. Часть оборудования включает в себя собственные биосы / модули EFI,
> не все из которых смогу работать на упрощённом варианте CPU.Этой проблемы не будет если сделать новую архитектуру исключительно под новый сокет.
Под отдельный PCIe, хотел сказать?
Т.е. два набора плат, один под x86, второй под очередное интеловское чудо?
Да нет, просто инициализацию опять придётся отдать монструозному биосу (как бы он там ни назывался), нет поддержки инициализации вот конкретно этой платы в таковом - всё, приплыли.
То есть прокатит разве что на серверах, но там оно вообще низачем.
Не нужно. Главный козырь x86 - совместимость. Потеряв совместимость ... ну есть же системы команд arm, riscv, mips, sparc, elbrus, где команды может и другие, но хотя-бы не такая помойка, как x86.Интелу просто надоело обеспечивать совместимость со старьём. Но проприетарная ISA, с legacy осталась и никуда не делась!
Лучше бы новые камни делали с аппаратной поддержкой risc5 и wasm - больше толка бы было.
Вэбщики должны исчезнуть вместе со своим WASM.
> Главный козырь x86 - совместимость.Уже нет. 20 лет назад главным козырем была совместимость, сегодня уже нет. Сегодня роль играет совместимость юзерспейса, но не биосов-хуиосов. И Intel, как мы видим, это понимает. В отличие от анонима опеннета, чьё мировоззрение застряло в 90-х.
А я и говорю про совместимость юзерспейса. Совместимость с уже написанными программами. Гарантии, какие-никакие, но гарантии, что в будущем эти программы не превратятся в тыкву. Речь не идёт про эмуляторы. Эмуляторы никогда не заменят нативного исполнения и memory breakpointы.
У Apple эмуляторы прекрасно заменяют нативное исполнение, и не первый раз уже.
Совместимость уходит на второй план, когда у твоих конкурентов типа ARM есть преимущество как раз таки в отсутствии легаси кода с которым нужна совместимость.
По моему ты пишешь бред.
Совместимость - это то, без чего бизнес невозможен. Никто не будет строить бизнес на зыбучих песках железа, не совместимого с программами, написанными до и после него. Никто не будет покупать программы, которые придётся заново покупать после того, как вендор выкатит новую версию железа.Для того, чтобы трюк интела прокатил, ему нужно монополизировать разработку софта.
И какие же порограммы бизнес сейчас покупает?
Бизнес поэтому всегда держит в кладовке старые компы.
На тех же госуслугах подписать документ можно только зайдя через edge, а на странице подписания включив режим MSIE иначе "криптокомпонента не загружена" 🤣
Вот это реально бред.
Твои понятия о бизнесе и использование "никто не будет" какбэ намекает :).
А я думаю что всё у них получится в наш-то век повсеместного JavaScript и HTML.
Так то и у ARM и RISC-V получится.
И ничего не меняется. Промышленный legacy-софт работает на таких же legacy-утюгах, где техпроцесс размером с кулак, а хомячок разницу не увидит.
> Прекращение поддержки доступа к портам ввода/вывода из 3 кольца защиты.Я далеко не знаток, конечно, дилетант скорее, но возник вопрос. Это что, микроядерные ОС типа QNX, у которых в нулевом кольце только микроядро, сильно ограниченное базовым функционалом, а драйвера в юзерспейсе (кольцо 3), печально уходят вдаль и машут нам ручкой? Ведь для них, наверное, доступ к I/O из юзерспейса должно быть фундаментальным требованием. К примеру, всё что можно было накрутить вокруг семейства микроядер L4 (очередную "ОС на коленке") теперь будет курить бамбук? Иначе что это будет за "надежная безопасная микроядерная ОС", если у нее в нулевом кольце будут с микроядром и дрова крутиться? Взять ту же Genode (не знаю как там всё это реально устроено) - там разные микроядра можно "снизу" подсунуть, но дрова, как и прочие сервисы, там ведь тоже наверное не в нулевом кольце?
Грубо говоря, регистры устройств отображаются на адресное пространство и для доступа к ним используется обращение по указателю.
Вопрос был не что такое порты I/O и как с ними работать, это понятно, а про то, что будет с теми ОС (и подобными), что я написАл. Ведь, если я правильно понял, если у тебя отобрали доступ к портам из кольца 3, то при попытке отобразить порты в адресное пространство кольца 3 или при попытке обращения по такому отображенному адресу тебе на аппаратном уровне покажут болт. Вопрос был - обязателен ли, прям кровь из носу, для таких ОС доступ к портам ввода/выода из кольца 3 или я что-то про них не так понимаю. А насчет отображения портов устройств на адресное пространство - у меня когда-то давно в 90-х даже курсовая была про подобную фигню, нарисовать схемы железки еще для древней шины ISA.
На самом деле это решается. В ядре, в обработчике исключения, выполняется анализ команды, которая выполнялась, и она выполняется уже в нулевом кольце. Мы так делали, например, с командой wrmsr, которая в 0 кольце разрешена, а в 3-тьем - нет.
А производительность?
Ага. Я даже хотел про это написАть в предыдущем ответе, что теоретически можно что-то типа как при работе с виртуальной памятью закостылить - страницы в физической ОЗУ не нашли, генерируем исключение и обработчик из свопа подгрузил. А тут такой же посредник для работы с портами. И хотел написать, что такого не предлагать. Думаю понятно что по производительности будет полнейшая опа. Да в таком случае вообще смысл запускать драйвера в юзерспейсе отпадает. Микроядерные ОС и так хейтеры ругают, что у них слишком много переключений контекста происходит. Вот представьте, что вы написАли драйвер к быстрой железке для микроядерной ОС, т.е. это процесс в юзерспейсе. В случае если у вас есть доступ к портам из юзерспейса - в драйвере, который как обычный процесс выглядит, получил через микроядро сообщение/RPC от клиента (увы, через переключение контекстов), полез из драйвера "напрямую" в порты железки, почитал их, пописАл - сделал свое черное дело. А с обработчиком в кольце 0 и запретом работы из кольца 3: драйвер в юзерспейсе получил сообщение от клиента, полез почитать/пописАть порты - а каждое обращение на чтение/запись - это исключение с переключением контекста в кольцо 0 и обратно. Лепота.
> Ага. Я даже хотел про это написАть в предыдущем ответе, что теоретически
> можно что-то типа как при работе с виртуальной памятью закостылить -
> страницы в физической ОЗУ не нашли, генерируем исключение и обработчик из
> свопа подгрузил. А тут такой же посредник для работы с портами.Сейчас, в основном, с портами никто не работает - всё, более-менее скоростное отображено на память, так-что просадка будет, но, имхо, не критичная.
точно. Порты закрыли для кольца 3, а mmio гоняй откуда хочешь куда хочешь и как хочешь
> точно. Порты закрыли для кольца 3, а mmio гоняй откуда хочешь куда
> хочешь и как хочешьСгонять в ФИЗИЧЕСКУЮ память из юзермода операционки - вообще достаточно отдельный квест. Который ядро если и позволяет, то только руту. А может и совсем не позволять (если например режим lockdown активен).
> Вопрос был не что такое порты I/O и как с ними работать,
> это понятноКак раз это и не понятно. Команды in и out появились в процессорах, когда шина адреса была узкая, её хватало лишь на небольшое по объёму ОЗУ, 64 Кб и меньше. При исполнении команд ввода-вывода процессор на специальной ножке выдавал сигнал "я обращаюсь не к ОЗУ, а к периферии". Позже адресное пространство увеличилось и стало больше объёма ОЗУ. Что позволяет зарезервировать диапазон адресов для доступа к устройствам. Теперь процессор читает-пишет память обычной командой mov, контроллер (мост) смотрит на значение адреса, если попадает в диапазон - перенаправляет обращение к регистрам устройства.
Попробуйте команду
lspci -vv | grep Region
Более того - со временем люди поняли что DMA это круто, быстро и эффективно. Так вообще никаких команд не надо - только сетап железки и потом она сама поток данных гоняет. А проц может заняться чем-то более полезным. И когда периферия стала скоростной и продвинутой - вон то, с in и out стало, пардон, архаикой. DMA с физическими адресами оперирует как правило.В мире где в моде сетевые, коммуникационные, периферийные интерфейсы с скоростями в десятки гигабит и более обкладываться DMA-движками, при том с обоих сторон линка, почему-то очень модно.
Порты ввода-вывода - это команды in/out
А отображённые на память регистры устройств для проца ничем не отличаются от оперативки - так что если ОС отмапит страницу юзерского пространства на них, работать с ними ничего не помешает.
Как забавно читать комментарии на опеннете.Раньше ныли о том чтоу intel legacy мешал, производительность сдерживал, энергоэффективность понижал (особенно в сp*чах о arm). А сейчас когда intel начал legacy выпиливaть как снова все недовольны.
Луддиты, сэр.
Комментарии на опеннете вообще всегда читать забавно, этакое guilty pleasure.
А не может быть так, что как выкинут легаси так залочат загружаемую ОС и рынку обычных ПК каким мы его знаем придёт конец?
Как у Эппл? Но даже там Линукс запускается.
> Как у Эппл? Но даже там Линукс запускается.Захотят запустится, не захотят не запустится...
Контроль то за запуском у них, а не у нас.
Наконец хоть один всё понял.
Что мешает сделать это прямо сейчас?
Ничего.https://www.linux.org.ru/forum/security/16550382?cid=16567177
https://www.opennet.me/openforum/vsluhforumID3/130402.html#119
Ну сейчас с рынком пк таки всё в порядке?
Будут китайские компы с китайскими процами, а интел просто уйдёт в закат. Вместе с амудой.
> Ну сейчас с рынком пк таки всё в порядке?
> Будут китайские компы с китайскими процами, а интел просто уйдёт в закат.
> Вместе с амудой.Боюсь как бы следом за НАТО/АКУСовскими производителями следом в закат не ушёл и опенсорс, потому как по странному стечению обстоятельств коммунистические государства более склонны к проприетарщине...
>> Ну сейчас с рынком пк таки всё в порядке?
>> Будут китайские компы с китайскими процами, а интел просто уйдёт в закат.
>> Вместе с амудой.
> Боюсь как бы следом за НАТО/АКУСовскими производителями следом в закат не ушёл
> и опенсорс, потому как по странному стечению обстоятельств коммунистические государства
> более склонны к проприетарщине...То есть, сейчас все железо опенсорсное, а всё китайское будет проприетарным?
Ну бред же.Железки как были закрытыми, так и останутся, только управляться будут не американским, а китайским агенством нацбезопасности, причем тут вообще опенсорс?
> То есть, сейчас все железо опенсорсное, а всё китайское будет проприетарным?
> Ну бред же.Оно будет залоченным без возможности разлочки, а на таком железе опенсорс начнёт гнить и потихоньку вытеснятся проприетарщиной.
>> То есть, сейчас все железо опенсорсное, а всё китайское будет проприетарным?
>> Ну бред же.
> Оно будет залоченным без возможности разлочки, а на таком железе опенсорс начнёт
> гнить и потихоньку вытеснятся проприетарщиной.Ты об этом?
https://en.miui.com/unlock/index.htmlИли вообще о чем? Сейчас на всех материнках м периферии закрыто вообще всё(за очень редким исключением), биос/уефи закрыт, фирмвари железок тоже. Как и микрокод для процов.
Доверяешь американским компаниям, всяким там эпплам, деллам и прочим хьюлетам мать его пакардам?
Оракл вообще обмазан доверием по самые уши, zfs подарил, по доброте душевной, не иначе :)
Не переживай, вендорлоки в скором времени будут везде, это общемировая тенденция. И не китаем начата, кстати.
>Ты об этом?
>https://en.miui.com/unlock/index.html.О этом и о том, что ты далее написал, и как я вижу вы согласны со мной что будущее СПО выглядит довольно мрачным, но у меня есть та надежда, что при сохранении торговли между политическими блоками не будут блокировать загрузку сторонних ОС в продаваемых. между блоками машинах, что повлечёт выпуск незалоченных машин и для внутреннего рынка для удовлетворения спроса на компы способные работать с произвольными операционными системами.
> по странному стечению обстоятельств коммунистические государства
> более склонны к проприетарщине...не понятно с чего Вы это взяли? При том-же СССР был считай этот самый Open Source во все поля. Разрабатываемые системы с ПО поставлялись со всеми исходниками. Даже к телевизору схема электрическая поставлялась.
>> по странному стечению обстоятельств коммунистические государства
>> более склонны к проприетарщине...
> не понятно с чего Вы это взяли? При том-же СССР был считай
> этот самый Open Source во все поля. Разрабатываемые системы с ПО
> поставлялись со всеми исходниками. Даже к телевизору схема электрическая поставлялась.Вы не понимаете, "этодругое".
Биосы закрыты, процы с микрокодом тоже, фирмварь на железках закрыты, но виноваты китайцы, патамушта коммунисты. Обычная манипуляция, ничего нового.Зато интел вон какой молодец, "развивает упрощенную архитектуру".
То есть, весь тот оверпрайснутый интел треш, который продается больше 30 лет - это нормально, а китайские процы с китайской же периферией - убъет опенсорс.
> Вы не понимаете, "этодругое".Где я говорил что американская проприетарщина в смысле проприетарщины лучше китайской?
> Зато интел вон какой молодец, "развивает упрощенную архитектуру".
Я между прочим прямо высказал опасение что следующим шагом после удаления легаси интел и амд полностью товоизируют платформу чем уничтожат рынок альтернативных ОС.
> То есть, весь тот оверпрайснутый интел треш, который продается больше 30 лет - это нормально, а китайские процы с китайской же периферией - убъет опенсорс.
Вы не поняли идею, если оба политических блока товоизируют свои платформы то опенсорсу просто не на чем будет работать.
ОБА политических блока.
Все плохие гады проприетарщики, на всём земном шаре ни одного свободного места не будет.
>Все плохие гады проприетарщики, на всём земном шаре ни одного свободного места не будет.А сейчас оно есть?
Если ты так думаешь, у меня для тебя плохие новости. Очень плохие.
> Даже к телевизору схема электрическая поставлялась.С схемой от телевизора у тебя недопонимание: она прилагалась не для тебя, а для ремонтников из мастерской по починке.
При этом то, что кто-то начнёт в сарае делать по этой схеме телевизоры на продажу не предполагалось вообще.
> не понятно с чего Вы это взяли? При том-же СССР был считай этот самый Open Source во все поля. Разрабатываемые системы с ПО поставлялись со всеми исходниками.Отчасти это было следствием эпохи, когда программы были утилитами, а не законченными средствами производства как сейчас, от части тем что программы были побочным продуктом деятельности автора, отчасти тем, что что всё производство принадлежало государству и по сути оно публиковало программы само для себя.
Так вот, особо важно последнее, то что государство производило программы само для себя, то есть и автор программы, и тот кто будет программу применять являлись частью этого единого государства.
Но свободный софт существует не внутри одного субъекта, а между равными личностями, а вот тут оказывается что государство относится к физическим лицам не только пренебрежительно, но и с презрительным недоверием, потому что за время коммунизма привыкло работать только со своими субъектами.
Да, РФ формально СПО признаёт, но признаёт ли оно его законы?
Насколько наше государство готово работать с адептом СПО независимо от его гражданства оценивая его первую очередь как адепта СПО, а не участника той или иной официальной структуры созданной для коллективной защиты и формализации деятельности в правовом поле адептов СПО, или просто даже какой проприетарной конторы с учётом соглашений о не конкуренции и пр. подобных документов подписанных этим человеком?
А насколько признаёт законы СПО Китай, для которого СПО лицензия просто ещё одна бумажка которую надо по возможности объегорить?
>> Даже к телевизору схема электрическая поставлялась.
> С схемой от телевизора у тебя недопонимание: она прилагалась не для тебя,
> а для ремонтников из мастерской по починке.
> При этом то, что кто-то начнёт в сарае делать по этой схеме
> телевизоры на продажу не предполагалось вообще.ПЭВМ Специалист предполагалось делать "в сарае". Там даже специально придумали технологию стежкового монтажа (не вполне удачную, но это уже вторично). И подпаивали эти машины к телевизорам как раз по прилагаемой к последним схеме.
Про программы молчу. Если бы ты умел не только повышать энтропию, но и ходить по ссылкам, то увидел бы у меня на гитхапе страницу из журнала с кодом для калькулятора.
> ПЭВМ Специалист предполагалось делать "в сарае". И подпаивали эти машины к телевизорам
> как раз по прилагаемой к последним схеме.Наличие возможности не означает того, что возможность закладывалась изначально.
Официальный мотив сопровождения электроапааратуры схемами это невозможность в каждую ремонтную мастерскую поместить схему каждого выпущенного в СССР телевизора, а вовсе не признание за гражданами права ремонтировать или изменять телевизор самим.
>> ПЭВМ Специалист предполагалось делать "в сарае". И подпаивали эти машины к телевизорам
>> как раз по прилагаемой к последним схеме.
> Наличие возможности не означает того, что возможность закладывалась изначально.Да, я знаю, что наличие у тебя возможности ознакомиться с предметом и почитать об истории создания ПЭВМ Специалист не означает, что ты это сделаешь.
Свой комментария я написал в ответ на твой для других читателей, а не лично тебе.
Кто был в СССР помнит
>"Вскрывать телевизор может только специалист"https://cs14.pikabu.ru/post_img/2021/08/15/10/16290450491877...
> Да, я знаю, что наличие у тебя возможности ознакомиться с предметом и
> почитать об истории создания ПЭВМ Специалист не означает, что ты это
> сделаешь.Посмотрел начало темы https://ruecm.forum2x2.ru/t70-topic
Как я понимаю это очередной компьютер на основе кр580/Z80 как я понимаю государство к началу этой гиковской разработки никакого не имеет.
Тебе не стоит искать примеры с опенсорсом тех времён, потому что для формирования СПО сообщества нужна точка в котором оно может собираться, а это минимум BBS, что находится технологически на уровень выше таких компьютеров.
(при этом не важно как будет осуществляться эта разница, как ЦПУ с более ёмкой шиной данных или как наращивание 8 битных миникомпов объединённых по транспьютерной или схеме или по схеме комутационной матрицы(свич))
>> ПЭВМ Специалист предполагалось делать "в сарае". И подпаивали эти машины к телевизорам
>> как раз по прилагаемой к последним схеме.
> Наличие возможности не означает того, что возможность закладывалась изначально.
> Официальный мотив сопровождения электроапааратуры схемами это невозможность в каждую
> ремонтную мастерскую поместить схему каждого выпущенного в СССР телевизора, а вовсе
> не признание за гражданами права ремонтировать или изменять телевизор самим.А для кого были схемы в журнале "Радио"?
Напомни, к схемам, которые прилагались практически к любому электронному устройству были номера патентов и предупреждения, что тот, кто прочитал эти схемы не имеет права что-либо менять или ремонтировать? Вот и я не помню такой фигни в СССР. Патенты - это алчность, капитализм, ёп.
Ну не было в СССР после сталинского периода частных(кооперативных) производств. И схемы печатались в любой тематической литературе.
> А для кого были схемы в журнале "Радио"?Вопрос не в том для кого были эти схемы, а в том как с этим работало государство.
Вот к примеру взять упомянутый где-то в этом топике компьютер "Наставник".
Пригласили ли автора на базе созданной им сети автоматизировать бухгалтерию, складской учёт и планирование работ на предприятии?
Захотели ли предприятие организовать на основе его сети деловую переписку между разными территориально разнесёнными отделами.
Может его пригласили сделать какую распределённую АСУ?
Что ему доверили из того, что довольно быстро капиталисты стали доверять ОС Linux и сопровождающим её гикам?
Выросла ли из наставника система автоматизации если не АЭС, то хотябы ГЭС или теплораспределительного пункта?
Сделана ли на базе Наставника система электронной рассылки новостей о общественной жизни и политике?
Ничего ему государство не доверило, только позволило применить его Наствника в школе по его основной работе и дальнейшего развития в строну кровавого энтерпрайза его проект развития не получил, его максимум это перенятие опыта другими школами по его использованию как ни за что не отвечающее учебное пособие.
И то что куча людей воспроизводило этот Наставник не приводило к росту этого комплекса как проекта, по сути усилия людей утилизировались в воссоздании одного и ого же проекта школьно обучающего компьютера без роста авторитета и качественного усложнения задач и амбиций.> Напомни, к схемам, которые прилагались практически к любому электронному устройству были
> номера патентов и ...Я не о патеннтах, а о отношении к "народному творчеству" как к чему то безполезному что посмотреть да бросить, потому что по факту так и есть, если не доверять сделать что-то значимое, то значимого сделано и не будет.
>> Даже к телевизору схема электрическая поставлялась.
> С схемой от телевизора у тебя недопонимание: она прилагалась не для тебя,
> а для ремонтников из мастерской по починке.
> При этом то, что кто-то начнёт в сарае делать по этой схеме
> телевизоры на продажу не предполагалось вообще.Продавать - не имели права, а делать Вам запретить никто не мог. И Вам не кажется, что при тогдашней централизации всего, по вашему подходу, гораздо проще было отсылать схемы сразу в мастерскую - и бумаги меньше потратят, и коварные частные собственники не смогут сами телевизоры с сарае изготавливать.
>> не понятно с чего Вы это взяли? При том-же СССР был считай этот самый Open Source во все поля. Разрабатываемые системы с ПО поставлялись со всеми исходниками.
> Отчасти это было следствием эпохи, когда программы были утилитами, а не законченными
> средствами производства как сейчасне только. Были, может и не средства производства, но вполне себе законченные системы.
> Но свободный софт существует не внутри одного субъекта, а между равными личностями,
> а вот тут оказывается что государство относится к физическим лицам не
> только пренебрежительно, но и с презрительным недоверием, потому что за время
> коммунизма привыкло работать только со своими субъектами.у Вас есть примеры такого пренебрежения у СССР? Желательно проверяемые.
> Да, РФ формально СПО признаёт, но признаёт ли оно его законы?
ну, как-бы СССР и РФ это совсем не одно и тоже. У них разные цели, разный общественный строй, разные приоритеты.
> Насколько наше государство готово работать с адептом СПО независимо от его гражданства
> оценивая его первую очередь как адепта СПО, а не участника
> той или иной официальной структуры созданной для коллективной защиты и формализации
> деятельности в правовом поле адептов СПО, или просто даже какой проприетарной
> конторы с учётом соглашений о не конкуренции и пр. подобных документов
> подписанных этим человеком?не знаю, насколько их можно считать адептами СПО, правда, но вот даже на этом сайте есть люди развивавшие Open Source проекты, аккаунты которых, вместе с репозиториями, на github-е удаляли за определённую политическую позицию. Это делали не компартия Китая и не правительство РФ.
> А насколько признаёт законы СПО Китай, для которого СПО лицензия просто ещё
> одна бумажка которую надо по возможности объегорить?У Вас есть конкретные примеры таких случаев в Китае, которых было-бы больше аналогичных в США, например. Особенно если считать с самого возникновения, например той-же GPL - много раз её вполне себе пытались отменить и присвоить себе исходники вполне себе американские корпорации.
Да и, если быть совсем уж честными, неужели Вы считаете, что в Китае коммунизм или хотя бы его строительство?
> Продавать - не имели права, а делать Вам запретить никто не мог.Но на крышке написано "Вскрывать телевизор может только специалист".
https://cs14.pikabu.ru/post_img/2021/08/15/10/16290450491877...> И Вам не кажется, что при тогдашней централизации всего, по вашему
> подходу, гораздо проще было отсылать схемы сразу в мастерскуюПытались, но Иосиф Виссарионович уже состарился и умер, а без него нормально решить логистическую задачу уже не смогли...
> у Вас есть примеры такого пренебрежения у СССР? Желательно проверяемые.
Юридических примеров нет, но обрати внимание, фамилия Кулибин в СССР употреблялась так, что я до сих пор её воспринимаю как ВЫСОКОМЕРНОЕ оскорбление, а прилагательное кустарное как нечто среднее между мошенничество и бомж(я тут несколько преувеличиваю, но сути это не меняет)
И сейчас, какое из госпредприятий попробовало вокруг себя собрать команду СПО разработчиков?
Да даже взять СВО на Украине, военные, военная необходимость, но государство ВОЗМОЖНО только сейчас начало что-то ДУМАТЬ о производстве квадрокоптеров, но именно думать после общественного возмущения, которое игнорировать уже не вышло.
А так недавно у какого-то солдата на КПП отобрали два дрона которые он вёз в Россию для ремонта и теперь, не знаю что там у него, взвод, отряд или расчёт сидит и думает "как мы будем искать цели для стрельбы без этих отобранных дронов?" о чём сообщил один военный блогер в ТГ.
То есть даже ради успеха в войне государство не может снизойти до взаимодействия с гражданским обществом.
Как давно такое происходит?
Не знаю как было с этим в царской России, хотя и там Гоголь писал про Акакий Акакиевича, но вот воспитатель Макаренко воспринимался госбюрократией как чужеродный элемент и обрати внимание при всех хороших словах к этому человеку его методики внедрять не стали, а на оборот, решают вопрос камерами и решётками на окнах школ.>> Да, РФ формально СПО признаёт, но признаёт ли оно его законы?
Ну я выше уже напомнил про то, что армию квадрокоптерами снабжают граждане при полном равнодушии государства, думаешь это исключение, а не правило?
> не знаю, насколько их можно считать адептами СПО, правда, но вот даже
> на этом сайте есть люди развивавшие Open Source проекты, аккаунты которых,
> вместе с репозиториями, на github-е удаляли за определённую политическую позицию. Это
> делали не компартия Китая и не правительство РФ.Я там имел ввиду не политическую позицию, а то, что государство не умеет и до недавнего времени не хотело учится работать с самособравшимся коллективом людей с разным уровнем ОФИЦИАЛЬНО подтверждённого образования или вообще без такового, но тем не менее с знаниями и опытом.
> У Вас есть конкретные примеры таких случаев в Китае, которых было-бы больше
> аналогичных в США, например. Особенно если считать с самого возникновения, например
> той-же GPL - много раз её вполне себе пытались отменить и
> присвоить себе исходники вполне себе американские корпорации.Пытались, но как-то ведь отбились, вопрос в том, смогут ли так же отбиться в РФ или особенно в Китае.
> Да и, если быть совсем уж честными, неужели Вы считаете, что в Китае коммунизм или хотя бы его строительство?
Как бы то ни было, но как я предполагаю формально китаец поднимать руку на коммунистическую идеологию и братские течения не должен, а СПО в чём-то братское течение по отношению к идее коммунизма.
>> Продавать - не имели права, а делать Вам запретить никто не мог.
> Но на крышке написано "Вскрывать телевизор может только специалист".
> https://cs14.pikabu.ru/post_img/2021/08/15/10/16290450491877...ну так и сейчас на зеркалах пишут "Изображение в зеркале заднего вида ближе, чем вам кажется", или как-то так.. Да и про специалиста - нет-же фразы, как в буржуиниях - только сертифицированный центр.
>> И Вам не кажется, что при тогдашней централизации всего, по вашему
>> подходу, гораздо проще было отсылать схемы сразу в мастерскую
> Пытались, но Иосиф Виссарионович уже состарился и умер, а без него нормально
> решить логистическую задачу уже не смогли...ну, вот Вы тоже слышали про артели, которые были при социализме, так-что как-бы сам социализм/коммунизм тут не при чём. Просто конкретные люди, потом, не смогли, а может и не захотели.
>> у Вас есть примеры такого пренебрежения у СССР? Желательно проверяемые.
> Юридических примеров нет, но обрати внимание, фамилия Кулибин в СССР употреблялась так,
> что я до сих пор её воспринимаю как ВЫСОКОМЕРНОЕ оскорбление, а
> прилагательное кустарное как нечто среднее между мошенничество и бомж(я тут несколько
> преувеличиваю, но сути это не меняет)не знаю, может это у Вас такое впечатление сложилось. Для меня фамилия Кулибин по ассоциациям что-то типа Левши - очень талантливый человек, который может делать что-то невероятное.
>> У Вас есть конкретные примеры таких случаев в Китае, которых было-бы больше
>> аналогичных в США, например. Особенно если считать с самого возникновения, например
>> той-же GPL - много раз её вполне себе пытались отменить и
>> присвоить себе исходники вполне себе американские корпорации.
> Пытались, но как-то ведь отбились, вопрос в том, смогут ли так же
> отбиться в РФ или особенно в Китае.не знаю, надо смотреть по фактам. По моему мнению - в США отбились, в итоге, потому, что оно стало нужно крупным корпорациям. Поэтому, в итоге, имхо, и SCO немного того... угомонили.
>> Да и, если быть совсем уж честными, неужели Вы считаете, что в Китае коммунизм или хотя бы его строительство?
> Как бы то ни было, но как я предполагаю формально китаец поднимать
> руку на коммунистическую идеологию и братские течения не должен, а СПО
> в чём-то братское течение по отношению к идее коммунизма.не обязательно, при необходимости можно обозвать ревизионистом/оппортунистом, предавшим идеалы трудового народа, с вытекающими последствиями.
Впрочем, предлагаю на этом завершить - это политика и к конкретной архитектуре x86S отношения не очень имеет.
> Впрочем, предлагаю на этом завершить - это политика и к конкретной архитектуре
> x86S отношения не очень имеет.Хорошо
> не знаю, может это у Вас такое впечатление сложилось. Для меня фамилия
> Кулибин по ассоциациям что-то типа Левши - очень талантливый человек, который
> может делать что-то невероятное.Так даже предложенный вами Левша весь роман потихоньку терял прочность своего социального положения и закончил тем что на коленях(по крайней мере в мультике) просил не чистить ружья керпичами но был послан куда подальше государственными чиновниками после чего умер.
То есть всё тоже про что я вам говорил.Но пожалуй закончу с некоторым оптимизмом, общение не с телевизором и прочим подобным, а с некоторыми, не всеми, живыми людьми IRL и в интернете побуждает меня несколько поправить мой печальный словарь по крайней мере при общении с такими людьми.
А напомни, плиз, откуда вылезли понятия патент, промышленный шпионаж, авторское право, недополученная прибыль, уголовная ответственность за нарушение лицензионного соглашения и прочие ограничения свободы?
Все живые существа пользуются генетическим кодом, который каждый получает по праву рождения.
Сколько недополученной прибыли зря пропадает :)
> А напомни, плиз, откуда ...Я не понял куда вы клоните, можете написать более прямолинейно, без косвенных указаний и загадок?
"коммунистические государства более склонны к проприетарщине" - это кто написал?
Кроме разработок, составляющих военную и гостайну всё остальное отдавалось всем и бесплатно.
А по теме обсуждения интел успешно использует парадигму "сделай сразу хреново, чтобы все мучались и платили, а потом упрости то, что считаешь нужным, чтобы продолжали платить".
Реализация защищенных режимов в 386 была сделана через две жопы, якобы для совместимости, а на самом деле чтобы не упустить прибыль от пользователей DOS программ. Ну а дальше по накатанной дорожке. Четвертый пень был вообще "шедевром" впаривания гoвна за оверпрайс.
> Кроме разработок, составляющих военную и гостайну всё остальное отдавалось всем и бесплатно.Вы не поняли почему я так говорю, проприетарщина не столько про прибыль, сколько про выстраивание деловых отношений и опора коммунистических стран на бюрократию и планирование, признание ими только того, что подчинено этой системе создаёт не менее душное отношение чем самый жадный и агрессивный патентный троль.
Это естественная плата за то, что даже человек принимающий конечные решения по факту является управляющим и по этому должен ради своей безопасности создавать бюрократическое оправдание своих действий.
>> по странному стечению обстоятельств коммунистические государства
>> более склонны к проприетарщине...
> не понятно с чего Вы это взяли? При том-же СССР был считай
> этот самый Open Source во все поля. Разрабатываемые системы с ПО
> поставлялись со всеми исходниками. Даже к телевизору схема электрическая поставлялась.Объяснение банально. Вы пишете "Open Source", поскольку Вам важна открытость исходников. Она может быть обусловлена техническими требованиями: библиотечный код выгоднее собирать и линковать статически с точки зрения производительности (inline функции встроятся и оптимизируются).
Тот оратор пишет в том же самом месте "СПО". Поскольку ему важна идеология, а не сами эти исходники. 6 (шесть) вхождений в тексте насчитал, повторяется как мантра -- остальное можно и не читать.
Он даже не знает, что в России "СПО" означает "среднее профессиональное образование".
У меня давно настройки ядра:
# CONFIG_X86_X32 is not set
запрещают запуск 32 разрядных прог32 разрядные библиотеки не собираю, профиль:
no-multilib> Удаление некоторых неиспользуемых битов режимов операционной системы.
NX бит хоть не удаляли? https://www.opennet.me/openforum/vsluhforumID3/129886.html#134
> Intel развивает упрощённую архитектуру x86Sдля упрощённого написания вирей.
> У меня давно настройки ядра:
> # CONFIG_X86_X32 is not set
> запрещают запуск 32 разрядных прогВы ошибайтесь и вводите в заблуждение других.
Читайте описание, x32 - имеет доступ ко всем 64-х разрядным регистрам:Include code to run binaries for the x32 native 32-bit ABI for 64-bit processors. An x32 process gets access to the full 64-bit register file and wide data path while leaving pointers at 32 bits for smaller memory footprint.
https://cateee.net/lkddb/web-lkddb/X86_X32.html
> 32 разрядные библиотеки не собираю, профиль:
> no-multilibЕсли речь о Gentoo, то там раздельные профили.
Первый не поддерживает 32-х разрядный код, в второй попробуйте собрать, если много лишнего времени. :)default/linux/amd64/17.1/no-multilib (stable)
default/linux/amd64/17.0/x32 (dev)
Подробнее о x32 есть даже здесь
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...config IA32_EMULATION
bool "IA32 Emulation"
depends on X86_64
select ARCH_WANT_OLD_COMPAT_IPC
select BINFMT_ELF
select COMPAT_BINFMT_ELF
select COMPAT_OLD_SIGACTION
help
Include code to run legacy 32-bit programs under a
64-bit kernel. You should likely turn this on, unless you're
100% sure that you don't have any 32-bit programs left.
config X86_X32
bool "x32 ABI for 64-bit mode"
depends on X86_64
help
Include code to run binaries for the x32 native 32-bit ABI
for 64-bit processors. An x32 process gets access to the
full 64-bit register file and wide data path while leaving
pointers at 32 bits for smaller memory footprint.You will need a recent binutils (2.22 or later) with
elf32_x86_64 support enabled to compile a kernel with this
option set.У меня в ядре они отключены. Все 32 разрядные проги падают, проверял лично.
Тебе же говорят, x32 вполне себе 64 разрядные, раз уж читать не умеешь.
> https://www.opennet.me/opennews/art.shtml?num=34065
> X32 представляет собой гибридный x86_64 ABI, позволяющий использовать на 64-разрядных системах 32-разрядную модель адресации памяти. ABI X32 позволяет приложениям использовать все преимущества архитектуры x86_64, такие как дополнительные регистры и более быстрые инструкции, PIC ABI. В то же время ABI X32 даёт возможность работать с 32-разрядными указателями памяти, что позволяет экономить память, способствует более эффективному наполнению процессорного кэша и положительно сказывается на общей скорости исполнения кода. При тестировании в ситуациях, связанных с интенсивной работой с указателями, новый ABI продемонстрировал ускорение исполнения кода вплоть до 30% в сравнении с классическим x86_64 ABI. Ограничением ABI X32 является невозможность адресации из приложения более 4 Гб памяти.Спасибо. Всегда отключал этот режим в ядре.
Вероятность, что случайный пользователь столкнётся с такими бинарями, абсолютно нулевая. За 10 лет ничего не поменялось, вещь довольно специфическая. Но внезапно можно выжать из неё немного профитов. Например, можно взять и ускорить какой-нибудь кодек, которому 32 битные ограничения не помеха в работе.
> Но внезапно можно выжать из неё немного профитов. Например, можно взять и ускорить какой-нибудь кодек, которому 32 битные ограничения не помеха в работе.В этих кодеках итак дыра на дыре и дырой погоняет. А x86_x32 уменьшает энтропию ASLR.
https://lwn.net/Articles/774891/
https://lwn.net/Articles/500502/Из-за уменьшения защиты ASLR в дистре Gentoo этот формат (x86_x32) не приобрёл популярности.
Советую всем поддержку 32битных бинарей отключать в ядре Linux.
Лучше бы SMM выпилили.
Вообще да, давно пора там многое выкинуть. В идеале можно было бы при проектировании x64 добавить некоторые команды и режимы работы. Или вообще сделать новый режим "по мотивам", чтобы и компиляторы не слишком перекраивать. Сходу приходит в голову:
* Инструкции MIN и MAX (минимальное и максимальное значение из двух операндов). Это достаточно часто нужно, и хотя их легко выполнить на сравнении, условном переходе и mov, но встроенные инструкции были бы интереснее.
* Инструкция RBIT для разворота бит в байте. Не слишком часто востребованная, но для функциональной полноты - почему бы и нет? Повесить ее например в группу F6-F7, там есть одна свободная команда.
* Вместо всевозможных расширений для SIMD (коих уже наверное десятки) сделать наверное нормальную систему префиксов, которая все эти инструкции переносит на обычные регистры (которых пусть будет больше).
MIN и MAX делаются с помощью "conditional move".
Наборы "полезных инструкций" это дело второстепенное, из прошлого века.
А актуальная потребность в быстром конвейере инструкций без блокировок, с максимумом операций за такт, возможностью дальнейшего подъёма частот, и эффективная многопоточность.
> * Инструкции MIN и MAX (минимальное и максимальное значение из двух операндов).
> Это достаточно часто нужно, и хотя их легко выполнить на сравнении,
> условном переходе и mov, но встроенные инструкции были бы интереснее.Есть группа инструкций CMOVcc - загрузка в регистр по условию.
Вот оптимизация bsearch в тему https://vk.com/wall639737021_774
По incel-ы не научатся делать 16-ти ядерные процессоры с верхним потреблением в 95 ватт всё это ниочёмные утюги.И кстати, что там с AVX512?
А вы вообще в курсе, что у интела два защищенных режима? :)Режим виртуального 8086 (V86, VM86, иногда просто виртуальный режим) — режим адресации процессоров семейства x86 совместимый с прародителем семейства — процессором Intel 8086. Является подрежимом защищенного.
V86 и x86-64
Процессоры с архитектурой x86-64 поддерживают V86 только в наследственном, но не в длинном режиме. В длинном режиме флажок EFLAGS.VM попросту игнорируется. Поэтому, для поддержки виртуальных DOS-задач требуется переключение в наследственный режим, сопряженное с двойным сбросом MMU. А поскольку роль DOS и её приложений в наши дни практически сошла на нет, операционные системы x86-64 не включают такого рода поддержку V86. Тем не менее, некоторые современные средства аппаратной виртуализации позволяют виртуализовать как реальный режим, так и V86, получая в результате двойную виртуализацию.Прародитель 8086, так романтично, 1978 год, дедуля :).
Помните, ЛЮБОЙ самый современный интел проц умеет режим дедули. Да, до сих пор. Не, нуачо, пипл хавает и платит.
> А вы вообще в курсе, что у интела два защищенных режима? :)имхо, Вы привели не совсем корректную цитату. Вообще, конечно, защищенных режимов как минимум два:
1) защищенный режим процессора 80286, благодаря которому получились такие страшненькие дескрипторы в защищенном режиме процессора 80386. Этот режим позволяет, если не путаю, 24-х битную физическую адресацию (16M), при сохранении 16-ти битной логической. Всё 16-ти битное, сегменты, смещения и никаких страниц.
2) защищенный режим процессора 80386 - тут уже и логические и физические адреса 32 бита(4G). Всё 32-х битное, в том числе и сегменты. Появилась страничная адресация.вот уже в последнем был подрежим виртуального 8086. По простому - чтобы проще было крутить MS-DOS в Windows 3.11 и выше.
Аналогично и сейчас в этой "новой" архитектуре x86S, при том, что всё 64-х битное, будет, как я понял, поддерживаться подрежим 32-х битный.
Кстати, у меня опыт использования всей этой лабуды, начиная с DOS3.*, DR Multiuser DOS, DesqView, PC-MOS, файл серверов NetWare 286 итд.
А винду помню еще как графическая оболочка версии 1.0.
Наиболее комфортно было работать с Windows NT 3.1 на платформе DEC Alpha, ностальгия, прям :)P.S. По итогу DEC, Sun и прочих задавили демпингом, маркетингом и прочими "законными по букве закона и не очень" средствами, разработки перекупили, всё вкусное что можно было реализовать у себя, реализовали как обычно, остальное похерили. А сейчас штеуд засуетился, но время уже упущено.
> 1) защищенный режим процессора 80286, благодаря которому получились такие страшненькие
> дескрипторы в защищенном режиме процессора 80386. Этот режим позволяет, если не
> путаю, 24-х битную физическую адресацию (16M), при сохранении 16-ти битной логической.
> Всё 16-ти битное, сегменты, смещения и никаких страниц.
> 2) защищенный режим процессора 80386 - тут уже и логические и физические
> адреса 32 бита(4G). Всё 32-х битное, в том числе и сегменты.
> Появилась страничная адресация.И никого не смущает, что "ЭТО" до сих пор работает в КАЖДОМ процессоре Intel? Даже в самом последнем поколении. Это как седло со шпорами и уздечкой в багажнике, ненужно, но пусть будет :)
> вот уже в последнем был подрежим виртуального 8086. По простому - чтобы
> проще было крутить MS-DOS в Windows 3.11 и выше.
> Аналогично и сейчас в этой "новой" архитектуре x86S, при том, что всё
> 64-х битное, будет, как я понял, поддерживаться подрежим 32-х битный.Вопрос к интелу, но скорее всего всё будет совсем по другому. И от интела это уже не зависит.
Моё сообщение удалили, ну и фик с ним.У нитела будущее уже настало. В смысле всё.
Генианальное решение, не?
Кстати, всем, кто надеется на RISC-V - не взлетит. Может, подпрыгивать сможет, но недолго.
