Это хоть и необходимые, но уже дополнительные фишечки к базе. Самое самое необходимое - это возможность написать HelloWorld. Потом идёт факториал, потом какой-нибудь калькулятор, компилятор и где-то там эти memory mapped io потребуются.

А в 99% случае в системном языке мы создаём переменные, переприсваеваем их, вызываем функции и т.д. И это всё в 99% случаев должно работать со стеком, а не с кучей. Поэтому стек.

А у всяких OOO cpu, EDGE, EPIC есть недетерминированность исполнения инструкций на низком уровне. То есть, казалось бы, в этом новом системном языке недетерминированность на низком уровне должна как-то отражаться.

Может быть даже Хаскель тут хорошо описывает реальность того же MCp - общая последовательность задаётся do блоком, а на низком уровне, если нет undefined, программист даёт волю системе вычислять в том порядке, в котором она хочет.

Вообще говоря, это вполне насущная задача -- создание ограниченного языка (подмножества Си) или DSL для задач низкоуровневых и высокопроизводительных вычислений. Здесь интересен анализ конструкций языка на предмет их эффективной компиляции для заданной целевой архитектуры. А архитектура эта иной раз может не соответствовать представлениям массового "настольного" программиста.

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

Это как раз основные фишечки, чтобы можно было работать с оборудованием. Иначе, кто увидит этот самый Hello world?

Почему обязательно стек? Не вижу взаимосвязи с задачами системного программирования.

P.S. Недавно перечитывал книгу о программировании игр на ZX-Spectrum. Там в качестве системного языка был Бэйсик, а в качестве эффективного языка - ассемблер. И ничего так, было весело.

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

Кстати, давайте перестанем цитировать миф о том, что Мультиклет это что-то в духе SSA в аппаратной форме. Во-первых, архитектура Мультиклета демонстрирует, что о технологиях компиляции авторы процессора не думали, а, во-вторых, какая-то возня с LLVM и Мультиклетом началась лишь совсем недавно — во что выльется, увидим, но, судя по годам, потраченным на компиляторы для Мультиклета, для того же стекового процессора из SSA генерировать код проще :)

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

Ну вот, в Мультиклете и нет аппаратного стека. Там не очень SSA, конечно, потому что регистры всё время "ползут", и LLVM к этой идее очень крайне перпендикулярен. Но прогресс идёт. Хотя, конечно, проще было бы сделать на SoN и не страдать.

О. Пришло в голову. Мультиклет - это Single Dynamic Assignment.

SoN является чисто компиляторной абстракцией, тем и хорош. При этом, что важно, SoN, как и любой другой вариант IR, имеет черты какой-то выч. архитектуры. Но в случае SoN это, всего-навсего, машина потоков данных. Для поддержки SSA, кстати говоря, очень полезно иметь в аппаратном варианте команды групповой перестановки регистров.

Ну так и вот. Некоторая гениальность же мультиклета в чём? В том, что каждый параграф - это небольшой фрагмент потока данных, а фрагменты эти стыкуются последовательно, позволяя программам быть +/- привычно последовательными с рекурсиями и ветвлениями через jmp-ы. Я не утверждаю, что это trueЪ-way процессоростроения, но, как минимум, идея небезынтересная. Для функциональных языков там может быть очень много интересных возможностей. Хотя, они сами концентрируются на LLVM. Зря, мне кажется.

То есть, это очень похоже на программу на Хаскеле.

Я что-то (временно?) перестал понимать почему люди хотят заменить C в качестве системного языка. Да и что такое "системный язык" тоже перестал понимать.

Но если уж фантазировать на эту тему, то понятно, что есть 2 аспекта, и они почти не пересекаются. Одно дело, теоретически (принципиально) более оптимальный язык для современного железа и какого-то круга "системных" задач. Другое дело - язык, способный заменить огромное количество C/C++ кода на практике, т.е. которым согласятся пользоваться большие массы "системных программистов".

При этом теоретически стройный и эффективно компилирующийся язык сделать-то не проблема, но пользоваться им никто всё равно не будет. Есть же пример ATS прямо перед глазами уже не мало лет.

А на практике Rust не так уж сильно отличается от C с одной стороны, но при этом предлагает значительные преимущества с другой. Поэтому сейчас - самый реалистичный претендент.

C'est la vie. 🤷‍♀️ 😊

Складывается ощущение, что поклонники ФП на нашем канале давно не открывали Харрисона&Филда, раздел "потоковые реализации" %)

Никогда, спасибо.

Не уверен. Но Хаскель, определённо, от такого поведения процессора может выигрывать: когда можно с потоком основных вычислений параллельно проверять готовность отложенных вычислений, и в зависимости от этого заранее запускать или вычисление, или брать просто чтение из памяти. У Мультиклета это без задержек можно делать.

Вопрос: а есть теоретическая проработка компьютера, как иерархии кешей?

У меня такое ощущение, что они многое теряют, используя С в качестве ЯВУ.

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

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

ATS - эффективный, но стройный? Там же дичь дикая в синтаксисе. Читать этот код даже с поллитрой очень тяжело. Система типов там, конечно, кое что гарантирует, но не всё, особенно в арифметике. Поэтому код вычитывать надо, а это легко выворачивает мозг наизнанку.

Судьба Rust лично мне не очень понятна. Он концептуально тяжелее Си. При чём, в неправильном месте: на нём тяжело писать эффективные алгоритмы на сложных структурах данных. А борется он с теми проблемами, которые в мире Си легко решает POSIX-операционка. Rust, поэтому, хорошо было бы нацеливать на что-нибудь типа Boot 2 Gecko, в котором можно говорить: хопа-хопа, смотрите, у нас тут нет ядра и барьеров между userspace и железом. Но тогда у пользователей надо отбирать unsafe, а без unsafe в Rust ещё тяжелее.

Легче в таком Boot 2 Gecko писать на JavaScript. При чём, не факт, что будет потеря производительности. JavaScript нынче удивительно хорош. В общем, мне кажется, Rust будет нишевым языком. А следующая операционка будет жабаскриптовой. Вон там автор Android пилит что-то такое уже.

Без статической типизации люди обречены писать тесты.

при том тесты на абсурдность, что это функция и что она вызываема :D