Защита адреса при записи

[vak]

Дошёл до реализации необычного свойства процессора микро-БЭСМ, отсутствующего у современных компьютеров. Каждое слово в оперативной памяти имеет дополнительный бит запрета записи. При попытке записи по этому адресу возникает прерывание "защита адреса при записи". Чтобы всё-таки иметь возможность изменить значение (и бит запрета), память имеет дополнительный сигнал, отменяющий защиту.

Получается полезная возможность, похожая на const в языке Си, но при этом защиту можно включать и отключать по ходу выполнения программы. Что-то отдалённо похожее - теговая архитектура - существовало в некоторых ранних компьютерах, но не прижилось.

Comments

[archaicos.livejournal.com]

В мире ощущается острый недостаток const!
Все влазят, но не всех убивает.

[spamsink.livejournal.com]

Выходит, каждая запись - не одно обращение к памяти, а два? Накладно.

[vak]

Замедления никакого нету. Шина адрес/данные мультиплексированная, и адрес в любом случае выдаётся на такт раньше строба записи. Память немедленно формирует ответ в виде текущего тега перезаписываемого слова. К следующему такту, когда пора выдавать строб записи, бит защиты адреса проверяется и вместо записи выдаётся прерывание.

[vak]

Как бы мог выглядеть в языке оператор установки и снятия признака const для переменной?

[vak]

А вот полезность всего этого тегового хозяйства для конечного юзера вызывает сомнения. Руднев прав: совершенно непонятно, как совместить теги с пейджингом, к примеру.Страница кода мэппится в бинарный файл программы, это понятно, а теги куда? Для тегов можно держать отдельную секцию в ELF-файле, но использовать механизм mmap() по любому не выйдет.

[rbs-vader.livejournal.com]

У SPARC в последних реализациях что-то похожее есть, но даже посложнее. Регионы памяти помечаются "цветом", в чужой регион запись невозможна (и вообще доступ). Причём всё это на аппаратном уровне, там никакой Интел и рядом не лежал.

[spamsink.livejournal.com]

Не вижу проблемы, чтобы пейджинг происходил 9-килобайтными блоками вместо 8-килобайтных. Как DMA организуешь, так и будет. В ELF-файле держать теги не надо, их можно формировать в зависимости от типа секции. А вот то, что при современной памяти (которая на порядки медленнее процессора) надо было бы перед записью отдельно читать, всю идею и подкосило.

[archaicos.livejournal.com]

const a = 1;
void foo(void)
{
#pragma push(fuck)
#pragma fuck(off)
a = 0;
#pragma pop(fuck)
}

[1801bm1.livejournal.com]

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

[vak]

Теги не получится формировать автоматически. Их делает ассемблер по информации от компилятора:
ПК - признак команды
РЭ - режим БЭСМ-6
ЗЧП - запрет чтения операнда из памяти
ЗЗП - запрет записи операнда в память
ЗВП - запрет выборки команды из памяти
ЗПУ - запрет передачи управления на команду

Часть битов можно в первом приближении ставить от типа секции, но с ЗПУ такой финт не пройдёт.

Если дело дойдёт до портирования юникса на микро-БЭСМ, мне кажется, имело бы смысл упростить хардвер и выкинуть все эти теги совсем. А режим БЭСМ переключать битом в регистре режимов.

[vak]

На SDRAM фигово получится, это верно. Или пришлось бы проектировать специальные SDRAM с поддержкой тегов.

[izard.livejournal.com]

в x86 можно пометить страницу (4к), можно ли из нее читать-писать-запускать код, потом пускай компилятор в read-only страницы константы аллоцирует.

[vit-r.livejournal.com]

Весьма полезная вещь, если писать на ассемблере. Думаю, на языке высокого уровня эта особенность превратится в ад, потому и не прижилась.

[nms.livejournal.com]

Burroughs, однако!

[Евгений Х. (from livejournal.com)]

Какой из юниксов самый привлекательный для портирования в данном случае?

[vak]

Я склоняюсь к OpenBSD. Возможно, лучше начать с LiteBSD, там все в ядре попроще. Когда заработает - вернуться к полномасштабному OpenBSD.

[vak]

Защита на уровне страниц здесь тоже имеется, примерно такая же.
Самый прикол в том, что признак const у слова можно менять в рантайме. Ни один из известных языков даже мысли такой не допускает.

[vak]

Цвет у SPARC сделан на уровне страниц, а не отдельных слов. Но отдалённо что-то похожее, да.

[vak]

Наоборот, в то время считалось, что именно для языков высокого уровня теги полезны. LISP и прочие дела.

[vak]

Burroughs держал в тегах информацию о типе значения, как Эльбрус. Там не было никаких "защит". Здесь совсем другой подход, более "бэсмовский" и приближённый к хардверу.

[rdia.livejournal.com]

А какой в этом смысл? Против злоумышленника это не поможет, а в ЯВУ и так всё, что не нужно, закрыто на этапе компиляции.

[rdia.livejournal.com]

Я, конечно, не рассматриваю тут кросс-платформенные ассемблеры С/С++. В них - очень кстати, особенно, если в программе снятие защиты делается каким-то очень явным образом.

Тогда при вызове функции можно сразу по умолчанию запрещать переписывать данные стека, например. Или наоборот, разрешать запись только в выделенную память (правда это будет медленно).

Зато у вас будет большой геморрой с многопоточностью. :-)

[rbs-vader.livejournal.com]

Да там и весь процессор прекрасен, очень жаль, что общие масссы вынуждены довольствоваться этим убогим х86...

[nms.livejournal.com]

Не понимай ссылку на Burroughs буквально. ;-)

[b0p0h0k.livejournal.com]

В Эльбрусе-1,2 (а следовательно и в СВС) также имелся "тэг незабиваемой информации". На практике, однако же, требовалось включить специальный режим процессора, чтобы этот тэг действовал, и режим этот замедляд обращение в память по записи раза в два.
Поэтому режим этот никогда не включали, кроме, может быть, особо тяжёлых случаев отладки.