Насчёт быстродействия. Если делать отдельный аппаратный блок для десятичных операций, он будет либо работать медленнее, чем аналогичный двоичный блок, либо будет существенно сложней (и не факт, что такой же быстрый: усложнение железа нередко его замедляет, хотя есть нюансы :) ). Но это уже переход на уровень схемотехники.
Реально десятичные вещественные реализованы в z/Architecture. Основная польза от них, как представляется, не для научных расчётов, а для финансов -- раньше там использовались тоже десятичные числа, но целые переменной длины (1-31 цифра плюс знак), что было реализовано ещё в Системе 360 и благополучно дожило до наших дней.
В финансах десятичная система удобней, в частности, из-за того, что все правила округления и т.п. при расчётах вырабатывались веками и именно для десятичной системы, и, чтобы им следовать, считая в двоичной, приходится принимать специальные меры. Для научных расчётов этого не требуется: там результаты практически всегда не точные, а приблизительные, и важно лишь то, какая точность достигается, а не конкретные правила (в отличие от финансов, где считать надо только так, как это установлено регулирующими документами).
В общем, в той же z/Architecture двоичные и десятичные будут благополучно сосуществовать и дальше, а вот внедрение десятичных (хоть целых, хоть вещественных) в другие архитектуры представляется довольно сомнительным, не смотря на определённые выгоды от них в некоторых задачах.
На уровне принципиальных схем -- да. На уровне функциональных -- нет, там удобней логическое наличие/отсутствие сигнала, а не конкретные логические уровни. Сейчас-то всё пишут на языках (VHDL, Verilog и иже с ними), а в эпоху ручной "рассыпухи" было весьма актуально.
И ни слова об участии Польши в создании ЕС и СМ ЭВМ вместе с другими странами соцлагеря. В частности, поляки выкатили, судя по имеющейся информации, весьма удачную ЕС-1032; они же производили прекрасные терминалы СМ-7209.
Давайте скрин или ссылку по которой это ясно не только лично Вам.
Например, вот один из моих постов выше по ветке, где ясно видно, что разница между гарвардской и фон-неймановской архитектурами проявляется и важна для программиста (на примере Ардуины):
Принципиальное отличие гарвардской архитектуры от фон-неймановской -- наличие двух независимых адресных пространств для кода и для данных, из-за чего численно одинаковый адрес вызывает обращение к разным ячейкам памяти в зависимости от того, используется ли он для доступа к коду или данным. Из современных действительно гарвардских архитектур, пожалуй, самая известная -- это AVR8 (благодаря Ардуине); в частности, в ней для доступа к константам, записанным во флэш-памяти, т.е. в памяти кода, пришлось ввести специальные команды, а не обычные, работающие с данными в ОЗУ.
Обычные же процы все поголовно являются фон-неймановскими, и разделение кэшей не делает их гарвардскими: обращение по одному и тому же адресу вызовет доступ к одной и той же ячейке памяти независимо от того, где она кэширована (как это будет реализовано технически -- второй вопрос). Правда, их нередко называют "модифицированными гарвардскими" или чем-то подобным, но лишь вносят лишнюю путаницу: с точки зрения программиста это фон-неймановские архитектуры, а что у них там внутри, программиста вообще не касается (а вот на настоящих гарвардских перед программистом появляется ряд дополнительных проблем; можете попробовать для интереса на той же Ардуине использовать printf("abc") и char S[] = "abc"; printf(S) -- сразу увидите разницу).
Какая разница? Грубость Вы допуcтили тут. Вот в этом обсуждении. И если Вы, когда писали в IBM, тоже употребляли слова "быдлоиндус" и "безграмотно", то удивительно, что Вам вообще ответили. Или Вы грубите только за глаза?
Когда я писал и в ARM, и в IBM, я использовал обычный деловой стиль. Разница в том, что IBM ответила и исправила ошибки, а ARM полностью проигнорировала обращение.
А грубость -- да, допустил и буду допускать дальше. Если человек дурак, я так и говорю, а не занимаюсь политкорректными изысканиями на тему "альтернативной одарённости".
3) А где я это утверждал? Я лишь ответил на вопрос:
А если и д'Артаньян, то что с того?
Вообще-то такой ответ отнюдь не говорит о том, что я считаю себя непогрешимым. Я указал на фактическую ошибку в официальной документации -- и эта ошибка остаётся ошибкой независимо от моей личности (точно так же, как Земля вертится независимо от личностей Кеплера, инквизиторов и прочая).
Я со ссылками доказал оспариваемое Вами моё утверждение в первом комментарии, что введение термина "модифицированная/гибридная/расширенная Гарвардская архитектура" внесло путаницу.
Вернёмся к Вашему утверждению, на которое Вы здесь сослались. Чтоб не бегать по комментариям туда-сюда, процитирую его здесь.
Во многих современных CPU общего назначения разделены кеш данных и кеш инструкций. Получается, внутри CPU гарвардской архитектуры (физически инструкции и данные в разной памяти и доступ к ним по разным каналам), а снаружи - фон Неймановской. Оттуда и путаница.
На самом деле, здесь несколько утверждений.
1) "Во многих современных CPU общего назначения разделены кеш данных и кеш инструкций" -- да, это верно. Более того, не обязательно разделены кэши: например, у целого ряда процессорных ядер ARM предусмотрено подключение к ядру через отдельные порты так называемой тесно связанной памяти команд и данных (ITCM и DTCM), которая является именно памятью, а не кэшем.
2) "Получается, внутри CPU гарвардской архитектуры (физически инструкции и данные в разной памяти и доступ к ним по разным каналам)" -- а вот здесь верно лишь отчасти. Доступ действительно по разным каналам (портам, шинам), но:
Если речь идёт о кэше, то он -- не память в том смысле, в каком была память в первых фон-неймановских и гарвардских компьютерах, откуда термины и пошли: кэш не является "истинным хранилищем", а лишь буфером, ускоряющим доступ, о чём Вы, по сути, говорите чуть далее. В случае DTCM/ITCM, однако, это будет именно что память, а не буфер.
Внутри процессор всё равно не является гарвардским. В случае с кэшами, если идёт обращение к коду, он обратится к кэшу команд, заполнив его, при необходимости, из настоящей памяти (нередко -- через промежуточные общие кэши). В случае обращения к данным он обращается к кэшу данных -- но заполняет его из той же самой памяти, используя те же самые адреса, и поэтому, в отличие от настоящего гарвардского компьютера, этот процессор может использовать одну и ту же ячейку памяти и для кода, и для данных, причём в буквальном смысле одновременно.
В случае DTCM/ITCM (об этом Вы не писали -- возможно, и не знали, но для полноты картины этот вопрос всё равно надо рассмотреть), на первый взгляд, ситуация всё-таки соответствует именно гарварской архитектуре. Но стоит бросить второй взгляд, и тогда будет видно, что (а) процессор может выбирать данные из ITCM и записывать информацию в ITCM, а не только в DTCM, для чего в ядре имеется соответствующая коммутация -- соответственно, ITCM работает и как память данных; (б) ITCM и DTCM не обязательны к реализации, а когда имеются, могут быть отключены программно, и тогда доступы по их адресам будут отправлены на общую шину, к которой подключена общая память (и разная периферия). Отсюда видно, что процессорное ядро даже с подключёнными к нему ITCM и DTCM ведёт себя как фон-неймановский компьютер, а не как гарвардский.
3) "а снаружи - фон Неймановской" -- согласен, но добавлю несколько слов чуть ниже.
4) "Оттуда и путаница." -- абсолютно согласен.
А теперь добавка.
Путаницу создаёте в том числе и Вы, из-за чего я написал свой пост в ответ на данный Ваш пост. Если бы Вы написали "Получается, внутри CPU модифицированной гарвардской архитектуры..." -- всё было бы нормально, но Вы не написали "модифицированной". А ведь просто гарвардская архитектура вызывает "несовместимость" адресных пространств кода и данных -- а этого нет, о чём Вы и говорите позже ("а снаружи - фон Неймановской"). Так что изначально моя претензия к Вам связана именно с использованием неправильного термина -- та же самая история, что и в цитированном Вами TRM на ARM9TDMI. (Термин "модифицированная гарвардская" мне не нравится, так как вызывает ненужные ассоциации с просто "гарвардской" и этим провоцирует путаницу -- но о терминах не спорят, а договариваются, но, договорившись, надо придерживаться терминологии, а с этим хронические проблемы).
Кстати, в том TRM есть такие пассажи:
The ARM9TDMI has a Harvard bus architecture with separate instruction and data interfaces....
...
For system purposes, it is normally necessary to provide some mechanism whereby the data interface can access instruction memory...
...
A typical implementation of an ARM9TDMI-based cached processor has Harvard caches and a unified memory structure beyond the caches...
Т.е. в реальности речь идёт о полноценном фон-неймановском компьютере, вместо которого при желании можно сделать частично гарвардский, а отнюдь не о "жёстко" и безальтернативно гарвардском -- но автор этого TRM ни разу не упомянул ни "von Neumann", ни "modified Harvard" (что было бы корректно), а только просто "Harvard" (что некорректно). Поскольку это не беседа в курилке и даже не чат, а официальный документ, я делаю вывод, что автор либо безграмотен (не видит разницы между "гарвардом" и "модифицированным гарвардом"), либо наплевательски относится к выполнению своей работы (не придерживается точной терминологии).
Кстати, сама архитектура ARM допускает как фон-неймановскую, так и гарвардскую реализацию, что прекрасно видно из документа ARM DDI 0100I "ARM Architecture Reference Manual". Однако она не предполагает именно гарвардскую реализацию и, более того, не делит адресные пространства на код и данне, что обязательно имеет место в настоящих гарвардских архитектурах вроде AVR8 (или собственно первых гарвардских компьютеров, давших название архитектуре). Просто возможна реализация, где не из любой области памяти можно выполнять команды или не к любой области памяти можно обращаться как к данным. И если реализации с памятью "только для данных", наверное, встречались на практике, то вот реализации "только код" крайне сомнительны, ведь тогда пропадёт возможность использования так называемых "литеральных пулов" -- констант, размещённых рядом с командами и адресуемых относительно счётчика команд, а без этого весьма неудобно при программировании на ассемблере и вовсе невозможно при использовании компиляторов с языков высокого уровня. Думаю, можно смело утверждать, что настоящих, "жёстких" гарвардских компьютеров на базе архитектуры ARM попросту нет, имеются лишь некоторые реализации, ограничивающие возможность размещения кода в произвольных областях памяти, что не требуется архитектурой, а является особенностью этих конкретных реализаций.
И если лично для себя Вы эту путаницу решили за счет игнорирования схемотехники, то консенсуса в сообществе это создать не может, так как сначала разрабатывается схемотехника. И именно создатели схемотехники вводят терминологию.
Начиная, по меньшей мере, с Системы 360, сначала разрабатывается архитектура, т.е. система команд, правила обработки прерываний и т.д. и т.п., и лишь затем реализация, включая схемотехнику.
Терминология же должна, вообще говоря, стандартизироваться -- и только в таком случае можно указывать тексты стандартов или иных нормативных документов как авторитетные источники. Но, кажется, Вы сами где-то выше говорили, что внести порядок в использование терминологии комитеты по стандартизации даже не пытались. Так что, простите, единственным авторитетным источником в такой ситуации может быть только анализ происхождения термина и его связь с описываемыми им явлениями -- а при таком анализе станет ясно, что процессоры "модифицированной гарвардской архитектуры" на практике ведут себя как фон-неймановские (исполняют код и обеспечивают доступ к данным в одних и тех же ячейках памяти), а не как гарвардские (строго разделяют хранилища кода и хранилища данных), а соответственно, опускать слово "модифицированная" недопустимо, что, однако, нередко делают -- как сделали в процитированном Вами документе от ARM.
В общем, "фон-неймановская" и "гарвардская" архитектуры, хотя и пошли изначально от реализации (в первом приближении -- схемотехники) конкретных вычислительных машин 1940-х годов, влияют на видение машины со стороны программиста (единое или разные адресные пространства кода и данных). А вот "модифицированная гарвардская" архитектура относится только к уровню микроархитектуры и реализации (опять-таки, в первом приближении -- к схемотехнике) и не влияет на наблюдаемое программистом "глобальное" поведение машины (при условии, конечно, что программист соблюдает требования архитектуры по, например, использованию самомодифицирующегося кода: в IA-32 или Системе 370 никаких действий ему предпринимать не надо, а вот в ARM требуется выполнить барьеры данных и команд, чтобы гарантировать учёт внесённых изменений).
1) Из контекста ясно, что речь идёт о некотором ограниченном круге лиц -- о программистах (поскольку для программиста есть разница, можно ли обращаться к данным в произвольных областях памяти или такой разницы нет -- сравните на Ардуине поведение printf("abc") и printf(S), где S -- массив в оперативе).
2) Я писал в ARM -- реакция была нулевой. Приходилось мне писать и в IBM по поводу ошибок в z/Architecture Principles of Operations -- там отвечали, а замеченные ошибки исправляли в последующих версиях данного документа.
3) Где я утверждаю, что я непогрешим? Это Вы мне приписываете непогрешимость.
1) Я где-то утверждаю, что что-то существенно или несущественно для схемотехники? Кажется, я утверждаю лишь то, что разделение на фон-неймановскую и гарвардскую (без всякой "модифицированной") существенно для программиста, а схемотехники вообще не касаюсь.
2) Я указал на фактическую ошибку, допущенную автором конкретного документа: он написал, что архитектура гарвардская (не "модифицированная гарвардская", а просто "гарвардская"), в то время как архитектура ARM не предполагает разделения на кода и данных и не реализует его, включая указанное ядро ARM9TDMI.
3) А если и д'Артаньян, то что с того? Это не я ошибку в документации допустил. Кстати, ARM её несколько раз повторяет в разных документах -- т.е. часть документации (а именно,TRM) там пишут люди, не видящие разницы между "гарвардской" и "модифицированной гарвардской".
А когерентность кэшей к "модифицированной гарвардской" вообще не относится, по большому счёту. Скажем, у мэйнфреймов IBM -- если не с Системы 360, то с Системы 370 точно -- есть чётко прописанные в руководстве по архитектуре критерии, которые аппаратура обеспечивает, при этом, естественно, сама архитектура не навязывает способ реализации. Например, самомодифицирующийся код автоматом учитывается процессором, на котором он выполняется (т.е. можно выполнить запись буквально следующей выполняемой команды -- и процессор обязан исполнить уже модифицированную команду). Однако изменения, вносимые в память другими процессорами или подсистемой ввода-вывода (каналами), могут оставаться неучтённым до тех пор, пока не произойдёт сериализация (она всегда происходит при прерываниях, а также в ряде других строго обозначенных случаев, но может происходить и чаще; в частности, если у машины в принципе нет никаких кэшей и буферов, это логически эквивалентно непрерывно выполняемой сериализации).
Понятно, что современные мэйнфреймы z/Architecture являются "модифицированными гарвардскими", т. е. с радельными кэшами команд и данных -- но архитектурно они как были фон-нейманами, так и остались, и ведут себя, с точки зрения программиста, так же, как вели себя их предки их 1970-х годов. В плане сериализации добавилось пару моментов для повышения общей эффективности. Скажем, в Системе 370 команды сравнения и обмена (CS и CDS) выполняли принудительную полную сериализацию, что требовало переписи всех изменённых строк кэшей в основную память (ОП; термин ОЗУ там исторически не используется, а никакой другой памяти у машины, с точки зрения программиста, нет -- ну, не считая "внешней памяти" в виде дисков и лент, конечно) и последующей полной очистки всех кэшей, чтобы учесть изменения в ОП, которые могли быть внесены другими процессорами или каналами. В z/Architecture эти команды ведут себя точно так же (обеспечение совместимости!), но появился ряд других команд, которые выполняют лишь "узкую" сериализацию -- гарантируют запись изменений из кэшей и последующую загрузку актуального содержимого ОП только для тех ячеек памяти, к которым эти команды обращаются (чем достигается повышение производительности: не всегда требуется полная сериализация, и какой способ выбрать, определяет программист).
И я про то же говорю. Фон-неймановская и просто гарвардская относятся... ну, к архитектуре -- т.е. к самим принципам функционирования процессора/компьютера с точки зрения программиста (предусматривает ли архитектура жёсткое разделение на код и данные или же не проводит различия между ними). А "модифицированная гарвардская" -- это чисто про реализацию, с точки зрения не программиста, а разработчика процессора.
1) Как уже отметил другой товарищ, пользователем процессора является программист, и для него между фон-неймановской и гарвардской архитектурой есть только одно принципиальное различие -- единые или разные адресные пространства для кода и данных.
2) Я пишу о разнице фон-неймановской и гарвардской архитектуры, о гарвардской говорит и обсуждаемая изначально статья. О "модифицированной гарвардской" я написал лишь то, что этот термин вносит дополнительную путаницу; я нигде не утверждал, что "модифицированная гарвардская" архитектура вводит разные адресные пространства для кода и данных (тем самым не давая возможность использовать один и тот же адрес и для кода, и для данных в разных ситуациях). Так что попрошу не передёргивать.
3) Вам нужны ссылки -- ищите историю появления гарвардской архитектуры и почитайте, как работали первые компьютеры, построенные на ней. Именно на них различие с фон-неймановской и проявилось во всей красе.
4) Вы привели цитату из ARM9TDMI про "гарвардскую архитектуру" -- не "модифицированную", а просто "гарвардскую". Однако это ядро, как в целом вся без исключения архитектура ARM (конкретно это ядро относится к версии ARMv5T, если не изменяет память), является фон-неймановской архитектурой, допускающей исполнение кода и чтение-запись данных из одной и той же памяти, а не гарвардской, строго разграничивающей адресные пространства. Автор документа -- как раз тот самый быдлоиндус, безграмотно использующий термины, и реальная авторитетность данного источника в плане терминологии равна нулю (она ненулевая в плане описания особенностей реализации ядра).
Моя личная интерпретация как раз и отражает единственнуюсущественную разницу между гарвардской архитектурой и фон-неймановской, а приведённая Вами цитата лишь запутывает картину, цепляясь к техническим подробностям и упуская из вида главное. Вспомните о том, что эти самые "separate storage and signal pathways for instructions and data" для фон-неймановских процессоров (которые, если не ошибаюсь, Вы склонны называть гарвардскими или модифицированными гарвардскими) имеют место только между ядром и кэш-памятью первого уровня; в последующих кэшах и тем более в собственно памяти разделения на код и данные у фон-неймановских процессоров нет. Ну и сравните это с настоящими гарвардскими архитектурами, например, с AVR8, где команды и данные хранятся в разных модулях памяти, которые между собой вообще не пересекаются по адресам (и для выборки данных из памяти команд нужны специальные команды, отличающиеся от команд, работающих с памятью данных).
Насчёт STM8 я не в курсе -- не сталкивался с ними. Ну а если кто-то безграмотно пишет (а и на Вике, и даже в технической документации на процессорные ядра безграмотности хватает) -- это уже не моя вина. Я, например, для какое-то из ядер Cortex-M видел, что в TRM его назвали гарвардской архитектурой (не модифицированной даже, а просто гарвардской), хотя все разновидности архитектуры ARM являются фон-неймановскими (и команды, и данные могут извлекаться из одной и той же памяти по одним и тем же адресам; для ускорения могут, но не обязаны использоваться отдельные кэши или TCM для кода и данных, но их всегда можно отключить в процессе работы -- и что, это изменит архитектуру процессора?)
И, замечу, что документацию, что Вику, что комментарии на Хабре пишут обычные люди. Считать заранее, что написанное где-то "там" является авторитетным и правильным -- такое себе... Даже в настоящих, тщательно выверенных энциклопедиях иногда попадаются ошибки, а уж в кое-как состряпанных быдлоиндусами документах...
Принципиальное отличие гарвардской архитектуры от фон-неймановской -- наличие двух независимых адресных пространств для кода и для данных, из-за чего численно одинаковый адрес вызывает обращение к разным ячейкам памяти в зависимости от того, используется ли он для доступа к коду или данным. Из современных действительно гарвардских архитектур, пожалуй, самая известная -- это AVR8 (благодаря Ардуине); в частности, в ней для доступа к константам, записанным во флэш-памяти, т.е. в памяти кода, пришлось ввести специальные команды, а не обычные, работающие с данными в ОЗУ.
Обычные же процы все поголовно являются фон-неймановскими, и разделение кэшей не делает их гарвардскими: обращение по одному и тому же адресу вызовет доступ к одной и той же ячейке памяти независимо от того, где она кэширована (как это будет реализовано технически -- второй вопрос). Правда, их нередко называют "модифицированными гарвардскими" или чем-то подобным, но лишь вносят лишнюю путаницу: с точки зрения программиста это фон-неймановские архитектуры, а что у них там внутри, программиста вообще не касается (а вот на настоящих гарвардских перед программистом появляется ряд дополнительных проблем; можете попробовать для интереса на той же Ардуине использовать printf("abc") и char S[] = "abc"; printf(S) -- сразу увидите разницу).
Справедливости ради -- иногда и сами строки. Скажем, если надо отсортировать строки в файле. Но разумный программист, конечно, прочитает исходный файл, отсортирует, переставляя указатели, и запишет результат -- всё с минимумом телодвижений и без пересылок собственно строк.
Потому что с терминами обращаются очень вольно, а заодно часто не понимают реальный смысл терминологии, а смотрят лишь на некий формальный признак. Торчат из процессорного ядра отдельные порты для доступа к коду и данным -- всё, это Гарвард, хотя сам проц как был фон-неймановским, так и остался, ибо адресное пространство-то общее у кода и данных, а не принципиально отдельное как у гарвардской архитектуры (именно в едином или разных адресных пространствах отличия между этими двумя подходами, а отнюдь не в числе внешних интерфейсов процессорного ядра, иначе, например, придётся сказать, что, скажем, Cortex-M1 может быть то гарвардским, то фон-неймановским в зависимости от того, включены в настоящий момент времени DTCM и ITCM или отключены).
Крайне поверхностно, без упоминания многих фактов и т.д. и т.п. Чьим был "первый коммерческий чип SRAM-памяти", я не скажу, но им точно не была приведённая в статье интеловская микросхема ёмкостью 256 бит. В частности, у TI были микросхемы 7481 и 7484 ёмкостью аж 16 бит, причём это ещё не совсем полноценное ОЗУ, а лишь его накопитель: этим микросхемам был нужен внешний дешифратор адреса и схемы управления записью и считыванием. Тем не менее, это самая что ни на есть настоящая статическая память на триггерах (но каждый триггер -- отнюдь не шесть транзисторов; последние -- это современная схемотехника КМОП, а отнюдь не доминировавшая в 1960-70-х годах ТТЛ и не n-МОП, которая применялась в микросхемах памяти более-менее значительного объёма в 1970-80-х). Да и первые "модули DRAM", а точнее, микросхемы, имели ёмкость поменьше 1 килобайта; например, массово были распространены микросхемы организацией 4096*1 бит, т.е., в пересчёте на байты, 512 байт.
Ну и впечатление такое, что до Интела памяти вообще не было :) Где, например, рассказ про ферритовую память, на которой работали абсолютно все вычислительные машины 60-начала 70-х? Или про более ранние реализации, где использовались и запоминающие ЭЛТ, и ртутные линии задержки, а то и вовсе магнитные барабаны?
На лампах, кстати, оперативную память никто не делал. На них были собраны усилители и логические элементы, а не сама память. И появившиеся транзисторы сначала потеснили лампы именно в этом качестве, а память оставалась той же самой -- ферритовой.
Если б это зависело от меня, я бы предлагал две реализации: чисто Си/Си++, полностью соответствующую стандартам языка и переносимую между любыми более-менее разумными платформами, ну а для определённых платформ -- тщательно оптимизированную ассемблерную под конкретную платформу, а то и под конкретное семейство процессоров (или вообще зашитую на уровне компилятора: скажем, мэйнфреймы z/Architecture имеют команды для шифрования данных по всяким там AES, команды для преобразования между разными кодировками Юникода и прочая, про "тупые" пересылки строк уж и не говорю -- очевидно, что для эффективности соответствующие функции конкретно на этой платформе нужно реализовать с помощью таких команд, а не компилировать универсальный сишный исходник, который, конечно, работать будет, но наверняка сильно медленнее).
Протокол обмена между клиентом и сервером -- это отдельная песня, которая должна быть хорошо документирована, реализовать же его особых проблем не составит. Если протокол сам по себе налагает ограничения на длину строки -- что ж, придётся передавать её частями, при этом ПО должно уметь делить, а потом соединять строку -- это усложняет реализацию, но не сказать чтоб слишком сильно, и уж точно критической проблемой не является.
В OS/360, кстати (а это вторая половина 1960-х), поддерживались записи данных и фиксированной, и переменной длины (с длиной, задаваемой двумя байтами), причём они могли образовывать отдельные физические блоки или же паковаться по несколько записей в блок (и даже переходить с одной дорожки диска на другую, но только в пределах одного цилиндра, т.е. пока не нужно механически перемещать блок головок). ОС умела всё сама упаковывать-распаковывать за программиста, поэтому он мог работать либо на уровне логических записей, либо физических блоков -- последнее потенциально эффективнее, но ощутимо геморройнее. Сама длина в 64 Кбайта, конечно, сейчас представляется недостаточной, но API в виде соответствующих функций ОС благополучно разработали и реализовали, и он работает (для совместимости с древним софтом) до сих пор в современной z/OS. В общем, в 1970-х написать "правильный API" вполне могли -- собственно, нередко и писали, хотя временами и ошибались, конечно.
Насчёт быстродействия. Если делать отдельный аппаратный блок для десятичных операций, он будет либо работать медленнее, чем аналогичный двоичный блок, либо будет существенно сложней (и не факт, что такой же быстрый: усложнение железа нередко его замедляет, хотя есть нюансы :) ). Но это уже переход на уровень схемотехники.
Реально десятичные вещественные реализованы в z/Architecture. Основная польза от них, как представляется, не для научных расчётов, а для финансов -- раньше там использовались тоже десятичные числа, но целые переменной длины (1-31 цифра плюс знак), что было реализовано ещё в Системе 360 и благополучно дожило до наших дней.
В финансах десятичная система удобней, в частности, из-за того, что все правила округления и т.п. при расчётах вырабатывались веками и именно для десятичной системы, и, чтобы им следовать, считая в двоичной, приходится принимать специальные меры. Для научных расчётов этого не требуется: там результаты практически всегда не точные, а приблизительные, и важно лишь то, какая точность достигается, а не конкретные правила (в отличие от финансов, где считать надо только так, как это установлено регулирующими документами).
В общем, в той же z/Architecture двоичные и десятичные будут благополучно сосуществовать и дальше, а вот внедрение десятичных (хоть целых, хоть вещественных) в другие архитектуры представляется довольно сомнительным, не смотря на определённые выгоды от них в некоторых задачах.
На уровне принципиальных схем -- да. На уровне функциональных -- нет, там удобней логическое наличие/отсутствие сигнала, а не конкретные логические уровни. Сейчас-то всё пишут на языках (VHDL, Verilog и иже с ними), а в эпоху ручной "рассыпухи" было весьма актуально.
И ни слова об участии Польши в создании ЕС и СМ ЭВМ вместе с другими странами соцлагеря. В частности, поляки выкатили, судя по имеющейся информации, весьма удачную ЕС-1032; они же производили прекрасные терминалы СМ-7209.
Например, вот один из моих постов выше по ветке, где ясно видно, что разница между гарвардской и фон-неймановской архитектурами проявляется и важна для программиста (на примере Ардуины):
Когда я писал и в ARM, и в IBM, я использовал обычный деловой стиль. Разница в том, что IBM ответила и исправила ошибки, а ARM полностью проигнорировала обращение.
А грубость -- да, допустил и буду допускать дальше. Если человек дурак, я так и говорю, а не занимаюсь политкорректными изысканиями на тему "альтернативной одарённости".
Вообще-то такой ответ отнюдь не говорит о том, что я считаю себя непогрешимым. Я указал на фактическую ошибку в официальной документации -- и эта ошибка остаётся ошибкой независимо от моей личности (точно так же, как Земля вертится независимо от личностей Кеплера, инквизиторов и прочая).
Вернёмся к Вашему утверждению, на которое Вы здесь сослались. Чтоб не бегать по комментариям туда-сюда, процитирую его здесь.
На самом деле, здесь несколько утверждений.
1) "Во многих современных CPU общего назначения разделены кеш данных и кеш инструкций" -- да, это верно. Более того, не обязательно разделены кэши: например, у целого ряда процессорных ядер ARM предусмотрено подключение к ядру через отдельные порты так называемой тесно связанной памяти команд и данных (ITCM и DTCM), которая является именно памятью, а не кэшем.
2) "Получается, внутри CPU гарвардской архитектуры (физически инструкции и данные в разной памяти и доступ к ним по разным каналам)" -- а вот здесь верно лишь отчасти. Доступ действительно по разным каналам (портам, шинам), но:
Если речь идёт о кэше, то он -- не память в том смысле, в каком была память в первых фон-неймановских и гарвардских компьютерах, откуда термины и пошли: кэш не является "истинным хранилищем", а лишь буфером, ускоряющим доступ, о чём Вы, по сути, говорите чуть далее. В случае DTCM/ITCM, однако, это будет именно что память, а не буфер.
Внутри процессор всё равно не является гарвардским. В случае с кэшами, если идёт обращение к коду, он обратится к кэшу команд, заполнив его, при необходимости, из настоящей памяти (нередко -- через промежуточные общие кэши). В случае обращения к данным он обращается к кэшу данных -- но заполняет его из той же самой памяти, используя те же самые адреса, и поэтому, в отличие от настоящего гарвардского компьютера, этот процессор может использовать одну и ту же ячейку памяти и для кода, и для данных, причём в буквальном смысле одновременно.
В случае DTCM/ITCM (об этом Вы не писали -- возможно, и не знали, но для полноты картины этот вопрос всё равно надо рассмотреть), на первый взгляд, ситуация всё-таки соответствует именно гарварской архитектуре. Но стоит бросить второй взгляд, и тогда будет видно, что (а) процессор может выбирать данные из ITCM и записывать информацию в ITCM, а не только в DTCM, для чего в ядре имеется соответствующая коммутация -- соответственно, ITCM работает и как память данных; (б) ITCM и DTCM не обязательны к реализации, а когда имеются, могут быть отключены программно, и тогда доступы по их адресам будут отправлены на общую шину, к которой подключена общая память (и разная периферия). Отсюда видно, что процессорное ядро даже с подключёнными к нему ITCM и DTCM ведёт себя как фон-неймановский компьютер, а не как гарвардский.
3) "а снаружи - фон Неймановской" -- согласен, но добавлю несколько слов чуть ниже.
4) "Оттуда и путаница." -- абсолютно согласен.
А теперь добавка.
Путаницу создаёте в том числе и Вы, из-за чего я написал свой пост в ответ на данный Ваш пост. Если бы Вы написали "Получается, внутри CPU модифицированной гарвардской архитектуры..." -- всё было бы нормально, но Вы не написали "модифицированной". А ведь просто гарвардская архитектура вызывает "несовместимость" адресных пространств кода и данных -- а этого нет, о чём Вы и говорите позже ("а снаружи - фон Неймановской"). Так что изначально моя претензия к Вам связана именно с использованием неправильного термина -- та же самая история, что и в цитированном Вами TRM на ARM9TDMI. (Термин "модифицированная гарвардская" мне не нравится, так как вызывает ненужные ассоциации с просто "гарвардской" и этим провоцирует путаницу -- но о терминах не спорят, а договариваются, но, договорившись, надо придерживаться терминологии, а с этим хронические проблемы).
Кстати, в том TRM есть такие пассажи:
Т.е. в реальности речь идёт о полноценном фон-неймановском компьютере, вместо которого при желании можно сделать частично гарвардский, а отнюдь не о "жёстко" и безальтернативно гарвардском -- но автор этого TRM ни разу не упомянул ни "von Neumann", ни "modified Harvard" (что было бы корректно), а только просто "Harvard" (что некорректно). Поскольку это не беседа в курилке и даже не чат, а официальный документ, я делаю вывод, что автор либо безграмотен (не видит разницы между "гарвардом" и "модифицированным гарвардом"), либо наплевательски относится к выполнению своей работы (не придерживается точной терминологии).
Кстати, сама архитектура ARM допускает как фон-неймановскую, так и гарвардскую реализацию, что прекрасно видно из документа ARM DDI 0100I "ARM Architecture Reference Manual". Однако она не предполагает именно гарвардскую реализацию и, более того, не делит адресные пространства на код и данне, что обязательно имеет место в настоящих гарвардских архитектурах вроде AVR8 (или собственно первых гарвардских компьютеров, давших название архитектуре). Просто возможна реализация, где не из любой области памяти можно выполнять команды или не к любой области памяти можно обращаться как к данным. И если реализации с памятью "только для данных", наверное, встречались на практике, то вот реализации "только код" крайне сомнительны, ведь тогда пропадёт возможность использования так называемых "литеральных пулов" -- констант, размещённых рядом с командами и адресуемых относительно счётчика команд, а без этого весьма неудобно при программировании на ассемблере и вовсе невозможно при использовании компиляторов с языков высокого уровня. Думаю, можно смело утверждать, что настоящих, "жёстких" гарвардских компьютеров на базе архитектуры ARM попросту нет, имеются лишь некоторые реализации, ограничивающие возможность размещения кода в произвольных областях памяти, что не требуется архитектурой, а является особенностью этих конкретных реализаций.
Начиная, по меньшей мере, с Системы 360, сначала разрабатывается архитектура, т.е. система команд, правила обработки прерываний и т.д. и т.п., и лишь затем реализация, включая схемотехнику.
Терминология же должна, вообще говоря, стандартизироваться -- и только в таком случае можно указывать тексты стандартов или иных нормативных документов как авторитетные источники. Но, кажется, Вы сами где-то выше говорили, что внести порядок в использование терминологии комитеты по стандартизации даже не пытались. Так что, простите, единственным авторитетным источником в такой ситуации может быть только анализ происхождения термина и его связь с описываемыми им явлениями -- а при таком анализе станет ясно, что процессоры "модифицированной гарвардской архитектуры" на практике ведут себя как фон-неймановские (исполняют код и обеспечивают доступ к данным в одних и тех же ячейках памяти), а не как гарвардские (строго разделяют хранилища кода и хранилища данных), а соответственно, опускать слово "модифицированная" недопустимо, что, однако, нередко делают -- как сделали в процитированном Вами документе от ARM.
В общем, "фон-неймановская" и "гарвардская" архитектуры, хотя и пошли изначально от реализации (в первом приближении -- схемотехники) конкретных вычислительных машин 1940-х годов, влияют на видение машины со стороны программиста (единое или разные адресные пространства кода и данных). А вот "модифицированная гарвардская" архитектура относится только к уровню микроархитектуры и реализации (опять-таки, в первом приближении -- к схемотехнике) и не влияет на наблюдаемое программистом "глобальное" поведение машины (при условии, конечно, что программист соблюдает требования архитектуры по, например, использованию самомодифицирующегося кода: в IA-32 или Системе 370 никаких действий ему предпринимать не надо, а вот в ARM требуется выполнить барьеры данных и команд, чтобы гарантировать учёт внесённых изменений).
1) Из контекста ясно, что речь идёт о некотором ограниченном круге лиц -- о программистах (поскольку для программиста есть разница, можно ли обращаться к данным в произвольных областях памяти или такой разницы нет -- сравните на Ардуине поведение printf("abc") и printf(S), где S -- массив в оперативе).
2) Я писал в ARM -- реакция была нулевой. Приходилось мне писать и в IBM по поводу ошибок в z/Architecture Principles of Operations -- там отвечали, а замеченные ошибки исправляли в последующих версиях данного документа.
3) Где я утверждаю, что я непогрешим? Это Вы мне приписываете непогрешимость.
1) Я где-то утверждаю, что что-то существенно или несущественно для схемотехники? Кажется, я утверждаю лишь то, что разделение на фон-неймановскую и гарвардскую (без всякой "модифицированной") существенно для программиста, а схемотехники вообще не касаюсь.
2) Я указал на фактическую ошибку, допущенную автором конкретного документа: он написал, что архитектура гарвардская (не "модифицированная гарвардская", а просто "гарвардская"), в то время как архитектура ARM не предполагает разделения на кода и данных и не реализует его, включая указанное ядро ARM9TDMI.
3) А если и д'Артаньян, то что с того? Это не я ошибку в документации допустил. Кстати, ARM её несколько раз повторяет в разных документах -- т.е. часть документации (а именно,TRM) там пишут люди, не видящие разницы между "гарвардской" и "модифицированной гарвардской".
А когерентность кэшей к "модифицированной гарвардской" вообще не относится, по большому счёту. Скажем, у мэйнфреймов IBM -- если не с Системы 360, то с Системы 370 точно -- есть чётко прописанные в руководстве по архитектуре критерии, которые аппаратура обеспечивает, при этом, естественно, сама архитектура не навязывает способ реализации. Например, самомодифицирующийся код автоматом учитывается процессором, на котором он выполняется (т.е. можно выполнить запись буквально следующей выполняемой команды -- и процессор обязан исполнить уже модифицированную команду). Однако изменения, вносимые в память другими процессорами или подсистемой ввода-вывода (каналами), могут оставаться неучтённым до тех пор, пока не произойдёт сериализация (она всегда происходит при прерываниях, а также в ряде других строго обозначенных случаев, но может происходить и чаще; в частности, если у машины в принципе нет никаких кэшей и буферов, это логически эквивалентно непрерывно выполняемой сериализации).
Понятно, что современные мэйнфреймы z/Architecture являются "модифицированными гарвардскими", т. е. с радельными кэшами команд и данных -- но архитектурно они как были фон-нейманами, так и остались, и ведут себя, с точки зрения программиста, так же, как вели себя их предки их 1970-х годов. В плане сериализации добавилось пару моментов для повышения общей эффективности. Скажем, в Системе 370 команды сравнения и обмена (CS и CDS) выполняли принудительную полную сериализацию, что требовало переписи всех изменённых строк кэшей в основную память (ОП; термин ОЗУ там исторически не используется, а никакой другой памяти у машины, с точки зрения программиста, нет -- ну, не считая "внешней памяти" в виде дисков и лент, конечно) и последующей полной очистки всех кэшей, чтобы учесть изменения в ОП, которые могли быть внесены другими процессорами или каналами. В z/Architecture эти команды ведут себя точно так же (обеспечение совместимости!), но появился ряд других команд, которые выполняют лишь "узкую" сериализацию -- гарантируют запись изменений из кэшей и последующую загрузку актуального содержимого ОП только для тех ячеек памяти, к которым эти команды обращаются (чем достигается повышение производительности: не всегда требуется полная сериализация, и какой способ выбрать, определяет программист).
И я про то же говорю. Фон-неймановская и просто гарвардская относятся... ну, к архитектуре -- т.е. к самим принципам функционирования процессора/компьютера с точки зрения программиста (предусматривает ли архитектура жёсткое разделение на код и данные или же не проводит различия между ними). А "модифицированная гарвардская" -- это чисто про реализацию, с точки зрения не программиста, а разработчика процессора.
1) Как уже отметил другой товарищ, пользователем процессора является программист, и для него между фон-неймановской и гарвардской архитектурой есть только одно принципиальное различие -- единые или разные адресные пространства для кода и данных.
2) Я пишу о разнице фон-неймановской и гарвардской архитектуры, о гарвардской говорит и обсуждаемая изначально статья. О "модифицированной гарвардской" я написал лишь то, что этот термин вносит дополнительную путаницу; я нигде не утверждал, что "модифицированная гарвардская" архитектура вводит разные адресные пространства для кода и данных (тем самым не давая возможность использовать один и тот же адрес и для кода, и для данных в разных ситуациях). Так что попрошу не передёргивать.
3) Вам нужны ссылки -- ищите историю появления гарвардской архитектуры и почитайте, как работали первые компьютеры, построенные на ней. Именно на них различие с фон-неймановской и проявилось во всей красе.
4) Вы привели цитату из ARM9TDMI про "гарвардскую архитектуру" -- не "модифицированную", а просто "гарвардскую". Однако это ядро, как в целом вся без исключения архитектура ARM (конкретно это ядро относится к версии ARMv5T, если не изменяет память), является фон-неймановской архитектурой, допускающей исполнение кода и чтение-запись данных из одной и той же памяти, а не гарвардской, строго разграничивающей адресные пространства. Автор документа -- как раз тот самый быдлоиндус, безграмотно использующий термины, и реальная авторитетность данного источника в плане терминологии равна нулю (она ненулевая в плане описания особенностей реализации ядра).
Моя личная интерпретация как раз и отражает единственную существенную разницу между гарвардской архитектурой и фон-неймановской, а приведённая Вами цитата лишь запутывает картину, цепляясь к техническим подробностям и упуская из вида главное. Вспомните о том, что эти самые "separate storage and signal pathways for instructions and data" для фон-неймановских процессоров (которые, если не ошибаюсь, Вы склонны называть гарвардскими или модифицированными гарвардскими) имеют место только между ядром и кэш-памятью первого уровня; в последующих кэшах и тем более в собственно памяти разделения на код и данные у фон-неймановских процессоров нет. Ну и сравните это с настоящими гарвардскими архитектурами, например, с AVR8, где команды и данные хранятся в разных модулях памяти, которые между собой вообще не пересекаются по адресам (и для выборки данных из памяти команд нужны специальные команды, отличающиеся от команд, работающих с памятью данных).
Насчёт STM8 я не в курсе -- не сталкивался с ними. Ну а если кто-то безграмотно пишет (а и на Вике, и даже в технической документации на процессорные ядра безграмотности хватает) -- это уже не моя вина. Я, например, для какое-то из ядер Cortex-M видел, что в TRM его назвали гарвардской архитектурой (не модифицированной даже, а просто гарвардской), хотя все разновидности архитектуры ARM являются фон-неймановскими (и команды, и данные могут извлекаться из одной и той же памяти по одним и тем же адресам; для ускорения могут, но не обязаны использоваться отдельные кэши или TCM для кода и данных, но их всегда можно отключить в процессе работы -- и что, это изменит архитектуру процессора?)
И, замечу, что документацию, что Вику, что комментарии на Хабре пишут обычные люди. Считать заранее, что написанное где-то "там" является авторитетным и правильным -- такое себе... Даже в настоящих, тщательно выверенных энциклопедиях иногда попадаются ошибки, а уж в кое-как состряпанных быдлоиндусами документах...
Принципиальное отличие гарвардской архитектуры от фон-неймановской -- наличие двух независимых адресных пространств для кода и для данных, из-за чего численно одинаковый адрес вызывает обращение к разным ячейкам памяти в зависимости от того, используется ли он для доступа к коду или данным. Из современных действительно гарвардских архитектур, пожалуй, самая известная -- это AVR8 (благодаря Ардуине); в частности, в ней для доступа к константам, записанным во флэш-памяти, т.е. в памяти кода, пришлось ввести специальные команды, а не обычные, работающие с данными в ОЗУ.
Обычные же процы все поголовно являются фон-неймановскими, и разделение кэшей не делает их гарвардскими: обращение по одному и тому же адресу вызовет доступ к одной и той же ячейке памяти независимо от того, где она кэширована (как это будет реализовано технически -- второй вопрос). Правда, их нередко называют "модифицированными гарвардскими" или чем-то подобным, но лишь вносят лишнюю путаницу: с точки зрения программиста это фон-неймановские архитектуры, а что у них там внутри, программиста вообще не касается (а вот на настоящих гарвардских перед программистом появляется ряд дополнительных проблем; можете попробовать для интереса на той же Ардуине использовать printf("abc") и char S[] = "abc"; printf(S) -- сразу увидите разницу).
Справедливости ради -- иногда и сами строки. Скажем, если надо отсортировать строки в файле. Но разумный программист, конечно, прочитает исходный файл, отсортирует, переставляя указатели, и запишет результат -- всё с минимумом телодвижений и без пересылок собственно строк.
Потому что с терминами обращаются очень вольно, а заодно часто не понимают реальный смысл терминологии, а смотрят лишь на некий формальный признак. Торчат из процессорного ядра отдельные порты для доступа к коду и данным -- всё, это Гарвард, хотя сам проц как был фон-неймановским, так и остался, ибо адресное пространство-то общее у кода и данных, а не принципиально отдельное как у гарвардской архитектуры (именно в едином или разных адресных пространствах отличия между этими двумя подходами, а отнюдь не в числе внешних интерфейсов процессорного ядра, иначе, например, придётся сказать, что, скажем, Cortex-M1 может быть то гарвардским, то фон-неймановским в зависимости от того, включены в настоящий момент времени DTCM и ITCM или отключены).
Так экономия пары байт на длине строки тоже ни на что, по большому счёту, не повлияет...
Крайне поверхностно, без упоминания многих фактов и т.д. и т.п. Чьим был "первый коммерческий чип SRAM-памяти", я не скажу, но им точно не была приведённая в статье интеловская микросхема ёмкостью 256 бит. В частности, у TI были микросхемы 7481 и 7484 ёмкостью аж 16 бит, причём это ещё не совсем полноценное ОЗУ, а лишь его накопитель: этим микросхемам был нужен внешний дешифратор адреса и схемы управления записью и считыванием. Тем не менее, это самая что ни на есть настоящая статическая память на триггерах (но каждый триггер -- отнюдь не шесть транзисторов; последние -- это современная схемотехника КМОП, а отнюдь не доминировавшая в 1960-70-х годах ТТЛ и не n-МОП, которая применялась в микросхемах памяти более-менее значительного объёма в 1970-80-х). Да и первые "модули DRAM", а точнее, микросхемы, имели ёмкость поменьше 1 килобайта; например, массово были распространены микросхемы организацией 4096*1 бит, т.е., в пересчёте на байты, 512 байт.
Ну и впечатление такое, что до Интела памяти вообще не было :) Где, например, рассказ про ферритовую память, на которой работали абсолютно все вычислительные машины 60-начала 70-х? Или про более ранние реализации, где использовались и запоминающие ЭЛТ, и ртутные линии задержки, а то и вовсе магнитные барабаны?
На лампах, кстати, оперативную память никто не делал. На них были собраны усилители и логические элементы, а не сама память. И появившиеся транзисторы сначала потеснили лампы именно в этом качестве, а память оставалась той же самой -- ферритовой.
В общем, совершенно ни о чём.
Если б это зависело от меня, я бы предлагал две реализации: чисто Си/Си++, полностью соответствующую стандартам языка и переносимую между любыми более-менее разумными платформами, ну а для определённых платформ -- тщательно оптимизированную ассемблерную под конкретную платформу, а то и под конкретное семейство процессоров (или вообще зашитую на уровне компилятора: скажем, мэйнфреймы z/Architecture имеют команды для шифрования данных по всяким там AES, команды для преобразования между разными кодировками Юникода и прочая, про "тупые" пересылки строк уж и не говорю -- очевидно, что для эффективности соответствующие функции конкретно на этой платформе нужно реализовать с помощью таких команд, а не компилировать универсальный сишный исходник, который, конечно, работать будет, но наверняка сильно медленнее).
Протокол обмена между клиентом и сервером -- это отдельная песня, которая должна быть хорошо документирована, реализовать же его особых проблем не составит. Если протокол сам по себе налагает ограничения на длину строки -- что ж, придётся передавать её частями, при этом ПО должно уметь делить, а потом соединять строку -- это усложняет реализацию, но не сказать чтоб слишком сильно, и уж точно критической проблемой не является.
В OS/360, кстати (а это вторая половина 1960-х), поддерживались записи данных и фиксированной, и переменной длины (с длиной, задаваемой двумя байтами), причём они могли образовывать отдельные физические блоки или же паковаться по несколько записей в блок (и даже переходить с одной дорожки диска на другую, но только в пределах одного цилиндра, т.е. пока не нужно механически перемещать блок головок). ОС умела всё сама упаковывать-распаковывать за программиста, поэтому он мог работать либо на уровне логических записей, либо физических блоков -- последнее потенциально эффективнее, но ощутимо геморройнее. Сама длина в 64 Кбайта, конечно, сейчас представляется недостаточной, но API в виде соответствующих функций ОС благополучно разработали и реализовали, и он работает (для совместимости с древним софтом) до сих пор в современной z/OS. В общем, в 1970-х написать "правильный API" вполне могли -- собственно, нередко и писали, хотя временами и ошибались, конечно.