> Естественно, совместные усилия процессора и софта. Так конфигурабельнее,
> чем железно прошивать что-то неизменяемое.

Ну да. А гарвард в классическом его понимании как раз полный брейнфак. Кто сомневается, может попробовать AVR прогать на сях, повозиться с указателями и познать масштаб грабель. Вот именно чистый гарвард, когда он настолько полный что и в программную модель вылез, это булшит все же. Си, да и сабж наверное не заточены на такое сами по себе.

> Да, на одних и тех же физических законах работают. Или ты про
> то, что они сделаны на транзисторах?

Я про то что поход на адрес 100500 это поход на адрес 100500, и будет ли он I-bus или D-bus сделан в принципе не проблема програмера, в 99.9(9)% даже может не задумываться над этим. В этом смысле современные железки чаще "логический нейман". А то что физически оно гарвард... прогеру обычно не видно. Только в каких-то глубоко системных операциях. Ну там early init когда I-cache и/или D-cache хотим как SRAM использовать за отсутствием DRAM, тут может начать интересовать.

Более детально в Cortex M видно: Cortex M0 нейман целиком (1 шина на все, 1 адреса). А M3 и жирнее уже нейман в логике, но I-bus и D-bus уже разные в физике, и так ессно быстрее при прочих равных. Но программная модель - нейман и от M0 в этом аспекте вообще отличия найти сложно.

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

Я их условно разделил на "логический" и "физический" уровни. Так вроде катит. Ну то-есть если есть I-bus и D-bus, то физически гарвард, но логически может нейманом выглядеть, чтобы не делать мозг пространствами.

> классификацию процессоров, инженеры следуют ей только тогда, когда это удобно.

В случае RISC vs CISC все еще интереснее.

> Но таблица пережила перепиливание, и пока выглядит так, что она _фундаментальна_,

А вон вам для гарвард vs нейман "с дополнениями". Разделим логику и физику, так вроде недурно классифицирует все что на глаза попадалось.

> она описывает фундаментальный закон Вселенной. Но большинство классификаций
> не фундаментальны,

Вообще, 1 шина на все vs I-Bus + D-Bus достаточно фундаментальное деление вроде. Во что это трансформируется в софте - отдельный вопрос.

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

Сейчас штуки типа линуха сделали подобные вещи достаточно lightweight. Конечно переключение контекста при желании отдать что-то ядру будет, и это не совсем халява. Но именно копиривания все же нету, потому и zerocopy. И сишные указатели за что-то такое все любят.

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

Ну, посмотрите на AVR. На си это мапится ушлепански. В gcc ведет к указателям которые как бы выглядят одинаково но не эквивалентны. Реально SRAM и FLASH натурально 2 разные пространства. В чем трабл? А в том что они не взаимозаменяемы и много нестандартных особенностей.

> Реально существуют MCU на гарвардской архитектуре которые могут перепрошивать сами себя,

Ну вот конкретно в AVR это отливается в то что оно не может извне вгрузить модуль в RAM. То-есть налить то код туда можно, но выполнить его - болт. В этом месте кортексы имеют нефиговый плюс. Даже если оно M3, вот так к SRAM bus matrix цепляет I, а вот так D, так что можно и код и данные.

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

Ну вон для "истинного гарварда" AVR подобное временами ведет к брейнфаку. Фокус в том что при записи флеш "временно недоступен" и в лучшем случае его контроллер держит шину и исполнение паузится на весьма ощутимое время в течение которого чип совершенно недееспособен. Хуже если не паузится :). А ежели код в SRAM выполняется, он при записи флеша живой и веселый, если не сунется в занятый флеш сдуру.

> И что? Если бы у тебя все адреса были бы равноценны, тебе
> бы не пришлось сношаться с mmap'ом.

Это требуется в основном из-за многозадачности. Каждому процессу кажут свое адресное пространство, полного размера. Он по нему может как правило целиком шариться (получит SIGSEGV за некоторые вещи). Очевидно физический лэйаут памяти не может совпадать 1 в 1 с этим. Иначе все процессы будут видеть всех, и внутренности ядра, отстой по безопасности. Но это другая абстракция, не особо связаная с гарвардом и нейманом, это "виртуальная память". В системе с VM и paging имеет смысл операция "memory mapping". Она отображает физические адреса в логические. Если бы мне не пришлось сношаться с mmap, я мог бы полностью перехватить контроль над системой, ибо некоторые физические регионы памяти это вообще железо. И я ммапал чтобы в регистры железки сходить "бех драйвера ядра" так то. Это вообще делать не стоит без понимания почему это может прокатить: прямой доступ таким манером рушит допущения многозадачки, при этом нет никакого арбитража доступа разных процессов и ядра и можно на этом нехило налететь.

> Когда ты в последний раз обращался к физическому адресу 0x100500?

Не так уж давно, а что?

> Ты можешь привести реалистичный пример программки на C, которая будет делать что-то типа
> *(unsigned char*)0x100500, и при этом обращаться именно к физическому адресу 0x100500?

Бутром из STM сдампил, характерной фичой "dumpblock(addr, len)" берущей на вход - только подумайте - лобовой адрес "чего дампим". Любой из 2^32 (оно 32-битное).

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

> Никто не обращается к физическим адресам, все давным-давно работают с виртуальными. Только
> mm в ядре парится о физических адресах, чтобы таблицы страниц правильно заполнять.

Ок, так круто за всех сишников говорить... только вот вся работа с железом например это работа с конкретными физическими адресами. Оно за mem-mapped, потому что это просто, быстро, хорошо работает, удобно сям.

> И что? Если ты упомянул "умную" аббревиатуру, то "это" перестало существовать?

Я лишь имел в виду что к гарварду MMU вообще ортогонален. И по логике вещей у "полного" гарвардца должно быть их минимум два: на I-адресацию и D-адресацию. Так то еще IOMMU бывает, но он про чуть иное: постановку железок в стойло. DMA так то тоже оперирует лобовыми адресами, физическими. И это не только позволяет железке полностью отыметь систему, но и к тому же ведет к очень интересным эффектам если железку в виртуалку пробросить. Там у драйвера свои идеи насчет адресов, только вот с хостом это не совпадает и когда железка запроганая драйвером в guest сделает именно вот туда DMA... :)))

> сформулировать и так, как ты это формулируешь:
>> Вообще это довольно нормальная абстракция, если не лезть в очень сильные дебри.

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

> Все кроме этих позорных прикладников вынуждены думать о стопке всё более медленных
> слоёв памяти в цепочке регистры-L1-...-LN-RAM-SSD/HDD/TAPE.

HDD и TAPE как правило не адресуемы как адреса памяти. Хотя mmaped файлы в случае HDD как частный случай могут немного поспорить с этим.

> насколько надо ещё эту мешанину усложнить, чтобы наконец признать, что это
> уже не фон-Нейман?

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

> У меня складывается ощущение, что ты считаешь, что ежели ядерный MM отлить
> в железе, то тогда это будет уже не фон-Нейман.

Для меня ответ на этот вопрос в контексте "логический нейман vs логический гарвард" будет зависеть от того греет ли програмер мозг отдельными адресными пространствами.

> сложность не отливает в железе? Такие сложности делаются софтварно.

Вообще-то программно-аппаратно. Совсем софтварно это малореализуемо и тормозно и требует очень явной поддержки именно железом. Как то paging и MMU. И вот этот паттерн многие собезьянили.

> микрокод, то есть множество программок, на каждую инструкцию по программке.

Не на каждую IIRC. Только на сложные. Это такой способ компрессии потока команд а потом и некая абстракция логического апи наружу от физической реализации. Внутри современнй x86 совсем не то что снаружи.

> можно менять. Почему? Потомучто: а) слишком сложно в железе это делать,

Вообще-то там в проце дефолтный uCode ROM защит. Просто его можно оверрайдить загружаемым, это после ряда увесистых багов в процах подгорело. Но uCode ROM это специфика махровых CISC. У большей части RISC его вообще нет, это одна из довольно четких границ водораздела RISC vs CISC.

> б) никаких транзисторов не хватит, и в) софтварное решение проблем гораздо
> гибче, настраиваемее.

Оно таки не полностью софтварное. Да и вообще uCode ROM заменили на uCode SRAM. И некие дефолты там есть, без него CISC вообще свой набор команд не могет выполнять по идее. Как минимум сложные операции, разбиваемые на микрооперации. RISC на самом базовом уровне отличается тем что операции простые и не бьются на более мелкие микрооперации секвенмируемые uCode ROM. И таки это делает процессорное ядро проще и меньше при прочих равных.