3-62> Я, как-то, не вижу разницы между CPUID или CALL id_pci. Во втором случае - надо разок написать подпрограмму. И можно пользоваться.
Да, с CPUID разницы, действительно, нет никакой.

А вот с fmul - была бы, тут же фишка в ускорении вычислений, любые накладные расходы - страшно бьют по выгоде, а если у нас они ещё и в цикле (допустим, код требует постоянного взаимодействия между целочисленной и "расчётной" частью, что не редко) - тогда и вовсе опаньки.
3-62> Ничего сложного в шине нет. А вот плавающая точка "на сопроцессоре" рождает проблему синхронизации. И если ею пренебречь, то "простой путь" заведет в болото багов.
Сложность относительно задачи. Как бы нет ничего сложного в поездке в другой город, но не за продуктами же.
Если у нас есть процессор и некий независимый сопроцессор, то синхронизация неизбежна. Вопрос в её удобстве. Вот, допустим, у меня сопроцессор сидит как внешнее устройство на портах. Я гружу в него задачу и данные (через порты), затем я делаю постоянный поллинг, в ожидании результата (так?) загружая и процессор, и его шину, и ещё и внешнюю шину, на которой висит устройство, а потом вручную вытаскиваю результат через порты. Ну или загружаю задачу и данные, программирую DMA, а затем занимаюсь поллингом.
Ну или цепляю обработчик прерывания (но это на современных процессорах и ОС ну ОЧЕНЬ громоздко и дорого по времени исполнения). Вообще же, каждый пролом прикладного уровня до аппаратуры в современных архитектурах (даже если это просто "безобидная" работа с портами) - это очень дорого (потому что это привелигерованный режим, эксепшн, обработка нулевым кольцом защиты (на х86/х64, или аналоге на других), возврат). То есть, по уму придётся делать драйвер, API для него... Не слишком ли сложно для провинциального советского цирка?
Как в 8086? fmul, ля-ля-ля обычный код, wait. Всё.
Сопроцессор запихает на стек (не то чтоб прям офигенно удобно, но сканает). Никаких опросов, никаких прерываний. Вся требуха общения и синхронизации, запихивания задачи и данных в сопроцессор скрыта от пользователя (и происходит самым натуральным образом: отказ от шины, выборка "своего" кода сопроцессором по префиксу, возврат шины, поправка счётчика команд и стека по надобности).
И это по-своему красиво.
КМК, используя послезнание, я бы даже
усугубил и ввёл в ISA инструкцию типа device (ID, адрес1, смещение1, адрес2, смещение2). По которой происходило бы программирование встроеных регистров (которые бы вызывали внешнее устройство ID, отдавая ему кусок памяти размера в смещение1 по адрес1, и сообщая, что результаты ожидаются в памяти по адресу2, не более чем в смещение2 размером.
По этой команде выбиралось бы устройство ID происходил бы отказ от шины процессороми захват её устройством (или запуск DMA в продвинутом варианте), а по результату работы было бы NMI с опять же захватом шины и помещением в память результатов. Симметрично wait ID вешало бы процессор до получения результатов от устройства ID.
Это же решало бы вопрос со всеми внешними устройствами ввода-вывода, для которых нынепринятый концепт "портов" мне кажется громоздким, дико времязатратным (особенно, на момент выкатывания архитектур) неудобным и, по сути, излишним. Пространство команд потрачено зря, для использования спецкоманды ввода-вывода нужно в большинстве ISA спецом сначала загрузить что-то в регистр, то есть затраты времени... зачем?
Дополнительных затрат железа в устройствах мой вариант не почти требует (только защёлки для адресов), но функционал радикально выше (особенно, на простом железе, сейчас-то - понятно, что почти пофигу, тем более рядовому программисту, который не имеет дела с железом).
Татарин>> НЯЗ, причины запрета на винде - в том как написан 16-разрядный рендер винды,
3-62> НЯЗ - проблема в работе префиксов размера адреса и данных. И тут либо 64/32, либо 32/16. А далее - как написан код. С префиксами или без.
Так а зачем 64 и 16 ОДНОВРЕМЕННО?

Никакие задачи совместимости этого не требуют, издержки были бы велики, ну, конечно, этого не сделали. Но вот перейти в режим эмуляции 8/16-битного кода любой современный проц может без чисто программного эмулятора.
Татарин>> Иллюстрация к тезису "сделай что-то, чем сможет пользоваться дурак, и только дурак будет этим пользоваться". ПЛК - для простых решений.
3-62> Тут ведь всегда найдется "дурак который смог". И не для простых решений ПЛК. Заблуждаетесь.
3-62> Специфика там в акценте "приоритетов значимости". И работа в реальном времени.
Тут вот какая проблема: если реализовывать то, что реализуют ПЛК в "нормальном" коде - это получится относительно простой код.
Беда в том, что ПЛК
заточены на совсем простые вещи (что следует из названия даже): "при превышении такой-то уставки и наличия кода там-то сделать-то-то", а вот "при наличии такого-то и такого-то проверить то-то и то-то и сделать так либо этак". Если это всё выразить в коде, нечастый проект заваливает за несколько десятков килобайт, что, если честно, по меркам "внешнего мира" совсем уж крохотная программка.
Просто способ организации этой логики таков, что заточен в первую очередь на нечто простое, что делается инженером, понимающим производство, а не программирование. При превышении некоторого уровня сложности становится ну очень сложным этим всем управлять и держать в памяти. Сама "простая" организация кода делает очень сложными проекты на нём и управление ими.
То есть, КМК, в некий момент хорошо бы уже просто иметь нормальный код для ОС РВ. Но много КИПовцев/"автоматчиков" считают этот инструмент очень тяжёлым (или даже вообще не умеют с ним работать), а "обычные программисты" понятия не имеют о реальном производстве... и зная, сколько косяков допускается на этапе формирования ТЗ и уяснения его программистом, оно и к лучшему, что "автоматчики" как-то справляются сами.

Но было бы неплохо, если бы "автоматчикам" дать нормальные инструменты, где можно нормально
на нормальном языке с использованием всего его инструментария писать код реакций с самого начала. Нечто среднее между программированием ПЛК и писанием проги под ОС РВ с нуля.
3-62> Тут проблема в том, что погнались за модой. Высокого уровня. И выдрали ассемлер. Который наиболее удобен даже для сложных проектов. Но требует понимания и "недурака".
3-62> Плюс нарушили заповедь "не вводи блокировок больше чем действительно требуется".
И да - как бы нужно согласиться, всё верно... и всё же душу корябает. Нужно сказать, что на ассемблере косячить гораздо проще, а чем сложнее проект - тем больше вероятность, что человек, увлёкшись, хаками упустит ключевое.
Реальное железо, и тем более, производство очень сложно и очень дорого дебажить :), так что уж лучше лишние проверки типизаций, чем взрыв бака-накопителя с фосгеном.