Создание экосистемы свободного ПО для процессоров «Эльбрус»

Эта «ассемблерная команда» не сможет инвалидировать все указатели на выделенную область памяти.

Почему? Все производные указатели (полученные из исходного) всё равно содержат указатель на начало объекта. В котором будет отметка «удалён».

но если этот кусок будет переиспользован, то новые данные можно будет спокойно прочитать там где не надо

Тогда бы это позволяло читать данные:

#include <stdio.h>

int main()
{
        int x = 1;
        int y = 2;
        int *p = &x, *p1 = &y;
        p++;
        printf("%p %p\n", p, p1);
        printf("%d\n", p == p1);
        *p = 3;
        printf("%d\n", y);
}

Но нет

0xc2dfff92c218 0xc2dfff92c218
1
Ошибка сегментирования

Чужой указатель на этот адрес не работает.

У штеуда есть положительное качество - если они видят бесперспективность платформы, они её закрывают и начинают работать над новым.

Какую архитектуру бы ты хотел от МЦСТ? Какой бы это дало выигрыш для оборонки?

При оборотах штеуда на убогом x86 можно сколько угодно выпендриваться. Выпендриваться же в условиях выполнения контракта и куда более скромных бюджетах куда как сложнее и гораздо бессмысленнее.

А ещё сомневаюсь, что есть какие-то мифические «фанаты VLIW».

Меня можно считать фанатом VLIW. В том смысле, что я уверен, что VLIW может достичь большей производительности, чем равной сложности OoO процессор. Потому что у компилятора больше данных для оптимизации, чем у процессора.

Вот мне думается, что разработчики Эльбруса тоже дойдут до этой мысли

Ну мсье! Странно думать, что живые разработчики живого процессора не дошли до какой-то мысли. Тут надо написать «когда руки дойдут». Полагаю, что у них масса всевозможных планов, проектов и идей для улучшения того, что уже имеется.

ok

У штеуда есть положительное качество - если они видят бесперспективность платформы, они её закрывают и начинают работать над новым.

Действительно. Над RISC они перестали работать ещё во времена i960, а над ARM во времена XScale. Если верить штеуду, то кроме x86 перспектив нет.

Странно думать, что живые разработчики живого процессора не дошли до какой-то мысли. Тут надо написать «когда руки дойдут».

Всякое может быть. Ту же самую технологию ведь и в x86 можно использовать, но руки ни у кого не дошли (Microsoft Research сделала Singularity, но дальше ядра дело не дошло).

Есть … эмулятор

жду ебилд:

http://gpo.zugaina.org/Search?search=qemu-e2k

Учись сколько влезет.

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

Почему? Все производные указатели (полученные из исходного) всё равно содержат указатель на начало объекта. В котором будет отметка «удалён».

Это так не работает. :)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define N 1024
int main(int argc, char *argv[]) {
    char *x, *y;
    x = malloc(N);
    printf("malloc %p\n", x);
    x[0] = 0;
    printf("  x[0] %d\n", x[0]);
    y = x; // dangling pointer
    printf("  free %p\n", x);
    free(x);
    for (int i = 0; i < 1000000; i++) {
        x = malloc(N);
        if (x == y) break;
        free(x);
    }
    printf("malloc %p\n", x);
    printf("  y[0] write 13\n");
    y[0] = 13;
    printf("  x[0] %d\n", x[0]);
    printf("  y[0] %d\n", y[0]);
    printf("  free %p\n", x);
    free(x);
    return 0;
}

numas13@yukari:~/dev/tmp/test$ lcc -mptr128 a.c && ./a.out
malloc 0x509a9030
  x[0] 0
  free 0x509a9030
malloc 0x509a9030
  y[0] write 13
  x[0] 13
  y[0] 13
  free 0x509a9030

Даже в МЦСТ признают («>70%»), что ЗРИ ТБВ от всех проблем не защищает.

Не раскрыли, но оно уже давно есть в слитом binutils и qemu-e2k.

В котором будет отметка «удалён».

Кстати, даже формат указателя менять не придётся. Там же длина объекта есть. Её надо просто занулять.

Тебе для этого надо записывать где лежат (память, регистры, стек) все указатели на все объекты, чтобы потом инвалидировать их. ЗРИ ТБВ так не работает.

Это так не работает. :)

Так ты привёл тот же пример, что со стеком. Есть легальный указатель на 0x509a9030 длиной 1024. От того, что его передали в free он сейчас не перестаёт быть легальным (нет такой команды в ассемблере). Естественно, через него можно получить данные, которые получены во втором malloc.

Есть легальный указатель на 0x509a9030 длиной 1024. От того, что его передали в free он сейчас не перестаёт быть легальным (нет такой команды в ассемблере).

Ты очень узко мыслишь. free будет где-то в потрохах, а время жизни указатели может быть очень неочивидно. Повторяю, хочешь больше безопасности — пиши на safe Rust, а ЗРИ ТБВ выбрось нафиг. :)

Тебе для этого надо записывать где лежат (память, регистры, стек) все указатели на все объекты

Зачем?

Длинный указатель имеет структуру struct ptr {base *base, offset_t offset}. где база struct base {void* data, type_t type, offset_t length}.

При доступе проверяется 0 < offset < base->length.

Те же страницы, но не килобайтами, а байтами.

Инвалидация сводится к установке base->length = 0.

а время жизни указатели может быть очень неочивидно.

Как попал во free, так и умер.

Повторяю, хочешь больше безопасности — пиши на safe Rust

Также повторяю, что там половину алгоритмов не реализовать. Есть хоть одна библиотека для работы с произвольными графами на safe Rust?

Хоть я и не фанат RISC-V, но отступить в направлении RISC-V МЦСТ вполне может.

Есть не только эмулятор,

Это не официальный эмулятор. Его @a1ba написал по утёкшим спекам и он вроде как даже не полон. Альба, наверное, может подробнее написать, если ему не лень.

Сами перцы из МЦСТ клали болт кому-то эмуляторы давать.

алсо

QEMU With E2K User Support

Там ОС не запустишь. Только юзерспейс.

Также повторяю, что там половину алгоритмов не реализовать. Есть хоть одна библиотека для работы с произвольными графами на safe Rust?

Слушай, если уж на хачкелле есть, то на Rust сделать вряд ли проблема. Даже на Safe Rust, да.

Какую такую половину, во 1-ых сейф раст тьюринг полный, во 2-ых сейф это не только и не столько то что отделяется ключевым словом unsafe. А графы, в общем случае, с самого начала реализовывали на массивах ещё задолго до раста, это вырожденные случаи вроде списков допускают реализацию на указателях

Ты написал это его практически основному автору. :)

@numas13 в разы больше меня кода написал в этот эмулятор. :)

а лол! Тем более.

так там есть возможность запустить целую ОС? Или это всё таки только юзерспейс?

Только юзерспейс. Я работал над system режимом, но не доделал его.

Там в каком-то виде грузился Embox, но не проходил тесты на многопоток, а Linux собранный из их сорцов не может перейти в следующую стадию загрузки. Фиг знает почему всё это. :)

Слушай, если уж на хачкелле есть, то на Rust сделать вряд ли проблема. Даже на Safe Rust, да.

В Haskell нет ограничений на алгоритмы, потому что там сборщик мусора. А в Safe Rust контролёр заимствований требует гарантии, что ни один объект не будет записан в два места. Как при этом описывать графы (в каждом узле которого, по нормальной схеме, есть ссылки на всех соседей), я не представляю. Rc не подходит, так как в графе ссылки друг на друга и при удалении ссылки на граф они автоматически не обнулятся.

во 1-ых сейф раст тьюринг полный

Тогда напиши, пожалуйста на нём вот эту функцию: https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html#177

Да, под это Риск5 как раз и заточен

Да, под это Риск5 как раз и заточен

А в Риск5 разве есть возможность указать процессору порядок предвыполнения инструкций? Или ты хотел написать VLIW?

Если брать вместо байткода Риск5, то там инструкций не хватает.

Риск5, разумеется. Гораздо проще поддержка, нет проблем по росту производительности, стандартизация. И у нас в России уже есть компетенции по теме.

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

На том же риске можно сделать высоконадёжные процы, сейчас это мипс, но мипс умер.

И вплоть до микроконтроллеров.

И развивать отечественное по мере появления литографов. Сплошной профит

А этим будет заниматься аппаратный планировщик

Как при этом описывать графы (в каждом узле которого, по нормальной схеме, есть ссылки на всех соседей), я не представляю.

Массивом. Любой граф легко описывается двумерным массивом, чувак, и даже такая неоптимальная реализация будет лучше чем херачить указателями. На указателях графы делать – полная и тотальная тупость, хотя бы из-за накладных расходов по памяти. У тебя каждый указатель по 8 байт добавляет. Нахрен так вообще жить?

Хоть я и не фанат RISC-V, но отступить в направлении RISC-V МЦСТ вполне может.

Шило на мыло по большому счёту. По крайней мере в текущих реалиях.

Риск5, разумеется.

Почему именно от МЦСТ? Если всё так просто и замечательно, как ты расписываешь, то это золотая жила. Думаешь, деньги никому не нужны?

Любой граф легко описывается двумерным массивом

Чтоб тебе AST программы в таком формате обрабатывать.

Чтоб тебе AST программы в таком формате обрабатывать.

AST – это дерево. На Safe Rust пишется без проблем. Вот тебе AST для JSON:

https://github.com/serde-rs/json/blob/master/src/value/mod.rs#L116

Но, кстати, даже AST лучше массивом делать. Если ты посмотришь бенчмарки, у типичного жсон парсера с деревом на указателях потребление памяти улетает просто в небеса. Типа, для 10 мегабайтового жсона дерево может вполне сожрать метров 300-400.

На указателях графы делать – полная и тотальная тупость, хотя бы из-за накладных расходов по памяти. У тебя каждый указатель по 8 байт добавляет. Нахрен так вообще жить?

Так массив дороже. Вот возьмём простой граф-кольцо на пару тысяч точек. На указателях у меня будет N28 байт. На массиве будет N*N (пусть бит). Уже для 128 точек даже битовый массивы вырастает до того же размера, как и на структура на указателях. Плюс все операции на нём O(N).

Если же известно, что элементов меньше 256, то «указателем» может быть номер элемента массива узлов. И тогда массив становится неэффективен уже на 16 элементах.

Не обязательно от МЦСТ, можно дать заказ тому, кто уже сейчас занимается рисками в России и помочь с воплощением в кремнии, поскольку сейчас такие вопросы без согласования в самых верхах не решаются.

Или уповать на то, что влив это правильно, потому что начальству виднее.

Так массив дороже. Вот возьмём простой граф-кольцо на пару тысяч точек. На указателях у меня будет N28 байт. На массиве будет N*N (пусть бит). Уже для 128 точек даже битовый массивы вырастает до того же размера, как и на структура на указателях. Плюс все операции на нём O(N).

Если же известно, что элементов меньше 256, от «указателем» может быть номер элемента массива узлов. И тогда массив становится неэффективен уже на 16 элементах.

Ага. Проще юзать Integer Map, а вместо указателей на ноды тупо нумеровать их. Сами же ноды хранить как раз в массиве. Хацкельная FGL как раз вот так и делает.

https://hackage.haskell.org/package/fgl-5.8.2.0/docs/Data-Graph-Inductive-PatriciaTree.html

Видишь? Опять unsafe и рекурсивные ссылки нахрен не всрались!

Видишь? Опять unsafe и рекурсивные ссылки нахрен не всрались!

Вот это сделай без unsafe:

https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html#177

В смысле отдельно выдернутый метод в уже сформированной структуре данных на указателях? естественно это нереально, а так это как раз попадает под моё во 2-ых - т.е. доказанный и проверенный ансейф = сейф
А если с нуля: ну будет в основе какой-нибудь:

struct Node<T> {
    next: usize,
    prev: usize,
    val: T,
 }

дальше сам догадаешься.

А этим будет заниматься аппаратный планировщик

Аппаратный планировщик всегда хуже программного. Он видит меньше контекста (буквально несколько десятков инструкций), у него гораздо жёстче требования по скорости (JIT компилятор может выполнять алгоритм тысячи тактов, а аппаратный обязан за один такт выдать решение на столько инструкций, сколько можно выполнить параллельно).

сейчас такие вопросы без согласования в самых верхах не решаются

То есть частная компания не может наладить разработку и производства процессора без согласования в самых верхах? Или речь о распилах бюджета и откатах?

Или уповать на то, что влив это правильно

Я так и не смог для себя определиться тупик это или нет.

потому что начальству виднее

Какому? :)

Так массив дороже.

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

Да-да, хейтеры ржавого носятся с этим двухсвязным списком как с ссаной торбой. Уже 10 раз видели это и столько же раз обсосали. На RefCell это делается просто элементарно.

Держи: https://gist.github.com/matey-jack/3e19b6370c6f7036a9119b79a82098ca

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

дальше сам догадаешься.

Кстати, а как в ваших вариантах на массивах удаление узла происходит?

То, что в нормальном коде будет

auto node = fill_data();
auto elem = node->next->next; // удалим после этого элемента

auto next = elem->next->next;
free(elem->next);
elem->next = next;
next->prex = elem;

На RefCell это делается просто элементарно

До тех пор, пока есть гарантия, что ссылки не образуют петлю.

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

Основная проблема в том, что unsafe используется действительно массово. Иначе вместо того, чтобы решать задачу, решаешь ребусы от контролёра заимствования.

В прикладном коде unsafe мало. В низкоуровневых частях либ, которые делают какие-то хитрые штуки от него не уйти, но я повторяю тезис о том, что в таком коде багов почти не бывает.

На RefCell это делается просто элементарно

До тех пор, пока есть гарантия, что ссылки не образуют петлю.

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

Серьёзно, кончай тут с этим позором. Выглядит убого.