Внутренняя история крупнейшей ошибки Texas Instruments, микропроцессора TMS9900

http://spectrum.ieee.org/geek-life/history/the-inside-story-of-texas-instruments-biggest-blunder-the-tms9900-microprocessor
  • Перевод
image

Если вы используете настольный компьютер или ноутбук, вероятно, в нём стоит микропроцессор линейки Intel 808x, неважно, работает ли машина под управлением Windows или Mac. Абсолютное доминирование этих микропроцессоров восходит к 1978 году, когда IBM выбрала 8088 для своего первого персонального компьютера. Но этот выбор был совсем не очевидным. Некоторые считают, что Intel 8088 был худшим выбором из имевшихся в то время 16-битных микропроцессоров.

Нет, это не был худший выбор. Ему была серьёзная, но худшая, альтернатива. Я знаю это потому, что я руководил организацией, работавшей в составе TI, разработавшей его: TMS9900. Хотя это барахло и использовали в первом в мире 16-битном домашнем компьютере, вы наверняка о нём не слышали. Как говорится, историю пишут победители.

Эта глава истории интересна не только чипом от TI, но и другим его конкурентом, Motorola 68000, с технологической точки зрения превосходившим как Intel 8088, так и TMS9900. И всё же 68000 не попал в IBM PC. И вот вам малоизвестная история от хорошо осведомлённых источников о том, как IBM выбрала недоразвитый чип, TI породил неудачника, а явный лидер от Motorola проиграл.

image
В 1978 году автор провёл презентацию чипа TMS9900, который рассматривали в качестве кандидата для персонального компьютера от IBM. TI контракт не получила.

Я устроился на работу в TI в 1972-м, сразу после аспирантуры, и через два года я уже делал презентацию для Джека Карстена, менеджера отдела MOS в Хьюстоне, где базировалась работа компании над металл-оксид-полупроводниковыми (MOS) чипами. Я, молодой инженер, несколько робел перед Джеком, всю презентацию просидевшим с ногами, закинутыми на стол в конференц-зале, курившим сигару и бормотавшим «херня» каждый раз, когда он не соглашался с чем-то, что я говорю.

В то время большая тройка полупроводниковых компаний — Fairchild, Motorola, and TI – пытались перейти от биполярных микросхем к MOS. Чипы MOS требовали совершенно другой схемы и процесса изготовления, и такие стартапы, как Intel, развивались гораздо быстрее уже существовавших компаний. Из всей большой тройки TI лучше всего удался переход, во многом благодаря таким людям, как Л. Дж. Севин, ушедший из TI в 1969 году, чтобы основать Mostek и впоследствии заниматься венчурными инвестициями. Карстен, до этого работавший в TI главным менеджером по прибыльной линейке продуктов транзисторно-транзисторной логики (TTL), также был ключевой личностью при переходе на MOS.

Отдел MOS в TI добился самого значительного успеха в разработке логических чипов для быстрорастущего рынка переносных калькуляторов. Хотя компания состязалась, и в итоге победила Intel, в разработке первого процессора общего назначения, инженеры TI не особенно интересовались микропроцессорами (МП) от Intel, 4-битным 4004 и 8-битным 8008. TI заметила 8-битные микропроцессоры 8080 и последовавший за ним 8080А, ведь они были более многообещающими, чем 4004. Отделу MOS поручили догнать Intel как по МП, так и по DRAM (динамическая память с произвольным доступом, способная впихнуть больше ячеек памяти на чип, чем RAM, но требующая постоянного обновления для предотвращения потери данных).

Так в TI и появилась стратегия создания МП общего назначения. Ключевыми предположениями стратегии были следующие: прикладное ПО будет главным стимулом для эволюции этих чипов, а как обладатель успешной линейки MOS IC, TI будет находиться в отличной позиции для разработки индустриального стандарта для микрокомпьютеров, систем безопасности и потребительских продуктов. Все перечисленные отрасли были быстро растущими источниками прибыли для компании. Но для этого TI необходимо было перепрыгнуть текущую передовую 8-битную разработку, примером которой был Intel 8080, и стать первой компанией, выведшей на рынок 16-битную архитектуру. Эта стратегия породила план создания TMS9900.


Победитель: микропроцессоры Intel 8088 были далеки от идеала, но IBM выбрала их для своего персонального компьютера, запущенного в 1981 году.

TI уже продемонстрировала свои компьютерные умения в гонке суперкомпьютеров в конце 1960-х. Двигали эту гонку нефтяные компании, пытавшиеся достичь конкурентного преимущества в трёхмерном сейсмическом анализе при разведывании нефтяных месторождений. На этом бизнесе и была основана TI. IBM, Control Data Corporation и другие компании соревновались в этой гонке, но TI первой вывела на рынок свой Advanced Scientific Computer.

Так что для TI выбор архитектуры для 16-битного чипа был простым. У TI была стратегия «одна компания, одна компьютерная архитектура», направленная на использование синергетических эффектов, существующих между разными, несоизмеримыми отделами компании. Отделение по работе с информационными системами уже запустило семейство микрокомпьютеров на базе TTL для использования в гостиничной сети Ramada Inn по всей территории США. Так что TMS9900 должен был использовать архитектуру, очень похожую на архитектуру микрокомпьютера от TI.

Команда Карстена знала, что разработка TMS9900 – как и биполярной его версии для военных под названием SBP9900 – потребует времени, и чипы, скорее всего, не будут готовы раньше 1975-1976 годов. В это время отделению MOS необходимо было действовать. Они планировали начать с копирования Intel 8080A, чтобы вывести хоть что-то на рынок, затем разработать оригинальную 8-битный микропроцессорную архитектуру (которая будет называться TMS5500), и, наконец, перейти к 16-битным TMS9900. National Semiconductor к тому времени уже выпустила 16-битный набор логических чипов общего назначения под названием IMP-16, но из-за того, что это был именно набор из нескольких чипов, популярности он не снискал.

У TMS9900 был свой багаж трудностей в разработке и задержек, но в итоге он был готов к 1976 году. И всё равно он столкнулся с несколькими крупными проблемами. Во-первых, не было совместимых с ним 16-битных периферийных чипов. А без периферийных чипов, работающих над передачей и хранением данных, МП будет бесполезен для разработки систем. Второй проблемой было то, что у архитектуры 9900, схожей с тем, что TI использовала в микрокомпьютерах, было всего 16 битов логического адресного пространства – как и у 8-битных процессоров того времени. Эту проблему нельзя было решить, не разработав новую архитектуру с нуля. Последней проблемой было то, что хотя TI могла использовать технологию одного МП для своего миникомпьютера, оборонки и полупроводникового бизнеса, её конкуренты в этих отраслях окажутся в невыгодном положении, если станут брать для своих продуктов архитектуру от TI.


Проигравший: среди крупных проблем, досаждавших TMS9900, было отсутствие 16-битных периферийных чипов, из-за чего МП был бесполезен в разработке систем

Чтобы бороться с отсутствием 16-битной периферии, инженеры TI придумали следующую инновацию. Почему бы не приспособить на TMS9900 8-битный порт, так, чтобы с ним могло работать большое количество уже существующих периферийных чипов, разработанных для 8-битных МП? Уверен, что в то время это казалось разумным. В результате в 1977 появился TMS9980. Присоединение 8-битной периферии к 16-битному МП устранило единственное реальное преимущество 16-битной архитектуры: быстродействие. 9980-му требовалось два командных цикла для выполнения команды от 8-битной периферии, в результате чего эффективное быстродействие падало в два раза, что было не лучше, чем у уже существующих 8-битных МП. До реализации великого плана TI Карстен ушёл из компании на должность вице-президента по продажам и маркетингу в Intel, чувствуя, вне всякого сомнения, что Intel станет очень серьёзным соперником, которого на рынке МП будет крайне сложно победить.

Intel, естественно, разрабатывал свой собственный 16-битный микропроцессор, 8086, увидевший свет в апреле 1978. Компания подошла к вопросу отсутствия совместимой 16-битной периферии точно тем же способом, добавив 8-битный порт к МП, что породило Intel 8088. Как и TI 9980, Intel 8088 был барахлом, и показывал уменьшенное быстродействие по сравнению с 8086 в любой реальной системе. Но у чипа от Intel было одно фундаментальное преимущество перед TI: 20 бит логического адресного пространства вместо 16. А в результате у него была возможность обращаться к мегабайту памяти, а не к 64К, как у TI 9900. Кроме того, внешние регистры TMS9900 и 9980 ещё больше ухудшали его быстродействие.

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

А в это время несколько конкурентов объявили о своих планах на создание 16-битных процессоров общего назначения. Самым амбициозным планом был Motorola 68000. Хотя у него было 16 внешних контактов, внутренняя его архитектура была 32-битной, и у него было 24 бита для логического адресного пространства. Следующий продукт, возможно, смог бы использовать 32 адресных бита. Zilog, создатель популярного 8-битного МП Z80, объявила о разработке 16-битного Z8000, с сегментированной памятью, выход которого планировался на 1978-1979 года. В отличие от 68000, у Z8000 была простая 16-битная архитектура.


Ещё один конкурент: У 16-битного МП 68000 от Motorola была 32-битная внутренняя архитектура, но он не успел выйти вовремя, чтобы стать одним из возможных вариантов для IBM PC.

В октябре 1978 года, через шесть месяцев после анонса Intel 8086, я перешёл в отделение MOS в TI и стал менеджером по МП. К тому времени все в компании, и многие вне её, знали, что 16-битная стратегия TI для МП не работала. Неудачная попытка подразделения разработать совместимый 16-битный микроконтроллер TMS9940, который к моему появлению прошёл уже 5 или 6 итераций, только усиливала эту проблему. Я знал, что наследую тяжёлую ситуацию. Так зачем же я бросил хорошую работу в качестве менеджера департамента разработки потребительских продуктов? Местоположение, местоположение, местоположение. Микропроцессорное предприятие находилось в Хьюстоне, а потребительские продукты TI перенесла в Лаббок, Техас. Лаббок – это город, в котором правильным ответом на вопрос «Как вам здесь нравится?» будет «Люди тут замечательные». Кантри-певец Мэк Дэйвис, выросший здесь, однажды написал песню с припевом «Я думал, что счастье – это Лаббок, Техас в зеркале заднего вида».

Вскоре после того, как я прибыл в Хьюстон, мне сказали, что я должен буду провести презентацию по TMS9900 для группы из IBM, работавшей над очень секретным проектом, требовавшим 16-битного микропроцессора. Группа приехала из необычного для IBM места: Бока-Ратон, Флорида. Я очень долго готовился к этому, выдал, как я считал, хорошо подготовленную презентацию, и прилежно работал с последствиями. Но команда из IBM не выказала особенного энтузиазма. До 1981 года мы не знали, в чём проиграли.

Джон Опель, президент, а потом генеральный директор IBM, совершил революционный ход, основав отделение в Бока-Ратон, позже ставшее известным как Entry Systems Division. Он понял, что персональные компьютеры от Apple, Commodore, Radio Shack, TI и других могут стать угрозой доминированию IBM в компьютерном бизнеса. Так что он дал группе из Бока-Ратон, руководимой Филиппом Эстриджем, карт-бланш на разработку их продукта – персонального компьютера от IBM. Они могли использовать помощь третьих лиц для чего угодно, включая разработку ОС и прикладных программ. Такое отношение сделало систему довольно «открытой» по стандартам IBM, и ускорило выход продукта на рынок. Однако у Опеля было одно ограничение: продукт будет носить имя IBM, поэтому он не может подрывать репутацию компании по качеству и надёжности. Поэтому массивная организация по контролю качества внутри IBM должна была подписать выход этого продукта до начала его продаж.


Мгновенный успех: IBM 5150 PC вышел в августе 1981. В США в стоимость $1565 не входили монитор, принтер и два дисковода.

О выборе командой IBM 16-битного МП спорить не приходилось. Motorola 68K, как его назвали позже, был, без сомнения, явным фаворитом. У него было самое большое логическое адресное пространство, что было ещё важнее, чем минимально 16-битная внутренняя архитектура. Его легко было расширить до полностью 32-битной архитектуры. И, что самое важное, 68К работал с порядком байтов «Big Endian», то есть от старшего к младшему. Речь идёт о порядке, в котором компьютеры хранят байты в памяти. 16-битная архитектура произошла от 8-битной, и инженерам пришлось решать, какой из 8-битных байт будет первым в 16-битном мире. Digital Equipment Corp. выбрала порядок от младшего к старшему («Little Endian») для своего Programmed Data Processor (PDP) и архитектур VAX. Intel сделал то же самое. Но компьютеры IBM использовали другой порядок, «Big Endian». Чтобы «Big Endian» общался с «Little Endian», порядок байт приходилось менять на обратный на лету. В то время такое конвертирование данных было нетривиальным. 68K от Motorola не требовал конвертации для использования с IBM PC. Так почему же мы сегодня не используем компьютеры на базе 68К?

Ответ связан с тем, кто первый вышел на рынок. 8088 был неидеальным, но, по крайней мере, он был готов, а 68К не был. Скрупулёзный процесс оценки качества IBM требовал, чтобы производитель предоставил тысячи образцов выпущенного продукта для каждой новой запчасти, чтобы IBM могла проводить на них живые тесты. В IBM контролем качества занимались сотни инженеров, но это отнимает время. В первой половине 1978 года у Intel уже были изготовлены примеры 8088. К концу 1978 68К ещё не был полностью готов к выходу.

К несчастью для Motorola, группа из Бока-Ратон хотела выводить на рынок новый IBM PC как можно скорее. Так что у них было только два полностью готовых 16-битных МП на выбор. В соревновании двух неидеальных чипов чип от Intel оказался менее неидеальным, чем чип от TI.

TMS9900 не остался тихо умирать, не получив признания от IBM PC. Управляющие всё ещё надеялись продавить корпоративную стратегию. Конечно же домашний компьютер от TI, анонс которого ещё только ожидается, должен будет использовать TMS9900?

Команда разработки компьютера нехотя согласилась дать ему шанс. Эта группа явилась результатом несчастливого слияния двух департаментов, один из которых разрабатывал игровую консоль, а другой – персональный компьютер. Получившийся у них гибрид не был приспособлен ни для того, ни для другого. Но TI упрямо гнули свою линию. TI-99/4 вышел на рынок в 1979-м, за ним последовал TI-99/4A в 1981. Компания в итоге продала 2,8 млн штук, большую часть из них – в убыток, пока не ушла с рынка персоналок в 1984.

Тем временем архитектура Intel 8086 эволюционировала и преодолела недостатки. Она всё ещё использует порядок байтов Little Endian, но сегодня это не имеет никакого значения. А Motorola со своей превосходящей технологией проиграла единственное важнейшее соревнование по разработке за последние 50 лет.

Раз уж мы говорим об остальных конкурентах, скажу пару слов об ОС для IBM PC. Логичным выбором для 16-битной ОС было расширение популярной ОС CP/M, разработанной Гэри Килдаллом в Digital Research на основе Zilog Z80. Группа из Бока-Ратон понимала, что за CP/M стоит открытый стандарт, поэтому они заказали Digital Research разработку версии под названием CP/M-86. В процессе Microsoft возникла с предложением MS-DOS, о которой уже много всего написано. Поэтому мир ПК развивался не в том направлении, о каком можно было сначала предположить, как в плане ОС, так и в плане микропроцессора.

Какие же уроки мы можем извлечь из истории? Один – если вы разрабатываете продукт на основе быстро меняющейся новой технологии, то главное — выйти первым на рынок, и неважно, какие ограничения будут у вашего начального продукта. Сегодня в Кремниевой долине такой подход называется созданием «минимально жизнеспособного продукта». Если у вашего продукта есть новые возможности, отличающие его от других, ваши клиенты придумают инновационные способы его использования.

Второй урок – если вы управляете крупной корпорацией, желающей создать проект в небольшом, изолированном от других отделе, не отягощённый багажом или традициями, думайте о накладываемых на него ограничениях. Вероятно, что ограничение ОС для IBM PC принесло бы компании больше пользы в долгосрочном периоде, чем обременение продукта сложными процедурами контроля качества. Никто не мог предсказать, как сильно персоналки повлияют на нашу жизнь, но реальная ценность содержится не в оборудовании, а в совместимости ОС. Если бы IBM, а не Microsoft, контролировала бы MS-DOS, Windows и прочих, мир компьютеров был бы совершенно другим.

Наконец, для людей, стоящих на обочине и просто наблюдающих за парадом высоких технологий, скажу: не упускайте ваши возможности. В случае с TI мы в 1979 году решили, что TMS9900 проиграл гонку МП общего назначения, и начали заглядывать вперёд, в будущее, которое наступит после МП общего назначения. Наша стратегия фокусировалась на МП узкой специализации и привела к разработке TMS320, цифрового процессора сигналов. Его анонс прозвучал на международной конференции по твердотельным схемам в феврале 1982 года, а вышел он в следующем году. Семейство 320 DSP и его производные начали приносить почти половину всей прибыли TI, подготовили новое поколение управленцев компании, и позволили TI участвовать в гонке встроенных процессорных систем на чипе. В 1990-х эта стратегия обратила вспять тенденцию к упадку среди лучших полупроводниковых компаний и принесла миллиарды долларов с продаж чипов для модемов, контроллеров дисководов и множества других продуктов.
Метки:
Поделиться публикацией
Похожие публикации
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 92
  • 0

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

    • 0

      Выпуск процессора 8080 как бы намекает, что внутренне 16-битный процессор вполне имеет смысл делать с 8-битной шиной. Позже этот же трюк повторил 386SX.


      Выбор процессора 8086 не был бы такой уж сильной ошибкой, если бы Intel и IBM не пошли по пути совместимости при выпуске процессора 80286, усугубляя все сделанные ранее ошибки. Вот тогда и надо было перейти на Motorola 68x или вообще разрабатывать RISC-процессор типа ARM.


      Да собственно, когда в IBM PC стали ставить 256 килобайт памяти — уже было понятно, что 16-битная архитектура (я о разрядности регистров) тормозит сильнее всего — ибо для адресации больших массивов требовались лишние вычисления.

      • +1
        Вот тогда и надо было перейти на Motorola 68x или вообще разрабатывать RISC-процессор типа ARM.

        И как вы себе это представляете? Выкинуть нафиг всё уже наработанное ПО? Или лепить эмуляцию? Даже на 64-битнои Интеле выполнять 32-битные программы не так просто, а тут совершенно другая архитектура.
        • 0

          Мне очень странно, что Вы этого себе не представляете. В компьютер ставятся два процессора: главный 32-битный и совместимый *86-й.


          Реально OS (в т.ч. драйверы оборудования) выполняется на главном процессоре. Желательно сделать там нормальную OS с вытесняющей многозадачностью — благо Unix был разработан для PDP-11, а значит, мог жить в очень малой памяти.


          На *86-м процессоре запускается "заглушка" (можно — загружать; а можно запускать прямо из ПЗУ), которая перенаправляет вызовы (INT-прерывания) DOS и BIOS на главный процессор. А тот уже выполняет нужные функции.


          Остаётся проблема с прямым обращением к аппаратуре. Реально надо эмулировать только видеопамять — ну так поддержку этого можно встроить в чипсет, контролирующий обращение *86-го процессора к оперативной памяти.
          Ну, ещё хорошо бы эмулировать COM/LPT-порты. Это тоже реально сделать; я даже могу расписать, как именно, но лень, ибо неактуально.


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


          Но как обычно — разработчики идут по пути с максимальным количеством грабель. Ведь если они выберут другой путь, то работодатель не станет платить им за преодоление предусмотрительно созданных заранее трудностей.


          PS: Программную эмуляцию процессора сделать не слишком сложно — при условии, что эмулирующий процессор имеет намного больше регистров, чем эмулируемый.

          • 0
            Интересно, как процессоры будут общаться друг с другом? Необходимость синхронизации между процессорами убъёт всю идею. Да и контролировать обращение процессора к памяти, да ещё аппаратно тянет на ещё один чипсет… плодить сущности на ровном месте?
            • –2

              Процессоры будут общаться через общую память. В системе предполагается от одного до трёх пулов/банков памяти. При трёх пулах — пропадает возможность динамического распределения памяти (т.е. память распределяется на этапе проектирования/сборки компьютера); зато в этой схеме доступ к памяти будет быстрее. При едином пуле — в нём логически создаются три пула, размер которых можно менять.


              Первый и второй пулы — это собственная память главного процессора и *86-го процессора соответственно. Каждый процессор не имеет никакого доступа к памяти второго процессора.
              Третий пул — это буферная память, куда имеют доступ оба процессора. Эту память они оба не кэшируют, зато эта память имеет свой собственный кэш — типа внешнего кэша процессора.
              Ну или процессоры могут кэшировать память третьего пула — в то время, когда кладут или забирают данные. После работы надо "убрать за собой" — приказать своему кэшу перестать кэшировать эту память. Никакой аппаратной синхронизации кэшей не нужно.


              О какой "синхронизации между процессорами" Вы говорите? Почему Вы не протестуете против синхронизации между CPU и GPU? Или там это не убивает идею?


              На данный момент контроллер памяти (адресного пространства) уже давно (с 386-го процессора; а недоделки были и а 286-м) встроен в процессор (сравнительно недавно в процессор перенесли и контроллер модулей памяти, распределяющий запросы процессора к физической памяти между банками памяти).
              Если Вас задел контроль над обращением к видеопамяти — то Вы сильно опоздали: этот контроль был в чипсете 8086-го процессора изначально, а начиная с EGA появился второй чипсет — на видеокарте.


              Что же касается сущностей, то Вы, видимо, не интересовались подробностями архитектуры *86-х процессоров. Вот Вам кратенький список сущностей, построенных одна над другой:


              • Сегментная адресация памяти на 8086 и 186 из-за того, что в системе предполагалось больше памяти, чем можно было адресовать одним регистром.
              • Сегментная защита памяти в 286-м — жуткое уродство. И это вместо того, чтобы переходить на 32-битную архитектуру (закон Мура уже известен).
              • Страничная защита памяти в 386-м — ну, нормально; но при этом — добавление ещё двух сегментных регистров.
              • Четыре кольца защиты. При этом никто не способен объяснить мне, чего нельзя сделать в двух кольцах — ядро и приложения. Да и вообще, можно без колец защиты: ядерные команды реализовать через порты ввода/вывода, доступ к портам ввода/вывода сделать через обращение к памяти, память защитить страничной защитой; в адресном пространстве ядра есть страницы с портами, а приложениям их не дают.
              • Четырёх колец мало — добавляют "минус первое кольцо защиты".
              • Этого тоже мало — добавляют ещё одно кольцо защиты, "минус первое" переименовывают в "минус второе", а новое становится "минус первым".
              • Если я правильно понял — сейчас навешивают ещё одно кольцо защиты.
              • Это я ещё не стал писать про расширения набора команд процессора: MMX, SSE, SSE2 и ещё более дюжины.

              У меня уже нет сил изучать весь этот зоопарк с вивисекцией. Сообщите кто-нибудь в антинаркотический контроль, пусть они проверят Intel на сверхтяжёлые наркотики.


              А Вы тут решили запретить мне ковыряться в носу! (Если кто-то не понял — это намёк на анекдот: "Ребёнок увидел, как родители занимаются любовью, и сказал/подумал: "Эти люди запрещают мне ковыряться в носу."")
              Сущности, видите ли, плодить не надо! Расскажите это в Санта-Кларе! И в Редмонде заодно — они тоже к этому руку приложили.

              • +1
                Почему Вы не протестуете против синхронизации между CPU и GPU? Или там это не убивает идею?

                GPU это довольно специализированный векторный вычислитель там такое поведение оправдано и накладными расходами на передачу данных можно пренебречь. Кроме того, GPU настолько специфичен что результаты вычислений не возвращаются в CPU а идут сразу в видеопамять. А у вас получается два процессора трудятся над одной по сути задаче, дял каждого из них нужна собственная прошивка-программа написанная на двух разных(или одном?) языках и скомпилированная на двух разных компиляторах… для одной-то вычислительной системы? Система просто обречена на забвение… ибо кто будет заморачиваться двумя компиляторами для поддержки одной аппаратной платформы когда есть решения проще и масштабируемей?

                доступ к портам ввода/вывода сделать через обращение к памяти
                Тогда это будут уже не порты ввода-вывода а просто отображение адресного пространства. Такое тоже часто практикуется, но… проблема в том что порты ввода-вывода по своей сути весьма медленные по меркам процессора и даже памяти. Их никак не получится отразить на адресное пространство памяти не замедлив работу с памятью.
                • 0
                  GPU настолько специфичен что результаты вычислений не возвращаются в CPU а идут сразу в видеопамять
                  Майнеры криптовалют от изумления теряют дар речи. Некоторые научные работники, занимающиеся вычислениями, тоже очень удивляются.

                  А у вас получается два процессора трудятся над одной по сути задаче
                  Насколько я знаю, в любой операционке — над ядром трудятся одни программисты, а над user-space программами совсем другие. В данном случае ядро и user-space программы выполняются на разных процессорах, что по большому счёту ничего не меняет.

                  дял каждого из них нужна собственная прошивка-программа написанная на двух разных(или одном?) языках и скомпилированная на двух разных компиляторах…
                  Про языки — будем считать, что я ничего не слышал. Потому что это настолько ничтожное возражение, что отвечать на него просто смешно — на фоне разнообразия используемых языков.

                  Компиляторы — очевидно разные. Ну и что?
                  Для *86- процессоров есть компиляторы для разных режимов работы: 16-битного, 32-битного и 64-битного; а для 16-битного режима были варианты с разными моделями памяти: Tiny, Small, Medium, Compact, Large и Huge. И после этого Вы запрещаете мне ковыряться в носу!

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

                  Мы точно на одной планете живём?

                  Тогда это будут уже не порты ввода-вывода а просто отображение адресного пространства.
                  Это будут именно порты ввода-вывода. Изучите систему команд процессоров 6502 или ARM — там нет команд для работы с портами ввода-вывода, всё делается через отображение этих портов в адресное пространство процессора.

                  проблема в том что порты ввода-вывода по своей сути весьма медленные по меркам процессора и даже памяти
                  Это не порты медленные, это тормозят устройства, с которыми процессор работает через порты.

                  А часто ли надо делать системные команды? Они и на *86 небыстрые — ибо ломают конвейер.

                  Их никак не получится отразить на адресное пространство памяти не замедлив работу с памятью.
                  А ничего, что в *86 обращение к портам ввода-вывода делается (ну или делалось до того, как контроллер памяти перенесли с сев.моста в процессор) через ту же шину, что и к памяти? Разница — только в том, что в адресной шине есть ещё одна линия, отвечающая за выбор между портами и памятью.
                  • +1
                    А глупые почему-то используют ASIC и специализированные математические модули… ведь есть GPU.

                    Я хочу сказать что для системы придётся использовать ОДНОВРЕМЕННО два разных компилятора а не каких-то произвольных т.к. нам одновременно надо будет менять и то и другое. Причем из-за кардинального различия в процессорах это будут совершенно разные компиляторы, если их сводить к одному знаменателю это чревато тем что ни один из них не будет работать оптимально.

                    В привычном нам компьютере есть масса процессоров — на сетевой карте, на HDD, а на видеокарте их вообще много.

                    Хотите ещё сильнее усложнить жизнь обновляя софт отдельно для каждого из процессоров и при этом умножив количество проблем совместимости между версиями? Такая схема будет не очень жизнеспособной.

                    Это не порты медленные, это тормозят устройства, с которыми процессор работает через порты.

                    Нет, это таки порты медленные. Устройства при всём желании не смогут работать быстрее чем работает шина, а скорость у неё ограничена. И за каждый такт на шине PCI процессор успевает сделать сотню тактов.
                    Отражение портов в адресное пространство памяти проблему не решит НИКАК. И если надо по алгоритму организовать сотню обращений к устройству для передачи данных то процессор вынужден будет ждать. По этой причине многие устройства имеют прямой доступ к памяти и общение с ними происходит через ПАМЯТЬ, и это не отражение адресного пространства.

                    в *86 обращение к портам ввода-вывода делается (ну или делалось до того, как контроллер памяти перенесли с сев.моста в процессор) через ту же шину, что и к памяти

                    До тех пор пока память не стала быстрее и эта линия тормозила всю систему при обращении к устройствам ввода-вывода. Вы ведь не забывайте что помимо этой линии для устройств отводился такой важный сигнал как HOLD позволяющий удерживать шину медленному устройству пока оно не примет данные. Именно из-за этого шины разделили. Теперь медленные устройства отделены от быстрой шины мостом и не мешают. Но это решило только часть проблемы — медленные устройства всё так же остались медленными, и если организовать интенсивное обращение к УВВ это может затормозить всю систему: вспомните как ведёт себя система при переключении IDE интерфейса в PIO-режим, а там каких-то 30-40Мб/сек и уже проблемы независимо от скорости процессора и шины памяти. То же касается и GPU — если данные вытаскивать исключительно через порты его потенциал не будет раскрыт полностью.
                    • 0
                      А глупые почему-то используют ASIC и специализированные математические модули… ведь есть GPU.
                      Я не очень понял, при чём тут ASIC. Многие любители вычислений используют GPU — и получают результат обратно. Что мешает построить аналогичную систему по предложенной мной схеме?

                      Я хочу сказать что для системы придётся использовать ОДНОВРЕМЕННО два разных компилятора
                      Почему одновременно???

                      На главном процессоре исполняется ядро (и некоторые приложения, написанные для этого процессора — предполагается постепенная миграция на этот процессор; но тут мы рассматриваем поддержку унаследованных программ, написанных/откомпилированных для *86). На *86 выполняются унаследованные давно откомпилированные программы. Зачем использовать компиляторы одновременно — я не понимаю.

                      Ну хорошо, рассмотрим Web-сервер и браузер (на Ваш выбор). Уж не хотите ли Вы сказать, что Web-сервер и браузер д.б. написаны на одном языке и компилироваться одновременно?
                      Ну или если это Вам ближе — файловый сервер Novell NetWare и DOS-клиент.

                      Хотите ещё сильнее усложнить жизнь обновляя софт отдельно для каждого из процессоров и при этом умножив количество проблем совместимости между версиями?
                      Кажется, Вы не поняли: в современном компьютере уже есть много процессоров — и все проблемы совместимости решаются через соблюдение протоколов.

                      Нет, это таки порты медленные. Устройства при всём желании не смогут работать быстрее чем работает шина
                      Ну так не обязательно выводить порт на шину! Порт может обрабатываться и чипсетом, и даже внутри процессора (в современных процессорах контроллер памяти — в процессоре).

                      И если надо по алгоритму организовать сотню обращений к устройству для передачи данных то процессор вынужден будет ждать. По этой причине многие устройства имеют прямой доступ к памяти и общение с ними происходит через ПАМЯТЬ, и это не отражение адресного пространства.
                      Когда устройства имеют прямой доступ к памяти — они сами залезают в память. В реальную память. Это совершенно другое — протокол общения на другом уровне.

                      Однако, тут Вы опять не понимаете, зачем это сделано. Это для того, чтобы не дёргать процессор IRQ-прерываниями, которые занимают куда больше времени, чем обращение к портам.

                      для устройств отводился такой важный сигнал как HOLD позволяющий удерживать шину медленному устройству пока оно не примет данные
                      Вы про какую шину? В современных процессорах их две: PCI и PCI-X.

                      вспомните как ведёт себя система при переключении IDE интерфейса в PIO-режим
                      Ну так это — как раз обработка IRQ, см.выше!
                      • +1
                        При том что GPU вещь специфичная и не все задачи решает оптимально. И даже вычислительные. Он заточен на работу с графикой, а то что используют для другого это побочная функция.
                        Результат обработки получить обратно можно, но это узкое место вычислителя. GPU заточен на то чтобы получить сравнительно небольшой объём данных, обработать его и оставить в памяти прямо на карте, а там память даже быстрее чем системная, но возвращать результат обратно в системную память довольно накладно поэтому используют GPU в вычислениях когда назад приходит относительно мало данных. Причем в майнинге криптовалюты видеокарты находятся в районе нулевого баланса.

                        в современном компьютере уже есть много процессоров
                        Эти процессоры — черные ящики и могут быть в любой момент заменены на другие без изменения функциональности. И как правило пользователю не надо ставить для них какой-либо софт. Но что касается основного(-ых) процессоров то софт под них надо считать переменным. И то что в идеале мы будем отказываться от x86 софта не означает что его не надо поддерживать и вносить изменения, особенно касающиеся безопасности и уязвимостей. Так или иначе нам надо будет работать как с новым так и со старым процессором на время перехода, которое может затянуться лет на 20, не меньше.
                        • –1
                          GPU вещь специфичная и не все задачи решает оптимально
                          Если Вы можете объяснить, в чём специфичность GPU — объясните. Если не можете — не говорите этого слова.

                          Неоптимально работают все системы. И что дальше?

                          Он заточен на работу с графикой
                          Ну и в чём заключается эта заточка?

                          Я читал про компьютер, высчитывающий движение космических тел в Солнечной системе. Там у процессора была команда, для которой аргументами были координаты и массы двух тел, а результатом — то ли сила взаимодействия, то ли сразу же два ускорения. Вот это я понимаю — специфичность, нигде более не нужная.

                          А в чём заключается заточенность на графику? Синусы, нужные в графике, и обычный процессор неплохо считает; вроде, у всех процессоров это уже есть в виде одной команды.

                          Результат обработки получить обратно можно, но это узкое место вычислителя.
                          Ой, а что там узкого-то? GPU умеет брать достаточно объёмные данные из памяти — текстуры. А значит, может и класть данные обратно.

                          Эти процессоры — черные ящики и могут быть в любой момент заменены на другие без изменения функциональности.
                          Вы меня поражаете. Вы так говорите. как будто яро Windows — не чёрный ящик и не было неоднократно заменено с сохранением совместимости и прежней функциональности. Наиболее значимое изменение — это замена W'95/98/ME на W'NT/2000/XP/etc.

                          И как правило пользователю не надо ставить для них какой-либо софт.
                          Ой! (Падаю под стол.)
                          Я так понимаю, про установку драйверов Вы не слышали. И про проблемы, связанные с этим — тоже.

                          Но что касается основного(-ых) процессоров то софт под них надо считать переменным.
                          Ой, это как?

                          И то что в идеале мы будем отказываться от x86 софта не означает что его не надо поддерживать и вносить изменения, особенно касающиеся безопасности и уязвимостей.
                          От поддержки 16-битного софта отказались уже давно, в т.ч. и от исправления уязвимостей. От поддержки W'XP отказались недавно; а от поддержки W'2000 (последней из Windows, не имевшей 64-битной версии) отказались достаточно давно.
                          (Я не уверен, можно ли считать W'XP'32 и W'XP'64 одной системой — там свои сложности.)

                          Т.е. отказ от поддержки старого софта — это вполне нормальная практика.

                          Но тут (я опять напоминаю) мы обсуждаем такую гипотетическую (в смысле — альтернативная история) ситуацию:
                          «Были компьютеры на процессорах 8086. Вместо создания процессора 286 принято решение сделать компьютер с друмя процессорами. На главном 32-битном процессоре выполняется ядро операционки. На процессоре 8086 выполняются старые унаследованные программы.»

                          Т.е. в нашем случае предполагается, что все те, кто собираются поддерживать свои программы — выпускают новые версии, написанные на ассемблере или откомпилированные для главного процессора. А старые программы — уже не меняются или меняются незначительно (пока не у всех программистов есть новые процессоры).

                          Так или иначе нам надо будет работать как с новым так и со старым процессором на время перехода, которое может затянуться лет на 20, не меньше.
                          Выше я несколько раз написал, что работа с несколькими процессорами — это нормальная практика современных компьютеров. Здесь нет проблемы; точнее, проблемы есть — но они меньше, чем если бы в компьютере был только один процессор.

                          Да-да, реально меньше. Чисто потому, что разнесение работы на несколько процессоров — это аппаратная реализация идеи «слоёв абстракции».
                          Например, мы знаем. что FDD и CD/DVD/BlueRay практически умерли. Тогда как HDD и Flash — живут и развиваются. А почему так? Обратите внимание: в первой группе мы имеем пассивные накопители (не имеющие входа электропитания); а во второй группе — интеллектуальные накопители, в каждом из которых есть собственный процессор.

                          Ну а теперь подумайте, можно ли возложить работу тех процессоров, которые сейчас находятся внутри HDD и Flash, на CPU. И когда Вы осмыслите этот вопрос, можно будет плавно перейти к вопросу о целесообразности зашивания OS в ПЗУ.
                          • +1
                            Специфичность GPU заключается в распарралеливании задачи.
                            Вычислительное ядро у GPU простенькое, зато их МНОГО.

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

                            В видеообработке, где экран можно поделить на участки, и каждый обрабатывать независимо — GPU оказались мегаэффективны.
                            Где нужно перебрать несколько десятков/сотен вариантов и затем уже по результатам выбрать из них один самый удачный — тоже.
                            Но опять таки, в большинстве популярных алгоритмов, сложно придумать даже как их разложить на уже доступные 4-8 ядер, не говоря уж о GPU.
                            • –1
                              Специфичность GPU заключается в распарралеливании задачи.
                              Вычислительное ядро у GPU простенькое, зато их МНОГО.
                              Это никак не тянет на специфичность. Попробуйте ещё раз.

                              Например архивация плохо поддается распарралеливанию, ибо вам нужно проанализировать весь участок данных, чтобы вычислить закономерности на как можно бОльшем участке, иначе степень архивации у вас будет невелика.
                              Что мешает мне анализировать разные куски, а потом объединить таблицы?

                              В видеообработке, где экран можно поделить на участки, и каждый обрабатывать независимо
                              Не получится — для этого надо устранить узкое место в виде «все процессоры постоянно читают трёхмерную модель». Или надо ставить столько памяти (причём отдельные микросхемы с независимым доступом), сколько у нас ядер — каждому ядру свою копию трёхмерной модели.

                              Ладно, вернёмся к моей модели. У меня всего два процессора, оба одноядерные. Как знания о GPU помогут анализировать схему из двух процессоров???
                              • 0
                                То, что анализируя разные куски, вы теряете возможность анализировать их целиком, например если закономерность встречается на стыке ваших кусков.
                                Лучше проанализировать 1 мб, найдя в нем все закономерности, чем разделить 1 мегабайт на 512 ядер, анализируя куски по 2 килобайта.
                                • –1

                                  Ну, заставим процессоры дважды анализировать участки, примыкающие к границам. Т.е. каждый процессор будет анализировать по 2.2 килобайта.

                                  • –1
                                    Этого недостаточно. всеравно каждому ядру нужен доступ ко всему содержимому, или как минимум к общему словарю который наполняется по мере анализа данных т.е. последовательно по мере чтения данных и является узким местом.
                                  • 0
                                    Этого недостаточно. Если ядра будут пользоваться одним общим словарем, парралельность анализа будет не очень, ибо нужно будет результаты каждой обработки куда-то записывать в общую память. Как это сделать, чтобы не мешать друг другу? Ждать результата выполнения и в очередь, иначе каша. Тут можно даже того, кто будет этот алгоритм кодить пожалеть.
                                    Найдя небольшую закономерность, можно тут же найти закономерность побольше. Найдя закономерность в участке 2.2 кб, вы не сможете определить, существует ли такая в 102 фрагменте и можно ли ее использовать.

                                    В общем подобные вопросы давно рассматривались в темах и идеях для «вечного архиватора», поэтому просто нет смысла повторять все базовые истины.
                                    • 0

                                      Разные процессы/потоки (выполняющиеся на разных ядрах) ведут свои словари и не конфликтуют. А по окончании работы они сливают свои словари (или точнее — словари сливает один главный процесс/поток).


                                      Нельзя найти закономерность побольше сразу. Её находят постепенно.


                                      Если закономерность есть в двух фрагментах — её заметят и там, и там. А потом при слиянии словарей выяснится, насколько эта закономерность сильная.

                                      • 0
                                        Только на момент слияния словарей данные должны быть уже сжаты с учетом общего словаря… иначе будут проблемы с распаковкой.
                                        • 0

                                          А зачем сжимать словари перед слиянием?
                                          Сначала по исходному тексту строятся словари (параллелится). Затем словари сливаются, получаем общий словарь (практически не параллелится). Потом по этому словарю строим кодировочную таблицу, и этой таблицей кодируем исходный текст (параллелится) — собственно, это и есть компрессия.

                                          • 0
                                            Выглядит конечно великолепно но за исключением одного ньюанса — исходные данные надо будет прочитать два раза. Представьте какие накладные расходы при необходимости сжать файл в десяток гигабайт?
                                            • –1

                                              Откуда читаем данные — из памяти или с диска? Вроде, в современном мире никто не требует от компрессоров-архиваторов однопроходности.


                                              Так что читаем данные в память — сколько уместится. Разделяем работу по процессорам — они ищут закономерности, потом сливают свои результаты и сжимают данные. Затем данные пишутся на диск, в память читается следующая порция данных, и повторяем.

                                            • 0
                                              Простите. Напишите простенький алгоритм сжатия по словарям для обычного процессора и GPU и проведите эксперимент, что будет работать быстрее.
                                              Просто мы вам объясняем не теорию, а то, что уже опробовано многими людьми. Или вы считаете, что автора 7z, rar, arj и др. идиотами, что они до сих пор поддержку gpu не встроили?
                                              • 0

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


                                                А ещё нас ждут сложности при запуске нескольких программ, каждая из которых пытается использовать GPU. Делить между задачами CPU — задача давно решённая. А вот с GPU всё немного сложнее, туда вытесняющую многозадачность ещё не прикрутили.

                                                • +1
                                                  Да ладно вам, если вы напишете архиватор, который будет использовать GPU (он есть в каждом домашнем компе сейчас), то скорость по идее возрастет в десятки раз.
                                                  На каждом производстве есть бэкапы. Увеличить скорость создания бэкапа в несколько раз — станете знаменитым на весь мир.

                                                  Вы очень много «теоретически» рассуждаете, как все должно хорошо работать, но похоже что вы даже не пытались никогда написать архиватор, который пользуется словарем, и как работает этот алгоритм представляете себе очень плохо. Отсюда эти идеи про «потом словари объединяются».
                                                  Напишите, докажите что вы правы.
                                                  Я, например пробовал, у меня не вышло, о чем я и пытаюсь пояснить. И многие другие пробовали, пока получить серьезное преимущество от GPU получилось только для проверки/хеширования файлов и блоков.
                                                  • +1
                                                    Где-то читал, что подглючивание отдельных процессоров в GPU дефектом не считается — подумаешь, пиксель не той цветности получится.
                                                    А вот для архивации такое не годится.
                                                    • +1

                                                      Как мне недавно объяснили — видеокарта крута не большим количеством независимых процессоров/ядер, а векторными операциями. Т.е. GPU хорошо выполняет операции типа "сложить два массива и положить результат в третий массив (все три массива — одного размера)". А вот выполнять ветвления, каждое из которых зависит от элемента массива — не получается.


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

                                • +1
                                  И что дальше?

                                  железобетонный тролльский аргумент. Всё с вами понятно. Путаете процессоры с контроллерами.
                                  Специфичность GPU это заточенность его ядер под расчеты связанные с графикой, математику на таких ядрах считать можно но не эффективно. Объезжает CPU только за счет количества ядер и более быстрой памяти. Если бы их было не 256 то ещё неизвестно кто был бы быстрее в произвольной математике обычный процессор или GPU.
                                  Ещё раз повторяюсь, для двухпроцессорной системы надо будет поддерживать оба процессора, особенно если они слишком разные. А это и компиляторы и софт… причем на совершенно другом уровне нежели поддержка контроллеров для периферии, где производители делают то что сами хотят ни с кем не согласовывая.
                                  Внутри HDD и Flash находятся МИКРОКОНТРОЛЛЕРЫ, заменить их можно в любой момент только соблюсти внешний интерфейс и для этого всего лишь надо будет переписать прошивку, а не тонну софта.
                                  про установку драйверов Вы не слышали.
                                  Драйвера — это проблема операционки а не периферии. Вы когда нибудь слышали про пользовательский софт выполняющийся на сетевой карте?
                                  • 0
                                    И что дальше?
                                    железобетонный тролльский аргумент.
                                    Не вижу тут никакого троллинга. Вы выкатили аргумент «эта система работает неоптимально». Я ответил «неоптимально работают все системы» и попросил развить тему. А Вы вместо того, чтобы ответить подробнее — перешли на обсуждение личности оппонента.

                                    Кстати, троллинг такой фразой не ведётся.

                                    Путаете процессоры с контроллерами.
                                    Нет, не путаю. Процессор м.б. частью контроллера. А бывают контроллеры без процессоров.

                                    Специфичность GPU это заточенность его ядер под расчеты связанные с графикой, математику на таких ядрах считать можно но не эффективно.
                                    Я уже просил Вас объяснить, в чём специфичность. Чем «расчеты связанные с графикой» — не математика?

                                    Кстати, многие математические задачи делают почему-то на GPU. Дураки, наверно…

                                    Объезжает CPU только за счет количества ядер и более быстрой памяти.
                                    Ну и что же мешает сделать CPU с тем же количеством ядер и с такой же памятью?

                                    Хотя зачем быстрая память, если есть кэш?

                                    Ещё раз повторяюсь, для двухпроцессорной системы надо будет поддерживать оба процессора, особенно если они слишком разные.
                                    Вы опять забыли, что в обычном компьютере процессоров гораздо больше двух? Что их поддерживают (включая компиляторы)? И что программы для этих процессоров модифицируют независимо?

                                    Внутри HDD и Flash находятся МИКРОКОНТРОЛЛЕРЫ
                                    А на микрокотнроллерах (или внутри них, если они однокристалльные) находятся МИКРОПРОЦЕССОРЫ (ну или НАНОПРОЦЕССОРЫ).

                                    заменить их можно в любой момент только соблюсти внешний интерфейс
                                    О! Наконец-то!

                                    Итак, возвращаемся к моей исходной схеме с двумя процессорами. Почему Вы считаете, что там невозможно соблюсти интерфейс?

                                    Драйвера — это проблема операционки а не периферии.
                                    Странно — драйверы обычно пишут производители именно периферии.

                                    А проблемы бывают никак не у устройств, а только у людей.

                                    Вы когда нибудь слышали про пользовательский софт выполняющийся на сетевой карте?
                                    Я давно уже не видел пользовательский софт. Мне всё больше попадается софт разработчиков, которые делает не то, что нужно пользователям, а то, что нужно разработчикам — например, шпионит за пользователем.
                                    • +1
                                      «расчеты связанные с графикой» — не математика?
                                      Я бы сказал что это не математика а арифметика, причем преимущественно в целых числах. А по-настоящему математические расчеты — это как минимум безразмерные числа, которые гарантированно не поместятся в любой фиксированный размер. Например, числа с 10000 значащими разрядами.

                                      Ну и что же мешает сделать CPU с тем же количеством ядер и с такой же памятью?

                                      Хотя зачем быстрая память, если есть кэш?

                                      Накладные расходы на синхронизацию между процессорами и общей шиной. Чем больше ядер тем больше конфликтов на общей шине и тем меньше эффективность многоядерности. Современные процессоры имеют большое количество инноваций, позволяющих уменьшить эту проблему — гипертрединг, отдельные кеши для каждого ядра/процессора и т.д. Но всеравно идеала достичь не удаётся. GPU же имеют заточенную под многопоточность архитектуру, в основном за счет простоты ядер, которым легко даются векторные расчеты но очень тяжело обычные для CPU вещи вроде условных переходов, циклов…
                                      В целом GPU для расчетов используют там где CPU недостаточно быстр(рендеринг видео, видео кодеки, и т.д.) а математический модуль слишком дорог или необоснован. В конце концов, GPU более распространён и уже есть в системе условно бесплатно.
                                      А насчет быстрой памяти… кеш хорош пока алгоритм и объем данных очень мал и полностью укладывается в кеш — нынче это считанные десятки килобайт и коэффициент повторного использования данных больше единицы, а дальше начинается фигня и начинает играть роль скорость работы основной памяти.

                                      Вы опять забыли, что в обычном компьютере процессоров гораздо больше двух? Что их поддерживают (включая компиляторы)?

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

                                      возвращаемся к моей исходной схеме с двумя процессорами. Почему Вы считаете, что там невозможно соблюсти интерфейс?
                                      Где я говорил что невозможно соблюсти? Очень даже возможно, но в два раза затратней по ресурсам разработки чем в системе с однотипными процессорами. Проще накинуть одинаковых ядер чем использовать два разных процессора. А в перспективе это покроет накладные расходы на эмуляцию старого процессора. Поэтому жизнь гибридной системы не имеет перспектив и не стоит затраченных усилий.

                                      Странно — драйверы обычно пишут производители именно периферии.
                                      Давно уже не так… очень нужна эта морока производителям писать драйвера под все существующие системы и с десяток специфических систем для эмбеддеров. Даже за деньги. Как правило, от производителя железа это драйвера на 1-2 популярных систем и не более. Обычно это проблема производителя операционной системы заинтересованного в работе железа на его системе.
                                      • 0
                                        Я бы сказал что {расчеты связанные с графикой} не математика а арифметика, причем преимущественно в целых числах.
                                        Арифметикой занимается процессор. Причём при выполнении любой работы. Это у него механизм такой.
                                        А вот программист занимается математикой, алгоритмами.

                                        Про целые числа — сообщите скорее авторам OpenGL, что они неправильно работают.
                                        И тут (на Хаббре или на GT) на днях пробегала статья о том, как можно быстро приближённо вычислить функцию 1/sqrt(x) для плавающих чисел — там что-то было про магическое число. И обсуждалось это именно в связи с графикой.

                                        А по-настоящему математические расчеты — это как минимум безразмерные числа, которые гарантированно не поместятся в любой фиксированный размер. Например, числа с 10000 значащими разрядами.
                                        Доказать или обосновать можете? Пруфы есть?

                                        Накладные расходы на синхронизацию между процессорами и общей шиной.
                                        «Общая шина» — это что такое? Какие устройства она объединяет?

                                        Чем больше ядер тем больше конфликтов на общей шине и тем меньше эффективность многоядерности.
                                        Допустим, в процессоре есть четыре ядра и общий кэш для всех ядер. Этот кэш разделён на два слоя — первый слой кэширует чётные адреса памяти, второй — нечётные (адрес — это номер сточки памяти, а не байта; строчка памяти по размеру равна строчке кэша).
                                        Теперь у нас нет общей шины, а есть две шины. Процессор при обращении знает, в какой из слоёв кэша надо обращаться. Если обращения распределены равномерно — то количество конфликтов падает в два раза.

                                        А теперь сделаем в кэше 16 слоёв — и конфликты становятся совсем редкими.

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

                                        отдельные кеши для каждого ядра/процессора
                                        А вот отдельные кэши как раз надо синхронизировать.

                                        кеш хорош пока алгоритм и объем данных очень мал и полностью укладывается в кеш
                                        Вы бы теорию кэширования почитали, что ли. Про локальность в пространстве и во времени. Про периоды высокого hit rate и периоды активной замены содержимого кэша.

                                        Для примера можете оценить размер кода и данных у Word/Excel. Затем сравнить это с размером кэша. Получается, кэш вообще неэффективен.
                                        А теперь отключите кэш и проверьте скорость работы.

                                        нынче это считанные десятки килобайт
                                        А я читал — что размер L2-кэша уже десятки мегабайт.

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

                                        В сетевой карте, как правило, прошивка заливается один раз и до её смерти. Поэтому и поддержка компилятора совсем другая, в другой ревизии той же сетевой карты вообще может применяться совсем другой компилятор не совместимый с предыдущим и команда разработки может быть другой.
                                        Ну так при выпуске нового ядра операционки (типа перехода от W'XP к W'Vista; или при смене мажорной цифры в версии FreeBSD) и при выпуске новой версии прикладной программы — точно так же можно сменить компилятор. Не вижу разницы.

                                        Для ваших же процессоров для обоих сразу нужно будет поддерживать два разных компилятора в актуальном состоянии
                                        У меня такое ощущение, что Вы опять забыли, о чём разговор.

                                        А разговор был о том, чтобы осуществить переход от DOS-8086 к нормальному процессору, сохраняя совместимость УЖЕ НАПИСАННЫХ и ОТКОМПИЛИРОВАННЫХ ПРОГРАММ. Т.е. для устаревающего DOS-8086 все компиляторы уже есть, но развивать их уже нет смысла. И создавать новые программы (а значит, компилировать их) уже никто не будет.

                                        Очень даже возможно {соблюсти интерфейс}, но в два раза затратней по ресурсам разработки чем в системе с однотипными процессорами.
                                        Разделение работы компьютера на два процессора означает разделение по уровням абстракции и надёжную изоляцию этих уровней абстракции. Затраты на разработку если и вырастут — то незначительно.
                                        А вот затраты на отладку (на обеспечение надёжности и секурности) — резко снизятся.

                                        Проще накинуть одинаковых ядер чем использовать два разных процессора.
                                        Создатели модемов, HDD, видеоускорителей, сетевых карт, RAID-контроллеров и много чего ещё — смотрят на Вас с недоумением. Расскажите им скорее, какие они придурки — что начали совать в свои изделия процессоры ещё до того, как CPU стали многоядерными. (Кстати — заодно мы имеем достоверный ответ на вопрос о том, что проще.)

                                        Как правило, от производителя железа это драйвера на 1-2 популярных систем и не более. Обычно это проблема производителя операционной системы заинтересованного в работе железа на его системе.
                                        Ок. Я вернусь к Вашему утверждению «как правило пользователю не надо ставить для {периферийных устройств} какой-либо софт». Оказывается, его надо не только ставить, но ещё и писать отдельно под каждую операционку!
                                        • 0
                                          Доказать или обосновать можете? Пруфы есть?

                                          Вычисление числа Пи до милионного знака и дальше.

                                          • 0

                                            Что-то мне кажется, у этой задачи весьма сомнительная практическая ценность...


                                            А что-то полезное предложить можете?

                              • +1
                                В PIO-режиме как раз нет никаких IRQ, это полностью программный режим работы исключительно через порты ввода-вывода.

                                Прямой доступ в память как раз реализовали для разгрузки центрального процессора, чтобы он не оказался узким местом в процессе передачи данных. И более того, скорость общения устройствами с памятью тоже ограничена скоростью шины PCI и PCI-E, которая в разы меньше пропускной способности шины памяти.
                                • 0
                                  В PIO-режиме как раз нет никаких IRQ, это полностью программный режим работы исключительно через порты ввода-вывода.
                                  А вот что врёт на эту тему Википедия: В этом режиме контроллер требовал исполнения драйвером или же BIOSом команды процессора REP INSW/OUTSW для передачи всех данных, обычно команда исполняется в обработчике прерывания контроллера в статусе «готов к передаче данных».
                                  (Термин «прерывание контроллера», очевидно, как раз обозначает IRQ.)

                                  Давайте подумаем, что здесь может сильнее тормозить: прерывание или же каманда «REP INSW/OUTSW».

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

                                  С др.стороны, неясно, сколько времени будет выполняться каждая команда «INSW/OUTSW» в цикле «REP». И это зависит от массы параметров, начиная с наличия буфера на контроллере диска (что-то мне подсказывает — начиная где-то с 386, он там должен быть обязательно; но я могу и ошибаться).

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

                                  скорость общения устройствами с памятью тоже ограничена скоростью шины PCI и PCI-E, которая в разы меньше пропускной способности шины памяти.
                                  Если мы говорим про работу с HDD, то эти ограничения ничтожны на фоне тормознутости механической системы. Да и Flash-память тоже небыстрая.

                                  Основная экономия получается от того, что прихода данных ожидает не дорогой CPU (или в многоядерном CPU — одно его ядро, что тоже недёшево), а дешёвенький DMA-контроллер, который простой (например, потому что не содержит FPU) способен обходиться без кэш-памяти.
                                  • +1
                                    Обычно она выполняется в прерывании, да, но в PIO-режиме не используются прерывания от привода или по крайней мере само прерывание выполняется лишь один раз на запрос — например как сигнал о том что с привода можно считать запрошенные 32 сектора каждый по 512байт. Проблема в другом — если DMA ложит данные прямо в указанный буфер без участия процессора, то в PIO-режиме процессор самостоятельно извлекает данные через регистры привода, а это обращения к портам ввода-вывода которые исполняются в лучшем случае по 100 тактов процессора на каждые 2 считанных байта. Вроде мелочь, но загружает процессор под завязку на высоких скоростях который практически не может в течении этих 100 тактов ничего другого делать. А поскольку все операции настолько низкоуровневого ввода-вывода осуществляются в ядре и с высоким приоритетом то остальным задачам сильно не достаёт ресурсов и даже парализуется работа аудиоподсистемы которая хоть и с использованием DMA работает, но буфер кому-то надо пополнять а процесс этот из менее приоритетных.
                                    • 0

                                      Хм-м-м… А разве привод может давать прерывания? Разве он имеет доступ на шину ISA/PCI, где проходят линии прерывания?
                                      Я всегда думал, что это делает не привод, а контроллер, устанавливаемый в слот шины. А этот контроллер может иметь собственную буферную память.


                                      Откуда у Вас сведения о том, что "обращения к портам ввода-вывода которые исполняются в лучшем случае по 100 тактов процессора на каждые 2 считанных байта"? Для какого процессора и какой шины это выведено?


                                      PS: Я привык подвергать сомнению каждое услышанное мной слово. И особенно — число.

                                      • 0
                                        Какой там контроллер… обычная логика на совпадение адреса(обычно двух — для master и slave), буффер для трёх адресных линий, сигнала CS(выбор master/slave) и двунаправленный регистр-защёлка для изоляции от шины. А сам «контроллер» находится в приводе и имеет отдельный выход запроса прерывания, который потом со слота PCI напрямую заводится на контроллер прерываний. Да, если сделать небольшой генератор(NE555) на IDE-шину можно запросто повесить систему завалив её запросами прерывания от несуществующего привода.
                                        На самом деле всё что делает «драйвер IDE» в винде — это резервирует адресное пространство — два участка по 8 адресов чтобы их не заняли другие драйвера как и для большинства системных устройств.

                                        Дальше — шина 16-битная(в случае IDE), поэтому за одно обращение к порту передаётся 2 байта, а одно обращение к порту, инструкция заставляет ожидать выполнения транзакции на шине — а PCI хоть и внутри чипсета но работает на частоте порядка 30Мгц… сколько тактов процессора пройдёт за один цикл работы шины? Порядка сотни… и это в случае если арбитр шины СРАЗУ ЖЕ даст доступ запрашиваемому устройству, ведь в этот момент шина может использоваться более приоритетным обменом. По этой причине, ещё со времен первых пентиумов стараются уйти от интенсивного обмена через порты используя окна в RAM но и это не сильно помогает — всеравно обмен с УВВ идёт гораздо медленней чем может работать RAM — узкое место это скорость работы шины и она никогда не сможет работать быстрее пока не перейдут на последовательную передачу данных чем собственно и является PCI-E, но… память тоже не стоит на месте там тоже хотят вводить последовательный интерфейс который будет ещё быстрее.
                                        Да, насчет тактов для команды чтения-записи в порты я когда-то читал в справочнике по ассемблеру. Там была написана цифра примерно от 100 и до бесконечности. А замерить реальное время исполнения чего-то идея в голову не пришла… я ж тогда чуть было не сделал свой PCI-девайс вроде 16-битного регистра на свободном адресе, но нехватка времени и идея была похоронена а сейчас что-то уже не хочется в такие мелочи, хотя уверен что смог бы — там больше возни с драйвером на современных операционках.
                                        • 0

                                          Что-то мне кажется, что Вы пишете сведения, относящиеся к IDE-контроллерам/устройствам на шине ISA. Потому что IDE как раз проектировался так, чтобы IDE-контроллер был как можно проще; правда, для этого на брюхо HDD пришлось ставить собственный процессор, особенно когда сообщаемая компьютеру геометрия перестала соответствовать реальной.


                                          Интересно, что это был за справочник? В хорошем справочнике д.б. указано, для какой архитектуры эти цифры. А то ведь даже внутри одной архитектуры есть довольно широкий диапазон значений — например, P'I (без MMX) мог иметь частоту от 66 до 200 мегагерц. На том же P'I обыычо были две шины — ISA и PCI, у которых скорость различалась примерно в восемь раз. И скорость диска тоже может различаться очень сильно.


                                          Если Вам хочется баловаться с собственным устройством — есть FreeDOS. И вроде, под современные операционки есть особый драйвер, позволяющий дёргать порты ввода-выводв и получать сообщения о прерываниях из user-space программ.

                                          • 0
                                            От шины работа контроллера IDE никак не зависит. Работа с ним как велась так и ведётся через 8 портов ввода-вывода.
                                            От архитектуры скорость выполнения операций ввода-вывода зависит слабо, хотя да для Z80 работа с портами была столь же быстра как и с памятью. Даже на модных STM32 операции ввода-вывода очень медленны по сравнению с ядром. Может не 100 тактов, а допустим 30 в лучшем случае, это сильно дело не меняет. В худшем случае окончания операции можно и не дождаться из-за того что шину захватит агрессивное устройство вроде TV-тюнера которое будет гнать поток на полной скорости шины и не даст никому голову поднять(зависит, конечно, от настроек арбитра шины но это настраивается где-то глубоко в чипсете, и возможно концы выведены в БИОСе вроде опции spread spectrum).
                                            Справочник был по ассемблеру процессоров серии Pentium.

                                            особый драйвер, позволяющий дёргать порты ввода-вывода
                                            Драйвер то есть, но на 10-ке он не идёт насколько я знаю т.к. не имеет цифровой подписи и врятли её когда-либо получит. Да и в любом случае наличие такого драйвера в системе это огромная брешь в безопасности. FreeDos это конечно хорошо, но опять же — только для поиграться и не более. Использовать-то устройство захочется в современных операционках!
                                            • 0
                                              От шины работа контроллера IDE никак не зависит. Работа с ним как велась так и ведётся через 8 портов ввода-вывода.
                                              «8 портов ввода-вывода» — это внешний интерфейс контроллера. А внутри м.б. что угодно — например, вместо классического HDD можно распаять Flash прямо на плате.
                                              В данном случае на контроллере м.б. буферная память, в которую контроллер примет данные от диска и будет отдавать со скоростью шины.

                                              А ещё бывают вирт.машины, в которых PIO-mode эмулируется программно (ну, если система эмулируется достаточно тщательно). И там скорость ответа немного совсем другая.

                                              От архитектуры скорость выполнения операций ввода-вывода зависит слабо
                                              Зато длительность такта процессора зависит очень и очень сильно.

                                              Впрочем, от архитектуры тоже зависит достаточно много — например, ISA, EISA, VESA/VLB, PCI и PCI-X имеют очеь разную скорость. А ещё я знаю про MCA и PCI-64.

                                              хотя да для Z80 работа с портами была столь же быстра как и с памятью
                                              Ну так на первых писюках (8086; а возможно, и 286) память сидела на той же шине, что и порты.

                                              Драйвер то есть, но на 10-ке он не идёт насколько я знаю т.к. не имеет цифровой подписи и врятли её когда-либо получит.
                                              Ну а кто мешает внедрить в систему свою собственную корневую подпись (которая удостоверяет подпись производителей драйверов)?

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

                                              Использовать-то устройство захочется в современных операционках!
                                              Linux, *BSD — к Вашим услугам. Там ещё и исходный код открыт.
                                              • 0
                                                Так это и есть контроллер на плате HDD. Он и обеспечивает тот самый интерфейс, а то что на материнке — просто жесткая(но конфигурируемая в некоторых пределах) логика изолирующая контроллер от шины и обеспечивающая работу по конкретному адресу.

                                                Ну а кто мешает внедрить в систему свою собственную корневую подпись (которая удостоверяет подпись производителей драйверов)?
                                                Куда втыкнуть? Насколько я знаю, 10-я винда этому сопротивляется. Они стараются быть монополистами в подписи драйверов, особенно системных. Иначе утечка сертификата и разгул вирусов. не все дрйверописатели, например, держат свои подписи достаточно надёжно. Ну да, сертификат могут отозвать но… это потребует времени.

                                                Вы так говорите, как будто Ваши эксперименты хоть немного соответствуют той модели безопасности, которую обеспечивают подпись на драйверах.
                                                Если не ошибаюсь, тот драйвер может безпрепятственно дать доступ к CMOS-памяти, или портам IDE и напрямую в обход системы общаться с железом — так что потенциальному взломщику/трояну любые антивирусы побоку. Поэтому, микрософт так зажимает гайки с подписью драйверов. На 8-ке вроде ещё был доступен режим отключения проверки подписи, но на 10-ке безальтернативно. Если хочешь свой драйвер — через специальную приблуду пиши, которая работает с пониженными привилегиями и не имеет доступа к ядру.

                                                Linux, *BSD — к Вашим услугам. Там ещё и исходный код открыт.
                                                А толку-то? Что я с линуксом делать буду? Тоже поиграться и выбросить за ненадобностью… держать и постоянно перезагружаться в него только для драйвера на собственную железку?

                                                А, да… эмуляция команд ввода-вывода в виртуалке ещё более накладна чем в железе поскольку обрабатывается особым образом.
                                                • 0
                                                  Если очень хочется подписать драйвер бесплатно, то выход есть.
                                                  • 0
                                                    то что на материнке — просто жесткая(но конфигурируемая в некоторых пределах) логика изолирующая контроллер от шины и обеспечивающая работу по конкретному адресу.
                                                    Когда-то давно COM-порт представлял собой простейшую логику, преобразующую один байт от процессора в последовательность битов по одной линии (и наоборот). Но позже туда впихнули буферную память, благо интерфейс общения процессора с COM_портом позволял это сделать вполне прозрачно.

                                                    Я думаю, что IDE-контроллеры (на самом деле — ATA, а не IDE, но это не важно) давно уже обзавелись собственной буферной памятью — чтобы отдавать данные процессору (и принимать их от процессора) со скоростью шины, а не интерфейса диска.
                                                    При этом у меня есть все основания полагать, что дисковый интерфейс медленне шины — хотя бы потому, что у него меньше разрядность, а кабедь длиннее и при этом гибкий. Шина же имеет больше разрядов, короткая и жёсткая.

                                                    Куда втыкнуть?
                                                    Хороший вопрос. Очевидно, что M$ не станет раскрывать подробности устройства хранилища подписей. Так что нао чистать хакерские форумы.

                                                    Я полагаю, что M$ не может сама написать все драйверы — и предоставляет такую возможность производителям устройств. При этом вряд ли производители устройств имеют способ оперативно подписывать свои драйверы подписью, которая хранится в M$ — слишком опасно.

                                                    Поэтому я полагаю, что система электронных подписей слизана с системы удостоверения подписей в Интернете: подписи авторизованных драйверописателей удостоверены подписью от M$, а дальше драйверописатели сами подписывают своей подписью что хотят. А в Windows хранится корневая подпись; причём с возможностью замены при компрометации.

                                                    Хуже всего — если корневая подпись интегрирована прямо в исполняемый файл в виде константы.

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

                                                    Что я с линуксом делать буду?
                                                    Да то же самое, что и с Виндой. Большинство программ имеют аналоги в Linux; что не имеет — можно запускать в WINE или в вирт.машине с Windows.

                                                    эмуляция команд ввода-вывода в виртуалке ещё более накладна чем в железе поскольку обрабатывается особым образом
                                                    Зато это подобный образ не обращается к шине!
                                                    • 0
                                                      Я думаю, что IDE-контроллеры (на самом деле — ATA, а не IDE, но это не важно) давно уже обзавелись собственной буферной памятью — чтобы отдавать данные процессору (и принимать их от процессора) со скоростью шины, а не интерфейса диска.
                                                      Буферная память есть, но на самом диске.
                                                      Сначала головка читает с диска, где-то на скорости 800 Мb/с. Предварительно потратив сколько-то там времени на позиционирование головки. А потом сливает данные по SATA на 3/6 Gb/s. Только вот если читать с внутреннего конца процессором — то оно побайтно получается, а специальный чип dma умеет лить в память потоком.
                                                      • 0

                                                        Я видел SATA-контроллеры на шину PCI. А на современных мат.платах SATA-контроллеры интегрированные; и, очевидно, там безслотовая шина PCI.


                                                        Как будет лить данные HDD? Должен ли он знать, на какой шине контроллер? Не логичнее ли сделать буферную память ещё и на контроллере (не на диске, а с другого конца SATA-кабеля)?
                                                        (Есть такой принцип: "сочетание каналов с разной скоростью — требует буферной памяти". SATA и PCI — это явно каналы с разной скоростью. Правда, буфером может работать память на брюхе диска.)


                                                        А ещё есть RAID-контроллеры. И про них пишут, что там есть собственная память — чуть ли не в виде стандартных модулей памяти. Неужто брешут?

                                                        • +1
                                                          Ну вот сейчас посмотрел — в контроллере в самом деле есть немножко памяти, 8К, 2К и 256 байт.
                                                          А в RAID там не только память мегабайтами, но и собственный процессор.
                                                          • 0
                                                            Память в «контроллере» нужна только чтобы обеспечить BURST-режим(накапливает с накопителя на скорости 100мб/сек и отдаёт пачкой в шину как та освободится на скорости 2гб/сек) для шины, поэтому её там килобайты… и используется она только в режиме DMA, когда идет программный обмен данные читаются «по одному» и пакетный режим просто не применим. А RAID-контроллеры это совсем другой вопрос, это как аппаратный ускоритель дисковых массивов и задачи у него совсем другие — например собрать информацию с 10 накопителей, посчитать контрольную сумму, отработать алгоритмами коррекции ошибок и передать в систему, понятное дело для таких операций нужны объёмы памяти для хранения перед передачей.
                  • +1
                    " Если бы IBM, а не Microsoft, контролировала бы MS-DOS, Windows и прочих, мир компьютеров был бы совершенно другим."

                    и скорее всего намного менее удобным.
                    • +1
                      Ну, как сказать… Если бы победил, скажем, 68000, то в архитектуре большинства современных компьютеров было бы два стека и было бы меньше роблем с безопасностью из-за переполнения стека.
                      • +2
                        не, я про UI/UX — у межделмаша вполне могла пойти отговорка «не понимаете как этим пользоваться? пройдите наши курсы всего за $199,95/занятие»
                        • 0
                          Как бы сертификация по продуктам MS/IBM/Cisco/Juniper/HP/DELL и так есть, и делится на туеву кучу всякой специализации, вроде сетей, хранилищ или мейнфреймов.
                        • +1
                          Вообще-то у x86 (ia32 и x64) уже несколько десятилетий существует возможность использовать свой стек для каждого уровня привилегий, автоматически переключаемый при переключении задач. Иначе пользовательское приложение получило бы возможность испортить стек привилегированных процедур ОС, а это абсолютно недопустимо.

                          image
                          • +2
                            А стек данных можно отдельно сделать от стека адресов возвращения?
                            • 0
                              Хороший вопрос, но обычно стек данных в x86 архитектуре в Форт системах делают через использование BP регистра.

                              P.S. Любители, кстати, запускают Forth на процессоре из статьи turboforth.net
                              и снимают видео.
                              • +1
                                Аппаратной поддержки для такого разделения стеков в x86 нет.
                                Да, есть опасность потери управления вследствие несоответствия количества инструкций PUSH при входе в процедуру и POP при выходе из процедуры. Разработчики x86 посчитали что важнее изолировать стеки между уровнями привилегий, защищая ОС от ошибок в приложениях, чем защищать приложения от самих себя.
                                • 0
                                  Они вообще ничего не считали, в первых x86 ничего ни от кого защищать не требовалось, просто не хотели копировать конкурентов. А потом уже пошло «а зачем второй стек, если все равно весь софт использует только один». Вот теперь и сидим с тем что есть в мире, где с переполнением буферов борятся уже лет 30.
                                  • –1
                                    30-летняя борьба с переполнением буферов, сравнительно недавно завершилась успехом. Технология MPX предусматривает отдельную защиту от несанкционированной модификации данных на уровне привилегий пользователя.
                                    • 0
                                      Каким образом это защитит от переполнения буфера? В четыре регистра никак не влезет весь список локальных переменных на стеке. Или перед каждой операцией загружать в эти регистры адреса используемых массивов? :)
                                      • 0
                                        От переполнения не защитит, но защитит от последствий — приложение сможет навредить только себе и не позволит выполнить код с более высокими привилегиями, для чего собственно и эксплуатируют переполнение.
                                        • 0

                                          В большинстве случаев хватает и прав пользователя программы, чтобы натворить дел. С отдельным стеком данных — злоумышленник сможет запороть только локальные переменные, что в 99.5% даст защиту от взлома.

                                        • +1

                                          Дополнительно вводится понятие «таблиц границ», которые хранят описания диапазонов памяти, в случае нехватки регистров границ.

                                          • 0
                                            Ну и какова будет скорость работы, если при каждом обращении к памяти — нужно будет сверяться с содержимым таблиц в этой же самой памяти?
                                  • 0
                                    Если стек общий (без разделения на стек адресов возврата и стек данных), то серия записей в память по PUSH на входе или POP на выходе из подпрограммы, попадет в ту же самую строку (или группу последовательных строк) кэш-памяти, что и ранее сохраненный адрес возврата. Это кэш-попадание в сравнении с обращением к ОЗУ при кэш-промахе может сэкономить сотни процессорных тактов.
                                    • +1
                                      Ну, как бы очевидно, что если второй стек не делать, то можно сэкономить много тысяч транзисторов в процессоре на его логике и кэше. Только вот эта экономия уже десятки лет боком встает для безопасности…
                                • 0
                                  Учитывая что в мейнфреймах IBM стека и прерываний ЕМНИП вообще не было — могло быть и в обратную сторону…
                                  • +2
                                    Ну, фактически там стек был (R13 и макросы SAVE/RETURN), просто сделанный из того что было. Громоздкий и медленный механизм, требующий выделения памяти на каждый вызов подпрограммы, в микропроцессорах такое бы никто делать не стал.
                                • 0
                                  и скорее всего намного менее удобным.

                                  Спорный вопрос. Та-же os/2 в плане юзабельности интерфейса была неплоха.
                                  • 0
                                    возможно, сильно попользоваться ей не получилось. но и чисто мдмовской разработкой оно тоже небыло.
                                    • 0
                                      OS/2 без MS/DOS просто не было бы, а IBM разрабатывала бы вместо этого версии своих OS, адаптированных с мэйнфреймов, выпуская минорные апгрейды раз в 10 лет, стоимостью в пятизначные суммы в долларах.
                                      В общем, нынешний Oracle на этом фоне выглядел бы невинным ягненком.
                                      • 0
                                        История, как говорится, не знает сослагательного наклонения, поэтому не буду спорить что-бы представляла из себя полуось, но я говорил именно про UI. А он был основан на, скажем так, методологии CDE. В принципе, по той же методологии делали UI и SUN в своей соляре. Речь, естественно, идет о полуоси версий 3 и выше.

                                        Ну и если бы не было MS (компания) полуось бы не была так коряво спроектирована в части ядра. UNIX был в этом отношении более зрелым.
                                        • 0
                                          В данном случае вполне знает, так как хорошо известно, какой была IBM в 80-х (ну и 30 предшествующих лет), что заставило ее измениться, откуда вообще возникла идея создавать OS/2 как таковую, кто первоначальную версию писал, и так далее.
                                          И, кстати, какое отношение UI имеет к OS? Настолько ли важное, чтобы говорить о нем, в отрыве от OS? Это какое-то «не для хабра» представление о компьютерах.
                                          • 0
                                            настолько — типичному пользователю достаточно пофиг, что там под капотом; ему надо чтоб удобно было и обои нескучные.

                                            (ну и вспоминаем количество разных гуев в линухах и срачей вокруг них)
                                            • 0
                                              Мне казалось, что на Хабре и ГТ все же собираются люде НЕ называющие системный блок «процессором».
                                              • +1
                                                и-и-и, ваша идея? посадить всех на идеально стройное железо и систему с интерфейсом, кривая обучения у которой будет а-дя Dwarf Fortress?

                                                кажется, мы это уже проходили где-то в 60е, когда программист и оператор эвм были двумя разными людьми.
                                                • 0
                                                  Моя идея — оставить все как есть ;) (кстати откуда у вас взялась мысль, о том, что я предлагаю какой-то другой вариант?)

                                                  Мне как раз кажется, что получившийся результат — умеренно лучший, и уж точно лучший чем «будущее по версии IBM образца 1985-го».
                                                  Я лишь обратил внимание, что стенать «ах этот мелкософт, если бы не он, ИБМ построило бы счастье с полуосью и презентеэйшн менеджер!» не очень разумно, и совершенно неисторично. Без MS мы бы в MVS программировали на PL/1 и прочих скулосворачивающих от тоски штуках.
                                                  • 0
                                                    >>> Мне как раз кажется, что получившийся результат — умеренно лучший, и уж точно лучший чем «будущее по версии IBM образца 1985-го».

                                                    ну так и мне кажется, что под одним межделмашем у нас были бы чугунные игрушки, приваренные к полу.
                                                    • 0
                                                      Ну и чего мы спорим тогда? ;) Я считаю также. Ура. )
                                      • +2
                                        Основное отличие OS/2 от Win в тот момент было, что пока OS/2 шлифовала UI, MS штамповала драйвера и совместимость под все, что было.

                                        В результате юзер мог поставить Win, и поругиваясь на глюки работать.
                                        А чтобы поставить OS/2, надо было долго трахаться с драйверами, чтобы завелись все нужные устройства. А потом уже да, можно было радоваться.

                                        Например для фидошной ноды, где нужен был только рабочий модем и tmail, OS/2 была хорошей заменой винды в плане стабильности работы.
                                        Но для себя, каждый апгрейд — головная боль. Прикладного ПО и игрушки — под Вин появлялись как грибы.
                                      • +1
                                        Microsoft контролирует часть мира компьютеров.
                                        Есть ещё Apple, которые легко поменяли процессор в своих ПК на x86 от Intel.
                                        • 0

                                          Да не сказать что на ходу поменяли. Скорее реинкарнация после смерти. С созданием новой ОС.

                                          • 0
                                            Тут важно что не потеряли клиентов.
                                            • 0

                                              Да и клиентов​ скорее новых набрали. Вряд ли апологеты сидели и ждали чуда воскрешения :)
                                              Ну, многие, наверно, порадовались. Но все же понимали что это другая машина и другая ОС, только лишь внешне похожая.

                                              • 0
                                                Помнится, мне один эпплофил в те времена с горечью говорил: «мы становимся софтверной компанией».
                                                Нет, в Apple он ни дня не работал. Да, апологетом как был, так и остался.
                                          • +1
                                            Ну если капнуть глубже то Apple несколько раз меняла процы — первый раз с, уже упомянутой в статье, Motorola на PowerPC и второй раз с PowerPC на Intel
                                        • +1
                                          производитель предоставил тысячи примеров выпущенного продукта

                                          Образцы наверное?
                                          • +4
                                            Да там весь перевод такой
                                          • 0
                                            Наверное, уместным будет здесь клип Мэка Дэйвиса «It's Hard To Be Humble»

                                            • +1
                                              Спасибо.
                                              Вы выбрали очень интересную статью для перевода.
                                              • 0
                                                Семейство 320 DSP и его производные начали приносить почти половину всей прибыли TI

                                                Оказывается его копии — микросхемы 1867ВМ7Т, 1967ВЦ1Т, 1910ВМ1Т, 1901ВЦ1Т.

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