Слово состояния STATUS i8080

[b2m]

А если сигнал расширенной памяти дополнить сигналом STACK из слова состояния, то получится вообще супер-гарвардская архитектура: код в одной области, данные в другой, а стек - в третьей

[He3HauKo]

Интересная мысль!
Интересно а какие преимущества у разделенной памяти(код, данные)?
Надо прикинуть....

[Lavr]

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

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

Это криво-гарвардская архитектура и дыряво-принстонская в некотором
смысле...

У меня почему-то не складывается впечатления, что INTELL предполагала
такое штатное использование слова-состояния...

[HardWareMan]

Есть мнение, что М1 предназначался для того, чтобы периферия определяла опкод, стек - чтобы можно было собрать логику проверки стека на переполнение. Это все реально и необходимо, особенно для многозадачных и/или многопроцессорных систем.

[Lavr]

Возможно,... но если опираться на системный контроллер от самой INTELL,
она почему-то не почесалась заложить указанные возможности.

В некоторых моделях древних компьютеров от братьев-демократьев (кажется,
"Долботрон") STATUS целиком фиксировался и отражался на морде терминала
светодиодами.

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

[b2m]

А реально - область кода с "дырками" на адресах байтов данных

Ну это ты гонишь, нифига не разобравшись

Если область кода отключать только в нужный момент, то никаких "дырок" не будет.

[Lavr]

А реально - область кода с "дырками" на адресах байтов данных

Ну это ты гонишь, нифига не разобравшись

Если область кода отключать только в нужный момент, то никаких "дырок" не будет.

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

[He3HauKo]

....дыряво-принстонская...

[Lavr]

....дыряво-принстонская...

Ну я опираюсь на совершенно верное рассуждение Хардыча:

Вся проблема в том, что "выборка команды" это М1, поэтому команда STA 1234h,
которая в памяти по адресу, скажем, 8000h лежит как 32 34 12 будет выполнена так
(C - код, D - данные):
R C:8000 32
R D:8001 34
R D:8002 12
W D:1234 XX

Если отслеживать только М1, как мы начали обсуждать с petrenko,
то получится, что все C - в одной плоскости, а все D - в другой...

Если же на каждый C отслеживать его длину в байтах, то D:1234 XX - можно
закидывать в другую плоскость памяти.

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

На мой взгляд, простой регистр страниц, доступный по IN/OUT из любой страницы
памяти по принстонской архитектуре и управляющий демультиплексором сигналов
MEMRD/MEMWR, решает задачу коммутации плоскостей памяти схемотехнически
весьма просто и вполне элегантно.
При этом мы не теряем такую замечательную опцию принстонской архитектуры,
как возможность самомодификации кода.

[b2m]

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

Ну твои-то посты раз в пять потолще будут А схему - это если только HardWareMan нарисует. Он, кстати, вполне себе разобрался.

[Lavr]

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

Ну твои-то посты раз в пять потолще будут

Ну если не нравится - не читай, я же не с тобой конкретно беседую.

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

Успокойся, Дима, - правды много не бывает...

А что касается HardWareMan-а, он и сам по себе неплохо во всём разбирается,
тем более, что и рисовать его никто ничего не просил.

[He3HauKo]

Тут то я согласен что регистр через IN\OUT для расширения страниц элегантней и проще, интерес в другом.
Давайте прикинем что память разделена на две плоскости КОД и Данные, что мы от этого будим иметь, плюсы и минусы.
Сразу о минусах!
Первое что приходит на ум это "дыры" в памяти ДАННЫХ.
Можно от этого избавится, соорудив некий аппаратный стек, который указывал на ячейку с нужными данными.
Второе это самомодификация кода
И решения этой проблемы я не вижу.

[Lavr]

...
Второе это самомодификация кода

Ты пропустил важную фразу:

Весь вопрос в том, что мы хотим получить...

Смотря с какой стороны взглянуть, а то и минусы могут стать плюсами (и наоборот)...

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

Хотя мне больше по душе возможность самомодификации кода.

[He3HauKo]

Ты пропустил важную фразу:

Весь вопрос в том, что мы хотим получить...

Скажу честно, у меня одна цель!
Даеш новою архитектуру старому процу!!!
Каждая новая мысль по увеличению гибкость архитектуры, для меня как глоток воздуха

ЗЫ. А для защиты памяти, есть простое решение(на мой взгляд), это 9-ти битные ОЗУ. Все равно если использовать DRAM он там лишний.

[petrenko]

....дыряво-принстонская...

Ну я опираюсь на совершенно верное рассуждение Хардыча:

Вся проблема в том, что "выборка команды" это М1, поэтому команда STA 1234h,
которая в памяти по адресу, скажем, 8000h лежит как 32 34 12 будет выполнена так
(C - код, D - данные):
R C:8000 32
R D:8001 34
R D:8002 12
W D:1234 XX

Если отслеживать только М1, как мы начали обсуждать с petrenko,
то получится, что все C - в одной плоскости, а все D - в другой...

Если же на каждый C отслеживать его длину в байтах, то D:1234 XX - можно
закидывать в другую плоскость памяти.

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

Я кажется начинаю понимать, что к чему..
То есть первый вариант - только отслеживать M1 в байте статуса - просто вынуждает ( далее себя же цитирую)

сильно урезать возможности, а именно не применять следующие команды :
{ MVI LXI STA LDA SHLD LHLD ADI ACI SUI SBI ANI XRI ORI CPI JMP JNZ JZ JNC JC JPO JPE JP JM CALL CNZ CZ CNC CC CPO CPE CP CM IN OUT}
Но как обойтись без "JMP"-ов и "CALL" ?
Ну допустим "JMP"-ы как то можно заменить на PCHL
А для CALL ничего, кроме какой-нибудь аппаратной хитрости (типа защёлкнутый в отдельном регистре предыдущий адрес обращения в М1 прочесть, как пару ячеек памяти и затолкнуть в стек) не придумывается.

Сложно, изощрённо , зато аппаратно относительно легко.

Второй вариант -

на каждый C отслеживать его длину в байтах...

- мне понравился больше ( правда для осмысления того, что там происходит и каким образом это возможно сделать, мне потребовалось существенное время и напряжённое, неоднократное вчитывание в "дэйташиит") и это приближает систему к довольно хорошо знакомому мне семейству процессоров MCS-51 , что радует, конечно, хоть 8080 и беднее командами (но в первом то варианте становится ещё беднее). Считаю, что сделать сие аппаратно возможно, хотя ещё слабо представляю в деталях.
Ещё очень обрадовало то, что "b2m" верно понял мои слова :

Итого : Не трогаем первые 32К, а верхние 32К "расслаиваем" на три слоя 1- слой стека, в нём VDSK 2- слой M1, в нём модули и подпрограммы и 3- слой данных - таблицы, массивы и т.п. удобно держать.

- но разве это гарвардская получится ?

А если сигнал расширенной памяти дополнить сигналом STACK из слова состояния, то получится вообще супер-гарвардская архитектура: код в одной области, данные в другой, а стек - в третьей

Может это супер-супер-гарвардская ? Я просто не очень силён в классификации архитектур (уж извините), или, возможно, не всегда улавливаю юмор. Я не смог такой гибрид ни к какой архитектуре отнести.