Ну, мне удавалось объяснить работу мультивибратора на двух транзисторах "на пальцах", без всяких дифуров. Постепенный заряд/разряд конденсатора вполне понимабелен, тем более, что легко придумывается "гидравлический" аналог и конденсаторов, и резисторов.
Это целое семейство мэйнфреймов, на которые люто... кхм... онанировал небезызвестный Дейкстра (который как раз в Burroughs и работал), попутно поливая грязью IBMовские машины -- ведь там было всё просто и примитивно: обычные регистры, обычная память, никаких тебе тэгов с типами информации, никакой тебе виртуальной памяти за счёт сегментов переменной длины, а скучные страницы фиксированного размера... И такого на Западе было полно -- ничуть не меньше, чем у нас. И, к громаднейшему сожалению, мы не только скопировали удачные, в общем и целом, архитектуры Системы 360 или там PDP-11, но и стащили эти идеи тоже -- и воплотили их в советских Эльбрусах (да-да, наши тогдашние Эльбрусы "идеологически" -- аналог этих уродцев от Burroughs со всеми их "гениальными особенностями", хотя именно аналог, а не копия архитектуры -- в отличие от ЕС ЭВМ).
От 51-битного слова данных крышу, похоже, не сносило. Или, раз это "у них", это другое? (если что, это Burroughs B6800 -- причём не 50-е годы, как Стрела, а уже 70-е; IBM уже десять лет как байты изобрела).
Ну, не на совсем уж 100%, но на 99,9% точно :) Навскидку одно из важных, но узкоспецифических отличий, -- префикс, необходимый для построения многопроцессорных систем. В 360 он задавался вручную переключателями на пульте управления (только не на фронтальной поверхности, а изнутри, поскольку его значение практически никогда не менялось после запуска в эксплуатацию), а в 370 он задаётся программно, для чего у проца есть соответствующий регистр и всё такое. Соответственно, "многопроцессорная" часть ПО (во всяком случае, код инициализации) оказывалась разной для 360 и 370 -- но в общем объёме кода ОС это мизер, конечно.
Но обратите внимание, что ранние советские машины (т.н. "Ряд 1") -- это Система 360, а (почти) все более более поздние -- Система 370, но в достаточно ранних её вариантах (кажется, в объёме, описанном в GA22-7000-3 или -4), а данное руководство является последним по Системе 370 и включает описание ряда средств, которые у наших машин, похоже, реализованы так и не были.
Какие, простите, готовые компоненты? Лампы? Так у них разрядности попросту нет, из них что угодно собрать можно -- как и из транзисторов. И, кстати, от 52-битного слова крышу, значит, не снесёт?
БЭСМ-6 выглядела весьма посредственно по сравнению с современными или даже более ранними машинами Крэя (CDC 6600 и иже с ней). У IBM виртуальная память появилась не в Системе 370, а раньше, в модели 67 Системы 360, но она не была первой: раньше неё появились Atlas и какая-то из машин Burroughs. Советские же Эльбрусы, созданные уже после решения о копировании, вобрали в себя целую кучу архитектурно провальных идей, поэтому и умерли очень быстро -- оказались абсолютно бесперспективными (правда, на момент начала работы над ними догадаться, что они будут провальными, было достаточно проблематично: в теории всё выглядело красиво; примерно то же самое лепила и Burroughs -- и тоже сошла со сцены). Но если по процессорам в 1960-е мы были ещё более-менее (в разы уступая по производительности только самым мощным американским машинам, но будучи вполне на уровне основной массы), то по периферии всё было много хуже (недаром даже у БЭСМ-6 были магнитные барабаны мизерной ёмкости -- диски появились позже, будучи "заимствованы" у ЕС ЭВМ, т.е. у IBM), а с программным обеспечением вообще был полный швах (собственно, решение о копировании Системы 360 во многом было вызвано как раз желанием утащить готовое системное ПО).
Причём, замечу, если в уничтожении немецкой бронетехники мы безусловно на первом месте (кажется, Черчилль в своих мемуарах указывал, что 2/3 личного состава и 80% бронетехники вермахт потерял на восточном фронте), то в плане уничтожения немецких подлодок наш вклад, скажем так, очень и очень невелик -- а построение данной фразы автором наводит на мысль, что СССР и в этом деле был главным.
Ну, изначально водопроводные вещи были прямо связаны со свинцом, откуда и plumbing в английском. Но, учитывая, что мы не знаем, какой материал был реально использован в данном случае, корректней перевести было бы всё-таки "водопроводные" -- ибо колена уже могли быть и чугуниевыми (хотя могли быть и буквально свинцовыми, как Вы совершенно верно заметили).
Ага, тоже у нас такой был -- правда, реально им почти не пользовались (я баловался для антиреса, но бесперспективность векторного дисплея мне тогда была уже очевидна: сравнивал с растровой графикой на школьных Агатах).
Но назначение, в общем-то, абсолютно одинаково, различается принцип работы. Так что эпл реально врёт -- ничего нового она в этом не придумала, а лишь усовершенствовала достаточно распространённую вещь. (Я вообще не уверен, что она придумала хоть что-то, а не брала и доводила до ума чужие идеи -- но это отдельная тема)
А вот так сделали :) А "Стрела" была то ли 51-, то ли 53-разрядной. Были и 18-разрядные машины, и 24-, и ещё всякие разные -- что у нас, что у них. У ранних машин критерий определения разрядности нередко был, в двух словах, такой: определяли, какой диапазон вещественных чисел должна обрабатывать эта машина и какая точность требуется. Исходя из этого, определяли, сколько битов нужно для представления мантиссы и порядка -- вот вам и размер машинного слова. А коды команд уже втискивали в это слово, как получится.
в начале 1960-х годов объём оперативной памяти измерялся не гигабайтами и даже не мегабайтами, а десятками или сотнями килобайт
В начале 1960-х байтов ещё не было :) Деление машинного слова на 8-разрядные байты было впервые введено в Системе 360, анонсированной IBM в 1964-м году. Но даже если пересчитывать в привычные нам байты объёмы памяти тех машин, сотни будут возникать весьма и весьма редко и только в самых мощных и дорогих машинах. Скажем, у самой мощной чисто советской ЭВМ в лице БЭСМ-6 памяти было 32 Кслова, что с учётом её 48-разрядного слова даёт эквивалентный объём всего в 192 Кбайта (и замечу в скобках, что в плане объёма памяти в те годы мы ещё не отставали от Запада так уж сильно: объём ферритового ОЗУ больше ограничивается массогабаритными характеристиками, ну а колечки были плюс-минус одинаковыми что у нас, что "у них"; это с появлением полупроводникового ОЗУ отставание стало быстро нарастать, откуда и возникла грустная шутка про "мегабайт -- американское название килобайта"). А вот массовые, широко распространённые ЭВМ имели памяти ощутимо меньше (скажем, наша "Минск-22", если правильно помню, имела слово 37 бит и объём памяти 8 Кслов; у её наследника "Минск-32" объём памяти был увеличен до максимум 64 Кслов -- но это уже начало 1970-х).
Кстати говоря, у упомянутого в статье IBM 2250 по штату было 4 Кбайта памяти; была предусмотрена возможность расширить этот объём до 8 Кбайт.
Вы думаете у человека, у которого не набита рука на верилоге - вдруг возникнет талант сделать гениальный CPU? Это не получится по очень банальной причине: когда дизайнер придумывает микроархитектуру, стадии конвейера, внутренние буфера и таблицы всякие - он должен очень хорошо чувствовать у каких операций будет какая задержка внутри такта
Скорей, не в верилоге или другом ХДЛ, а в схемотехнике: нужно же понимать, в какое "железо" превращаются те или иные конструкции языка, а не просто уверенно владеть синтаксисом ХДЛ и уметь описать на нём желаемое поведение.
Придумали это не дураки, а люди которые все внимательно по тактам меряли, и у них получилось что статистически это в среднем работает хорошо
Ну так и саму концепцию RISC придумали не дураки, и посчитали правильно -- что в CISC-процессорах активно используется от силы 10% команд, а остальные -- эпизодически, вот и решили их выкинуть. Однако на сегодняшний день от их изначальной концепции осталось только выполнение операций исключительно в регистрах, и то есть определённые подвижки для ухода от этого в некоторых специфических случаях: внезапно оказалось, что эти самые редко используемые команды многократно ускоряют выполнение соответствующих классов задач, т. е. отнюдь не бесполезны, если речь идёт о вычислительных системах достаточно высокой производительности, а не минимальной стоимости и потребляемой мощности. Вот и набиты современные типа RISC-процессоры сотнями, а то и тысячами странных и редко используемых команд :) (хотя насколько странных, как EDMK в Системе 360, сейчас, пожалуй, не встречается)
Ну и если б такое управление TLB работало бы действительно хорошо, от него бы, в конечном итоге, не отказались бы, да и использовался бы такой подход намного шире.
А вы в курсе, что даже в достаточно простых мипсовских ядрах микроконтроллерного класса аппаратные кэши трансляций состояли не из одной таблицы, а из трех? И в дополнение к нему вот тот механизм.
Нет, не в курсе; я особо в MIPS не погружался -- так, полистал немного для общего развития, и всё. На практике с ними никогда сталкиваться не приходилось, вот и не углублялся. Но это уже тонкости реализации, а не архитектурно-концептуальный уровень (очевидно, что у современных мэйнфреймов z/Architecture TLB тоже несколько отличается от, скажем, использованного в System 370/145, чья микроархитектура была нами содрана и воплощена в ЕС-1035: там весь TLB аж из восьми (восьми!) элементов состоит, а управляется микропрограммно, насколько помню; однако для программиста эти тонкости совершенно безразличны, ибо на концептуальном уровне TLB ведёт себя одинаково на любых моделях).
286 - это ядро с разными тупиковыми странностями как я помню
Угу. Не столько даже тупиковая -- сделать полноценную ОС с виртуальной памятью и прочим на этом можно, и даже некоторые дополнительные возможности были бы доступны и реализовывались бы дёшево в плане скорости, но очень уж неудобно всё это дело было, поэтому и не прижилось. (Замечу в скобках, что подход IBM -- "нормальная" виртуальная память на основе страниц с "нормальным" MMU плюс архитектурная концепция множества адресных пространств плюс архитектурный же механизм "вызова программы" оказались намного элегантнее и эффективнее, чем Интеловские описатели сегментов и шлюзов вызова, хотя, в первом приближении, позволяют решить одни и те же задачи аппаратными (с точки зрения программиста) средствами, т.е. достаточно быстро -- в отличие от чисто программной реализации путём вызова соответствующих сервисов операционной системы, что всегда очень дорого).
а PDP-11 упоминать нельзя, потому что люди влюбляются в его ассемблер и им приходится доказывать, что это плохая архитектура так как она делает конвейеризацию дорогой из-за двухоперандности и аутоинкрементов
А тем, кто влюбился, показать VAX-11, а потом попросить набросать концепцию суперскалярного процессора этой архитектуры :) Ага, с длиной кода команды от 1 до 36 байт :)))) В PDP-11, по крайней мере, выборку и декодирование команд сделать несложно -- длина хоть и переменная, но количество вариантов ограничено (1, 2 или 3 слова, т. е. 2/4/6 байтов), а однозначно определить её можно анализом первого слова (хотя в Системе 360 и её потомках анализ ещё проще: длину кода команды (тоже 2/4/6 байтов) определяют два старших бита первого байта). Собственно, поэтому мне VAX-11 и не нравится, хотя PDP-11 -- моя любимая 16-разрядная архитектура, а VAX лишь продолжил её идеи: просто DEC решила сделать мощную машину, а концептуальный подход использовала, который был успешным для маленькой и дешёвой машины; естественно, ничего из этого не вышло (VAX-11 получился слишком дорогим, чтоб вытеснить PDP-11 из её ниши, но при этом не имел шансов стать высокопроизводительным, чтоб действительно составить конкуренцию тем же мэйнфреймам IBM).
В учебных программах мало времени, учителя норовят впихнуть свою ностальгию по детству (6502 всякие), а студенты легко отвлекаются на всякое, поэтому нужно держать их строго фокусированными, чтобы они могли решать задачи на будущих интервью, а не процессорной археологией заниматься.
Честно говоря, не уверен. Что бизнесу нужны готовые специалисты -- это понятно, а Вы как раз в бизнесе и работаете, решаете реальные инженерные задачи. С другой стороны, нельзя подготовить исследователя/учёного, если у него кругозор ограничивается тем, что нужно и эффективно здесь и сейчас. Но это возвращаемся уже к общим проблемам образования -- в частности, к "целеполаганию" в образовании: а кого мы вообще готовим в том или ином учебном заведении? Думается, количество вузов, как я их понимаю, нужно сократить радикально -- раз в 10, а то и больше, -- и они должны готовить именно учёных; ну а для более приземлённых вещей типа обычных программистов или там "вериложников" -- условные техникумы и ПТУ. Ну, думаю, Вы понимаете идею.
Из сферического вакуума у нас, кстати, тоже было в 90-е, например Z-преобразование (по схемам с задержками и коэффициентами - никогда не встречал потом на практике!), но это было только на первом курсе, на абстрактном мат-анализе
Из школьного: вводят производные и интегралы в последних классах на уроках алгебры -- но чисто "сферически в вакууме", и основная масса учеников понятия не имеет, нафиг нужны эти математические извраты. А вводить можно было бы даже раньше, но в рамках физики -- механики, где прекрасно видно, как резко эти извраты упрощают решение многих задач, приближённых к реальности (преобразования между путём-скоростью-ускорением и т.п.). Как по мне, пользы от такого обучения было бы куда больше: и достаточно понятная, очевидная и практически применимая физика, и сразу математический аппарат для её обслуживания.
А мне вспомнился Терри Прачет и его "Народ", где "полуглавная героиня" -- девочка из британской королевской семьи, попавшая на почти необитаемый остров -- в один момент думает, что их (девочек знатного происхождения) учат лишь тому, что точно никогда не пригодится в реальной жизни :)
В более поздних архитектурах, например в MIPS, TLB был не в памяти, а на основе CAM (блоков context-addresable memory) и регистровых структур. При tlb miss происходило исключение и в его программном обработчике можно было подгрузить данные из памяти.
Мне это такой дикостью показалось: ведь жутко медленно и неэффективно по сравнению с аппаратной выборкой из таблиц переадресации, а последняя -- вещь весьма простая, чтоб на ней усиленно экономить.
В любом случае, сейчас академический стандарт - RISC-V
Что, уже официально на RISC-V перешли? Я-то от образования далёк, поэтому не в теме, что там и как -- только по книжкам что-то вижу.
Но говорил я больше о том, что давать глубоко надо, конечно, современное, но упомянуть неплохо бы и существовавшие некогда другие подходы -- для общего развития, так сказать, но без траты сколько-нибудь значительного времени на это дело (кто заинтересуется историей -- сам найдёт, ему достаточно ключевые слова подсказать).
А я б про кэши и таблицы страниц рассказал бы в 16-17 лет, когда познакомился с этим на реальном железе... В общем, если человеку интересна некая тема, он и сам её изучает, а если неинтересна -- никакой вуз не поможет (и вопрос только в том, а нафига такой человек в вузе?)
Строго говоря, не обязательно, хотя во всех современных архитектурах, думается, это именно так. Навскидку из отличающихся "исторических" архитектур:
80286 с его теневыми регистрами для сегментов (хотя, подобно TLB, теневые сегментные регистры хранят информацию, полученную из таблиц в памяти, но, в отличие от TLB, это не "кэш" в том смысле, что каждый теневой регистр обновляется процессором не "по собственному желанию", а в строго определённый момент -- когда выполняется загрузка соответствующего сегментного регистра, т.е. по прямому указанию программиста). В IA-32 теневые регистры сохранены, но там появился уже и нормальный TLB, поскольку появилась нормальная страничная организация памяти;
PDP-11, где преобразование адресов основано на регистрах MMU: из-за малого объёма виртуального адресного пространства (64 Кбайта) нужды в таблицах переадресации, расположенных в ОЗУ, нет, и всё необходимое лежит прямо в MMU; соответственно, нужды в TLB тоже нет.
Ну, мне удавалось объяснить работу мультивибратора на двух транзисторах "на пальцах", без всяких дифуров. Постепенный заряд/разряд конденсатора вполне понимабелен, тем более, что легко придумывается "гидравлический" аналог и конденсаторов, и резисторов.
Это целое семейство мэйнфреймов, на которые люто... кхм... онанировал небезызвестный Дейкстра (который как раз в Burroughs и работал), попутно поливая грязью IBMовские машины -- ведь там было всё просто и примитивно: обычные регистры, обычная память, никаких тебе тэгов с типами информации, никакой тебе виртуальной памяти за счёт сегментов переменной длины, а скучные страницы фиксированного размера... И такого на Западе было полно -- ничуть не меньше, чем у нас. И, к громаднейшему сожалению, мы не только скопировали удачные, в общем и целом, архитектуры Системы 360 или там PDP-11, но и стащили эти идеи тоже -- и воплотили их в советских Эльбрусах (да-да, наши тогдашние Эльбрусы "идеологически" -- аналог этих уродцев от Burroughs со всеми их "гениальными особенностями", хотя именно аналог, а не копия архитектуры -- в отличие от ЕС ЭВМ).
От 51-битного слова данных крышу, похоже, не сносило. Или, раз это "у них", это другое? (если что, это Burroughs B6800 -- причём не 50-е годы, как Стрела, а уже 70-е; IBM уже десять лет как байты изобрела).
Ну, не на совсем уж 100%, но на 99,9% точно :) Навскидку одно из важных, но узкоспецифических отличий, -- префикс, необходимый для построения многопроцессорных систем. В 360 он задавался вручную переключателями на пульте управления (только не на фронтальной поверхности, а изнутри, поскольку его значение практически никогда не менялось после запуска в эксплуатацию), а в 370 он задаётся программно, для чего у проца есть соответствующий регистр и всё такое. Соответственно, "многопроцессорная" часть ПО (во всяком случае, код инициализации) оказывалась разной для 360 и 370 -- но в общем объёме кода ОС это мизер, конечно.
Держите ссылку: https://disk.yandex.ru/d/Y07g0tNR5_YaYQ
Но обратите внимание, что ранние советские машины (т.н. "Ряд 1") -- это Система 360, а (почти) все более более поздние -- Система 370, но в достаточно ранних её вариантах (кажется, в объёме, описанном в GA22-7000-3 или -4), а данное руководство является последним по Системе 370 и включает описание ряда средств, которые у наших машин, похоже, реализованы так и не были.
Какие, простите, готовые компоненты? Лампы? Так у них разрядности попросту нет, из них что угодно собрать можно -- как и из транзисторов. И, кстати, от 52-битного слова крышу, значит, не снесёт?
БЭСМ-6 выглядела весьма посредственно по сравнению с современными или даже более ранними машинами Крэя (CDC 6600 и иже с ней). У IBM виртуальная память появилась не в Системе 370, а раньше, в модели 67 Системы 360, но она не была первой: раньше неё появились Atlas и какая-то из машин Burroughs. Советские же Эльбрусы, созданные уже после решения о копировании, вобрали в себя целую кучу архитектурно провальных идей, поэтому и умерли очень быстро -- оказались абсолютно бесперспективными (правда, на момент начала работы над ними догадаться, что они будут провальными, было достаточно проблематично: в теории всё выглядело красиво; примерно то же самое лепила и Burroughs -- и тоже сошла со сцены). Но если по процессорам в 1960-е мы были ещё более-менее (в разы уступая по производительности только самым мощным американским машинам, но будучи вполне на уровне основной массы), то по периферии всё было много хуже (недаром даже у БЭСМ-6 были магнитные барабаны мизерной ёмкости -- диски появились позже, будучи "заимствованы" у ЕС ЭВМ, т.е. у IBM), а с программным обеспечением вообще был полный швах (собственно, решение о копировании Системы 360 во многом было вызвано как раз желанием утащить готовое системное ПО).
Причём, замечу, если в уничтожении немецкой бронетехники мы безусловно на первом месте (кажется, Черчилль в своих мемуарах указывал, что 2/3 личного состава и 80% бронетехники вермахт потерял на восточном фронте), то в плане уничтожения немецких подлодок наш вклад, скажем так, очень и очень невелик -- а построение данной фразы автором наводит на мысль, что СССР и в этом деле был главным.
Ну, изначально водопроводные вещи были прямо связаны со свинцом, откуда и plumbing в английском. Но, учитывая, что мы не знаем, какой материал был реально использован в данном случае, корректней перевести было бы всё-таки "водопроводные" -- ибо колена уже могли быть и чугуниевыми (хотя могли быть и буквально свинцовыми, как Вы совершенно верно заметили).
Ага, тоже у нас такой был -- правда, реально им почти не пользовались (я баловался для антиреса, но бесперспективность векторного дисплея мне тогда была уже очевидна: сравнивал с растровой графикой на школьных Агатах).
Но назначение, в общем-то, абсолютно одинаково, различается принцип работы. Так что эпл реально врёт -- ничего нового она в этом не придумала, а лишь усовершенствовала достаточно распространённую вещь. (Я вообще не уверен, что она придумала хоть что-то, а не брала и доводила до ума чужие идеи -- но это отдельная тема)
А вот так сделали :) А "Стрела" была то ли 51-, то ли 53-разрядной. Были и 18-разрядные машины, и 24-, и ещё всякие разные -- что у нас, что у них. У ранних машин критерий определения разрядности нередко был, в двух словах, такой: определяли, какой диапазон вещественных чисел должна обрабатывать эта машина и какая точность требуется. Исходя из этого, определяли, сколько битов нужно для представления мантиссы и порядка -- вот вам и размер машинного слова. А коды команд уже втискивали в это слово, как получится.
В начале 1960-х байтов ещё не было :) Деление машинного слова на 8-разрядные байты было впервые введено в Системе 360, анонсированной IBM в 1964-м году. Но даже если пересчитывать в привычные нам байты объёмы памяти тех машин, сотни будут возникать весьма и весьма редко и только в самых мощных и дорогих машинах. Скажем, у самой мощной чисто советской ЭВМ в лице БЭСМ-6 памяти было 32 Кслова, что с учётом её 48-разрядного слова даёт эквивалентный объём всего в 192 Кбайта (и замечу в скобках, что в плане объёма памяти в те годы мы ещё не отставали от Запада так уж сильно: объём ферритового ОЗУ больше ограничивается массогабаритными характеристиками, ну а колечки были плюс-минус одинаковыми что у нас, что "у них"; это с появлением полупроводникового ОЗУ отставание стало быстро нарастать, откуда и возникла грустная шутка про "мегабайт -- американское название килобайта"). А вот массовые, широко распространённые ЭВМ имели памяти ощутимо меньше (скажем, наша "Минск-22", если правильно помню, имела слово 37 бит и объём памяти 8 Кслов; у её наследника "Минск-32" объём памяти был увеличен до максимум 64 Кслов -- но это уже начало 1970-х).
Кстати говоря, у упомянутого в статье IBM 2250 по штату было 4 Кбайта памяти; была предусмотрена возможность расширить этот объём до 8 Кбайт.
Скорей, не в верилоге или другом ХДЛ, а в схемотехнике: нужно же понимать, в какое "железо" превращаются те или иные конструкции языка, а не просто уверенно владеть синтаксисом ХДЛ и уметь описать на нём желаемое поведение.
Ну так и саму концепцию RISC придумали не дураки, и посчитали правильно -- что в CISC-процессорах активно используется от силы 10% команд, а остальные -- эпизодически, вот и решили их выкинуть. Однако на сегодняшний день от их изначальной концепции осталось только выполнение операций исключительно в регистрах, и то есть определённые подвижки для ухода от этого в некоторых специфических случаях: внезапно оказалось, что эти самые редко используемые команды многократно ускоряют выполнение соответствующих классов задач, т. е. отнюдь не бесполезны, если речь идёт о вычислительных системах достаточно высокой производительности, а не минимальной стоимости и потребляемой мощности. Вот и набиты современные типа RISC-процессоры сотнями, а то и тысячами странных и редко используемых команд :) (хотя насколько странных, как EDMK в Системе 360, сейчас, пожалуй, не встречается)
Ну и если б такое управление TLB работало бы действительно хорошо, от него бы, в конечном итоге, не отказались бы, да и использовался бы такой подход намного шире.
Нет, не в курсе; я особо в MIPS не погружался -- так, полистал немного для общего развития, и всё. На практике с ними никогда сталкиваться не приходилось, вот и не углублялся. Но это уже тонкости реализации, а не архитектурно-концептуальный уровень (очевидно, что у современных мэйнфреймов z/Architecture TLB тоже несколько отличается от, скажем, использованного в System 370/145, чья микроархитектура была нами содрана и воплощена в ЕС-1035: там весь TLB аж из восьми (восьми!) элементов состоит, а управляется микропрограммно, насколько помню; однако для программиста эти тонкости совершенно безразличны, ибо на концептуальном уровне TLB ведёт себя одинаково на любых моделях).
Угу. Не столько даже тупиковая -- сделать полноценную ОС с виртуальной памятью и прочим на этом можно, и даже некоторые дополнительные возможности были бы доступны и реализовывались бы дёшево в плане скорости, но очень уж неудобно всё это дело было, поэтому и не прижилось. (Замечу в скобках, что подход IBM -- "нормальная" виртуальная память на основе страниц с "нормальным" MMU плюс архитектурная концепция множества адресных пространств плюс архитектурный же механизм "вызова программы" оказались намного элегантнее и эффективнее, чем Интеловские описатели сегментов и шлюзов вызова, хотя, в первом приближении, позволяют решить одни и те же задачи аппаратными (с точки зрения программиста) средствами, т.е. достаточно быстро -- в отличие от чисто программной реализации путём вызова соответствующих сервисов операционной системы, что всегда очень дорого).
А тем, кто влюбился, показать VAX-11, а потом попросить набросать концепцию суперскалярного процессора этой архитектуры :) Ага, с длиной кода команды от 1 до 36 байт :)))) В PDP-11, по крайней мере, выборку и декодирование команд сделать несложно -- длина хоть и переменная, но количество вариантов ограничено (1, 2 или 3 слова, т. е. 2/4/6 байтов), а однозначно определить её можно анализом первого слова (хотя в Системе 360 и её потомках анализ ещё проще: длину кода команды (тоже 2/4/6 байтов) определяют два старших бита первого байта). Собственно, поэтому мне VAX-11 и не нравится, хотя PDP-11 -- моя любимая 16-разрядная архитектура, а VAX лишь продолжил её идеи: просто DEC решила сделать мощную машину, а концептуальный подход использовала, который был успешным для маленькой и дешёвой машины; естественно, ничего из этого не вышло (VAX-11 получился слишком дорогим, чтоб вытеснить PDP-11 из её ниши, но при этом не имел шансов стать высокопроизводительным, чтоб действительно составить конкуренцию тем же мэйнфреймам IBM).
Честно говоря, не уверен. Что бизнесу нужны готовые специалисты -- это понятно, а Вы как раз в бизнесе и работаете, решаете реальные инженерные задачи. С другой стороны, нельзя подготовить исследователя/учёного, если у него кругозор ограничивается тем, что нужно и эффективно здесь и сейчас. Но это возвращаемся уже к общим проблемам образования -- в частности, к "целеполаганию" в образовании: а кого мы вообще готовим в том или ином учебном заведении? Думается, количество вузов, как я их понимаю, нужно сократить радикально -- раз в 10, а то и больше, -- и они должны готовить именно учёных; ну а для более приземлённых вещей типа обычных программистов или там "вериложников" -- условные техникумы и ПТУ. Ну, думаю, Вы понимаете идею.
Из школьного: вводят производные и интегралы в последних классах на уроках алгебры -- но чисто "сферически в вакууме", и основная масса учеников понятия не имеет, нафиг нужны эти математические извраты. А вводить можно было бы даже раньше, но в рамках физики -- механики, где прекрасно видно, как резко эти извраты упрощают решение многих задач, приближённых к реальности (преобразования между путём-скоростью-ускорением и т.п.). Как по мне, пользы от такого обучения было бы куда больше: и достаточно понятная, очевидная и практически применимая физика, и сразу математический аппарат для её обслуживания.
А мне вспомнился Терри Прачет и его "Народ", где "полуглавная героиня" -- девочка из британской королевской семьи, попавшая на почти необитаемый остров -- в один момент думает, что их (девочек знатного происхождения) учат лишь тому, что точно никогда не пригодится в реальной жизни :)
Мне это такой дикостью показалось: ведь жутко медленно и неэффективно по сравнению с аппаратной выборкой из таблиц переадресации, а последняя -- вещь весьма простая, чтоб на ней усиленно экономить.
Что, уже официально на RISC-V перешли? Я-то от образования далёк, поэтому не в теме, что там и как -- только по книжкам что-то вижу.
Но говорил я больше о том, что давать глубоко надо, конечно, современное, но упомянуть неплохо бы и существовавшие некогда другие подходы -- для общего развития, так сказать, но без траты сколько-нибудь значительного времени на это дело (кто заинтересуется историей -- сам найдёт, ему достаточно ключевые слова подсказать).
А я б про кэши и таблицы страниц рассказал бы в 16-17 лет, когда познакомился с этим на реальном железе... В общем, если человеку интересна некая тема, он и сам её изучает, а если неинтересна -- никакой вуз не поможет (и вопрос только в том, а нафига такой человек в вузе?)
Строго говоря, не обязательно, хотя во всех современных архитектурах, думается, это именно так. Навскидку из отличающихся "исторических" архитектур:
80286 с его теневыми регистрами для сегментов (хотя, подобно TLB, теневые сегментные регистры хранят информацию, полученную из таблиц в памяти, но, в отличие от TLB, это не "кэш" в том смысле, что каждый теневой регистр обновляется процессором не "по собственному желанию", а в строго определённый момент -- когда выполняется загрузка соответствующего сегментного регистра, т.е. по прямому указанию программиста). В IA-32 теневые регистры сохранены, но там появился уже и нормальный TLB, поскольку появилась нормальная страничная организация памяти;
PDP-11, где преобразование адресов основано на регистрах MMU: из-за малого объёма виртуального адресного пространства (64 Кбайта) нужды в таблицах переадресации, расположенных в ОЗУ, нет, и всё необходимое лежит прямо в MMU; соответственно, нужды в TLB тоже нет.