Это, кстати, не всегда эффективно. Скажем, одной из причин, хотя и далеко не основной, очень значительного (в 4-6 раз) повышения производительности процессора ЕС-1022 по сравнению с ЕС-1020 является то, что в нём есть два параллельно работающих пути данных: через АЛУ и прямая передача мимо АЛУ, что позволяет в одной микрокоманде совмещать часто используемые пересылки с вычислениями, а не разносить их по разным тактам. Хотя, понятно, по количеству логики такое устройство затратнее.
Но, вроде б, более простые драйвера, если они были полностью корректно написаны под WDM от 2000-й, должны работать и в современной винде (скорей всего, с перекомпиляцией исходников, но без переписывания) -- хотя могу и ошибаться, под Винду уже давно не пишу, поэтому и не слежу особо. А вот у Линуха как новая большая версия ядра, так обязательно что-то внутриядерное выпилят, из-за чего просто так не обновишься.
А ещё можно сделать ради собственного удовольствия :) Ну или как прототип будущей заказной микросхемы. Или как железный эмулятор древнего компа -- но с последним не всегда получится в лоб. Скажем, проц от СМ-1420 для симуляции в какой-нить там Квесте перевести на Верилог можно, а вот для синтеза в ПЛИС без существенных переделок -- фигвам: там и двунаправленные шины с открытым коллектором или с тремя состояниями, и куча одновибраторов, длительность импульсов которых задаётся RC-цепочками... И несколько ошибок, и реальный проц работает только потому, что в схемотехнике ТТЛ они оказались некритичными :)
А мне и 1, и 2, и 3, и 4 герои понравились: у каждого свои достоинства и недостатки. Но 4 был таки достаточно сырым и не доведённым до ума -- кажись, контора благополучно банкротилась, поэтому и пустили в продажу недоделку.
Этому требованию отвечает, в частности, система функций ⟨∧,⊕,1⟩ (конъюнкция, сложение по модулю два, константа 1). На её основе и строятся полиномы Жегалкина.
Как видим, эти полиномы содержат функции AND и XOR, а не одну только XOR. Речь же о возможности создания любой логики на одном типе логических элементов.
Ну, на ПЛИС примерно такое обычно и синтезируется: несколько отдельных блоков для сложения, И, ИЛИ и т.п., а на выходе -- мультиплексор для выбора результата. Реализовать ручками ускоренный перенос можно, но он будет, скорей всего, работать медленнее последовательного, т.к. для последовательного переноса у ПЛИСины имеется специально для этого выделенная связь и всё такое прочее, максимально оптимизированные по скорости, а ускоренный придётся делать обычной логикой и разводить обычной медленной коммутацией через 100500 невидимых мультиплексоров. Вот в заказной микросхеме или на рассыпухе -- другое дело.
Нет, RS-триггер, в отличие от действительно комбинационной логики, запоминает своё состояние. Да, оно устанавливается определённой комбинацией на его входах, но в дальнейшем поддерживается триггером самостоятельно, пока он не будет переключён в другое состояние. Ну а комбинационная логика ничего в принципе не хранит -- в том и различие.
Сейчас RS-триггеры действительно почти не используются, как не используются и защёлки -- везде сплошь флип-флопы, а вот "в древности" -- строго наоборот: защёлки и RS устроены существенно проще, а когда тебе каждый триггер надо собирать на логических элементах, ты начинаешь заботиться о количестве корпусов микросхем :) Ну и, кроме того, в крупных схемах с протяжёнными связями возникают проблемы с разводкой синхронизации, и там нередко проще и целесообразнее сделать многофазную синхронизацию и использовать защёлки, а не делать однофазную и использовать флип-флопы.
В ПЛИС использовать можно и то, и другое, но, во-первых, флип-флопы у тебя "бесплатны" (нет смысла экономить: они всё равно реализованы), а во-вторых, ПО не умеет правильно считать задержки и прочая при использовании защёлок, поэтому обеспечение правильной синхронизации становится задачей разработчика (с флип-флопами считать намного проще из-за того, что они меняют своё состояние лишь в момент фронта/спада тактового импульса).
Кстати, с биполярными транзисторами всё хитрее. Вроде бы, на уровне физики они тоже управляются напряжением, но для практических расчётов удобнее считать, что током, почему так и считают. Впрочем, в этом вопросе не поклянусь, сам разбирался, как оно работает, ещё школьником, а это было 100500 лет назад :)
В первом приближении -- да. Впервые разделение на архитектуру (представление машины с точки зрения программиста) и реализацию ввела IBM в Системе 360, но микроархитектуру тогда ещё не придумали, т.е. не отделили её от физической реализации. Микроархитектура -- это, скорей, нечто промежуточное между архитектурой и физическим воплощением: логическое внутреннее устройство процессора, но без жёсткой привязки к "железу". Скажем, можно взять какой-нибудь интеловский проц (официально они называют современную архитектуру Intel 64 -- не брать же название AMD64 :) , а её 32-разрядного предка -- IA-32, хотя в "разговорной речи" обычно все говорят об x86) какой-нибудь определённой микроархитектуры, скажем, Sandy Bridge, но реализовать его по иным технологическим нормам (не 22 нм или сколько там было в нём, а, скажем, 7 нм). Понятно, что физически реализация уже будет другой, но если в "схемы" (реально -- в исходные тексты на Верилоге или ещё каком языке описания аппаратуры) никаких изменений не вносили, то микроархитектура останется прежней (а архитектура -- и подавно).
Не умеют чётко ограничивать "сферы ответственности" и т.д. В частности, жутко переусложняют "ядерный" API, впихивая туда 100500 функций, хотя можно было бы обойтись малым количеством достаточно низкоуровневых системных вызовов, а всё остальное, если нужно, делать на уровне библиотек режима пользователя. В какой-то мере Win32 API так и построена: в ней же во много раз больше функций, чем представляет собственно ядро Винды.
А ещё гарвардская архитектура предполагает не просто отдельные шины для доступа к коду и данным, а принципиально разные адресные пространства -- т.е. численно одинаковый адрес означает разные ячейки памяти в зависимости от того, относится он к коду или данным. Соответственно, данные в области кода либо не могут располагаться вовсе, либо для доступа к ним нужны специальные команды, а не обычные, оперирующие с данными в памяти данных. Современный пример -- архитектура AVR8. Но подавляющее количество архитектур -- фон-неймановские, где нет принципиального отделения пространств кода и данных (даже если в физической реализации они на некотором уровне разнесены, как это происходит с кэшами первого уровня современных процов).
Вообще, очень много проблем возникает из-за неряшливого обращения с терминами, и "архитектура" здесь одна из наиболее пострадавших. Вон, кажись, вчера мелькала статейка про то ли интеловские, то ли АМДшные процы, где архитектуру использовали вместо микроархитектуры. Так и с гарвардской/фон-неймановской получилось: смотрят на некий простой формальный признак, а не на суть этих понятий.
Ну, вообще-то, даже полевых транзисторов отнюдь не два типа, а ведь есть ещё и биполярные, на которых строились все машины средней и высокой производительности вплоть до конца 1980-х. Понятно, что описывать их все в подобной статье смысла нет, но хотя б упомянуть, что мир этим не исчерпывается, стоило бы.
Реализация АЛУ тоже... скажем так, типична для ПЛИС, но не шибко эффективна: много лишней логики получается. Можно сравнить, например, с устройством классического АЛУ SN74181, а заодно разобраться в ограничениях по скорости из-за переносов и как они могут быть смягчены в реальных схемах.
Писал. Проблем не было. Как и постоянных несовместимых изменений внутри самого ядра, делающих непригодными драйверы для предыдущих версий системы. (Ну ладно, драйверную модель для видюх таки перепилили при переходе от ХП к Висте, так что, надо полагать, драйвер для ХП не пойдёт на более поздних системах -- хотя не уверен, так как в них не вникал; но для видюх, по крайней мере, таки имелись веские технические основания: из всех устройств именно они сильней всего изменились, не говоря о том, что ныне они являются самыми сложными устройствами -- это не УАРТ и даже не хост-контроллер УСБ).
Работа в браузере -- не показатель, ибо очень сильно зависит от скорости передачи данных, т.е. от внешних факторов.
Сама по себе система работала, с точки зрения пользователя, примерно с такой же скоростью, что и современные версии, однако железо-то было во много-много-много раз слабее.
Стоило б отметить, что, во-первых, Система 370 и не должна была стать революционной -- это развитие Системы 360, сохраняющее с ней совместимость. А во-вторых, эта линейка развивается и по сей день, и современные мэйнфреймы z/Architecture -- далёкие потоки Системы 360, сохраняющие с ней совместимость на уровне прикладного кода, что делает эту линейку архитектур самой старой из не утративших актуальность.
Давайте разберем локомотив в качестве примера. Хотя двигатель поезда имеет округлые поверхности и довольно сложные формы, он фактически собран из 762 тысяч плоских треугольников, используя 382 000 вершин и 9 различных материалов/цветов, нанесенных на поверхности треугольников.
Вы утверждаете, что в присутствующем в кадре одном цилиндре паровой машины -- а именно она является двигателем паровоза -- имеется 762 тысячи треугольников? Мне вот кажется, что эта величина относится ко всему локомотиву, который на английском называется "steam engine" -- точно так же, как и собственно паровая машина.
Это, кстати, не всегда эффективно. Скажем, одной из причин, хотя и далеко не основной, очень значительного (в 4-6 раз) повышения производительности процессора ЕС-1022 по сравнению с ЕС-1020 является то, что в нём есть два параллельно работающих пути данных: через АЛУ и прямая передача мимо АЛУ, что позволяет в одной микрокоманде совмещать часто используемые пересылки с вычислениями, а не разносить их по разным тактам. Хотя, понятно, по количеству логики такое устройство затратнее.
Но, вроде б, более простые драйвера, если они были полностью корректно написаны под WDM от 2000-й, должны работать и в современной винде (скорей всего, с перекомпиляцией исходников, но без переписывания) -- хотя могу и ошибаться, под Винду уже давно не пишу, поэтому и не слежу особо. А вот у Линуха как новая большая версия ядра, так обязательно что-то внутриядерное выпилят, из-за чего просто так не обновишься.
А ещё можно сделать ради собственного удовольствия :) Ну или как прототип будущей заказной микросхемы. Или как железный эмулятор древнего компа -- но с последним не всегда получится в лоб. Скажем, проц от СМ-1420 для симуляции в какой-нить там Квесте перевести на Верилог можно, а вот для синтеза в ПЛИС без существенных переделок -- фигвам: там и двунаправленные шины с открытым коллектором или с тремя состояниями, и куча одновибраторов, длительность импульсов которых задаётся RC-цепочками... И несколько ошибок, и реальный проц работает только потому, что в схемотехнике ТТЛ они оказались некритичными :)
А мне и 1, и 2, и 3, и 4 герои понравились: у каждого свои достоинства и недостатки. Но 4 был таки достаточно сырым и не доведённым до ума -- кажись, контора благополучно банкротилась, поэтому и пустили в продажу недоделку.
А вот 5 -- неа, не то-с, не зашло совсем.
Цитирую Вику:
Этому требованию отвечает, в частности, система функций ⟨∧,⊕,1⟩ (конъюнкция, сложение по модулю два, константа 1). На её основе и строятся полиномы Жегалкина.Как видим, эти полиномы содержат функции AND и XOR, а не одну только XOR. Речь же о возможности создания любой логики на одном типе логических элементов.
Можно построить один XOR из четырёх NAND, а вот наоборот...
Ну, на ПЛИС примерно такое обычно и синтезируется: несколько отдельных блоков для сложения, И, ИЛИ и т.п., а на выходе -- мультиплексор для выбора результата. Реализовать ручками ускоренный перенос можно, но он будет, скорей всего, работать медленнее последовательного, т.к. для последовательного переноса у ПЛИСины имеется специально для этого выделенная связь и всё такое прочее, максимально оптимизированные по скорости, а ускоренный придётся делать обычной логикой и разводить обычной медленной коммутацией через 100500 невидимых мультиплексоров. Вот в заказной микросхеме или на рассыпухе -- другое дело.
Нет, RS-триггер, в отличие от действительно комбинационной логики, запоминает своё состояние. Да, оно устанавливается определённой комбинацией на его входах, но в дальнейшем поддерживается триггером самостоятельно, пока он не будет переключён в другое состояние. Ну а комбинационная логика ничего в принципе не хранит -- в том и различие.
Сейчас RS-триггеры действительно почти не используются, как не используются и защёлки -- везде сплошь флип-флопы, а вот "в древности" -- строго наоборот: защёлки и RS устроены существенно проще, а когда тебе каждый триггер надо собирать на логических элементах, ты начинаешь заботиться о количестве корпусов микросхем :) Ну и, кроме того, в крупных схемах с протяжёнными связями возникают проблемы с разводкой синхронизации, и там нередко проще и целесообразнее сделать многофазную синхронизацию и использовать защёлки, а не делать однофазную и использовать флип-флопы.
В ПЛИС использовать можно и то, и другое, но, во-первых, флип-флопы у тебя "бесплатны" (нет смысла экономить: они всё равно реализованы), а во-вторых, ПО не умеет правильно считать задержки и прочая при использовании защёлок, поэтому обеспечение правильной синхронизации становится задачей разработчика (с флип-флопами считать намного проще из-за того, что они меняют своё состояние лишь в момент фронта/спада тактового импульса).
Кстати, с биполярными транзисторами всё хитрее. Вроде бы, на уровне физики они тоже управляются напряжением, но для практических расчётов удобнее считать, что током, почему так и считают. Впрочем, в этом вопросе не поклянусь, сам разбирался, как оно работает, ещё школьником, а это было 100500 лет назад :)
Ну, скажем, Cortex-M1 и Cortex-M3 написаны на Верилоге (исходники есть). Вряд ли другие ядра они писали на чём-то другом.
В первом приближении -- да. Впервые разделение на архитектуру (представление машины с точки зрения программиста) и реализацию ввела IBM в Системе 360, но микроархитектуру тогда ещё не придумали, т.е. не отделили её от физической реализации. Микроархитектура -- это, скорей, нечто промежуточное между архитектурой и физическим воплощением: логическое внутреннее устройство процессора, но без жёсткой привязки к "железу". Скажем, можно взять какой-нибудь интеловский проц (официально они называют современную архитектуру Intel 64 -- не брать же название AMD64 :) , а её 32-разрядного предка -- IA-32, хотя в "разговорной речи" обычно все говорят об x86) какой-нибудь определённой микроархитектуры, скажем, Sandy Bridge, но реализовать его по иным технологическим нормам (не 22 нм или сколько там было в нём, а, скажем, 7 нм). Понятно, что физически реализация уже будет другой, но если в "схемы" (реально -- в исходные тексты на Верилоге или ещё каком языке описания аппаратуры) никаких изменений не вносили, то микроархитектура останется прежней (а архитектура -- и подавно).
Не умеют чётко ограничивать "сферы ответственности" и т.д. В частности, жутко переусложняют "ядерный" API, впихивая туда 100500 функций, хотя можно было бы обойтись малым количеством достаточно низкоуровневых системных вызовов, а всё остальное, если нужно, делать на уровне библиотек режима пользователя. В какой-то мере Win32 API так и построена: в ней же во много раз больше функций, чем представляет собственно ядро Винды.
А ещё гарвардская архитектура предполагает не просто отдельные шины для доступа к коду и данным, а принципиально разные адресные пространства -- т.е. численно одинаковый адрес означает разные ячейки памяти в зависимости от того, относится он к коду или данным. Соответственно, данные в области кода либо не могут располагаться вовсе, либо для доступа к ним нужны специальные команды, а не обычные, оперирующие с данными в памяти данных. Современный пример -- архитектура AVR8. Но подавляющее количество архитектур -- фон-неймановские, где нет принципиального отделения пространств кода и данных (даже если в физической реализации они на некотором уровне разнесены, как это происходит с кэшами первого уровня современных процов).
Вообще, очень много проблем возникает из-за неряшливого обращения с терминами, и "архитектура" здесь одна из наиболее пострадавших. Вон, кажись, вчера мелькала статейка про то ли интеловские, то ли АМДшные процы, где архитектуру использовали вместо микроархитектуры. Так и с гарвардской/фон-неймановской получилось: смотрят на некий простой формальный признак, а не на суть этих понятий.
Ну, вообще-то, даже полевых транзисторов отнюдь не два типа, а ведь есть ещё и биполярные, на которых строились все машины средней и высокой производительности вплоть до конца 1980-х. Понятно, что описывать их все в подобной статье смысла нет, но хотя б упомянуть, что мир этим не исчерпывается, стоило бы.
Реализация АЛУ тоже... скажем так, типична для ПЛИС, но не шибко эффективна: много лишней логики получается. Можно сравнить, например, с устройством классического АЛУ SN74181, а заодно разобраться в ограничениях по скорости из-за переносов и как они могут быть смягчены в реальных схемах.
Писал. Проблем не было. Как и постоянных несовместимых изменений внутри самого ядра, делающих непригодными драйверы для предыдущих версий системы. (Ну ладно, драйверную модель для видюх таки перепилили при переходе от ХП к Висте, так что, надо полагать, драйвер для ХП не пойдёт на более поздних системах -- хотя не уверен, так как в них не вникал; но для видюх, по крайней мере, таки имелись веские технические основания: из всех устройств именно они сильней всего изменились, не говоря о том, что ныне они являются самыми сложными устройствами -- это не УАРТ и даже не хост-контроллер УСБ).
Работа в браузере -- не показатель, ибо очень сильно зависит от скорости передачи данных, т.е. от внешних факторов.
Сама по себе система работала, с точки зрения пользователя, примерно с такой же скоростью, что и современные версии, однако железо-то было во много-много-много раз слабее.
Дык не было всяких мало кому нужных служб и т.п., запускаемых в обязательном порядке; про шпионские модули я уж молчу.
Использовал её на своём первом собственном компе, пока не появилась Вынь-2000. 95/98 только на работе использовались.
Стоило б отметить, что, во-первых, Система 370 и не должна была стать революционной -- это развитие Системы 360, сохраняющее с ней совместимость. А во-вторых, эта линейка развивается и по сей день, и современные мэйнфреймы z/Architecture -- далёкие потоки Системы 360, сохраняющие с ней совместимость на уровне прикладного кода, что делает эту линейку архитектур самой старой из не утративших актуальность.
Цитирую:
Вы утверждаете, что в присутствующем в кадре одном цилиндре паровой машины -- а именно она является двигателем паровоза -- имеется 762 тысячи треугольников? Мне вот кажется, что эта величина относится ко всему локомотиву, который на английском называется "steam engine" -- точно так же, как и собственно паровая машина.