ЯП, ОС, архитектура процессоров, инструкции

сгинь с лора троль

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

Какая каша.

ОС пишут на компиляторе ЯП

ОС пишут на языках, а не компиляторах.

Вот хочу я, например, свой процессор изобрести с уникальной архитектурой, значит ли это, что мне, минимум, придется портировать компилятор того же С?

Если будешь писать ОС на Си - да.

Ее корень - ядро, его пишут на ЯП, компилятор которого уже завязан на поддерживаемых им платформах (читай: ОС)

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

Вот хочу я, например, свой процессор изобрести с уникальной архитектурой, значит ли это, что мне, минимум, придется портировать компилятор того же С?

Нет, но тебе придётся написать оптимизации и кодогенерацию для, к примеру, LLVM.

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

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

А вообще, возьми https://class.coursera.org/compilers/lecture и книгу под названием «Engineering a Compiler».

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

Во-первых, удалось добиться не «безопасности вообще», а относительно большей безопасности по сравнению с С/С++, с (потенциально) сохранением производительности. В частности, Rust гарантирует поткобезопасность и безопасность обращения к памяти, но не гарантирует отсутствие утечек, хотя и минимизирует их возможность. Ради этого пришлось усложнить семантику введя лайфтаймы, сделать компилятор медленнее типичного С++-компилятора, и немножко пожертвовать производительностью в рантайме, например для контроля размера массива при обращении к элементу.

Сложновато объяснил, всё сводится к следующему вопросу: какими жертвами удалось добиться безопасности растом?

«Безопасность» раста означает, что там нельзя «расстрелять память» или устроить «data race» (если не использовать ансейф код). Достигается это некоторым ужесточением правил обращения со ссылками и проверками в рантайме, где без этого никак.

При этом надо понимать, что устроить циклические ссылки и как результат «утечку памяти» в расте вполне возможно.

сделать компилятор медленнее типичного С++-компилятора

Да ладно? По моему, компилятор раста куда быстрее, другое дело, что и оптимизаций они поменьше делают «пока что».

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

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

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

Но где эта грань завязанности? Банальные потоки в стандартной библиотеке раста - обертка потоков ОС. Т.е. если бы новая ОС была написана на расте, то пришлось бы писать нативные потоки на расте для компилятора раста?

Не для компилятора, но для стандартной библиотеки и, возможно, рантайма. Компилятор как таковой потоками не занимается.

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

Но где эта грань завязанности?

ХЗ, что такое «грань завязанности». Код, который «завязывается на ОС» (обращается к ней за обслуживанием) почти всегда пишется сознательно программистом.

Нет, но тебе придётся написать оптимизации и кодогенерацию для, к примеру, LLVM.

Раст построен на LLVM, но при этом раст может компилировать сам себя. Взять тот же GCC, на некоторых платформах он очень старых версий, т.е. компилируем старым версию поновее, а ей еще новее и т.д., в итоге придем к самой последней версии компилятора GCC. Можно ли такое сказать о «поддержка LLVM = поддержка Rust»?

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

Что мешает скомпилировать сразу скомпилировать свежий GCC, если он поддерживает данную платформу?

Можно ли такое сказать о «поддержка LLVM = поддержка Rust»?

В целом — да, раст доступен везде, где есть поддержка LLVM. Но стандартная библиотека зависит от ОС.

Ну а если нам надо пройтись по вектору целиком, то как и в С++ будет одна проверка, а не на каждой итерации.

В коде вроде такого?

for (i = 0; i < N; ++i) {
    f (arr[i]);
}

Итераторы же есть.

Не для компилятора, но для стандартной библиотеки и, возможно, рантайма. Компилятор как таковой потоками не занимается.

У меня всё находится на понятии курица или яйцо, портирование компилятора пока что магия. Так, архитектура X86, при включении устройства стартует загрузчик, он загружает ядро. Ядро должно что-то делать: сперва подгрузить драйвера. Куда и как их подгрузить? Работа с IO реализуется в ядре, ядро пустое. Тут вспоминаем о POSIX стандартах. Т.е. должны быть зарезервированы определенные имена для стандартных функций ОС, а также должен быть написан способ общения ядра и приложения. Этот POSIX будет заглушкой для тех же самых нативных потоков компилятора rust'а. Тут сразу встает вопрос, а что вообще можно использовать в расте для написания ядра ОС? Так, магическим образом подгрузили драйвера (хотя тот же видеодрайвер завязан на иксах или вяленом), далее запуск системы инициализации? Можно ли написать другое ядро с использованием поддержки железа от линукса? Или тут всё линуксо-специфично и придется самому портировть драйвера под новое ядро?

видеодрайвер завязан на иксах или вяленом

triple_facepalm.jpg

Почитай хоть какой-нибудь учебник по ОС.

Как тут с одной проверкой? Или имелся в виду другой код?

На «нормальном С++» такой код будет выглядеть примерно так:

for(auto& val : arr) {
    ...
}

for val in &arr {
    ...
}

В расте точно так же:

Не точно так же. В С++ ты задаешь тип, в том числе - по ссылке или нет, const или нет. Заодно можно сразу приводить к нужному типу. Т.е. точно так же как при объявлении переменных. В rust же ты указываешь только метод для итерации:

for val in arr.next()

Опять язык говорит тебе - забей уже на типы для переменных, ну и пусть во всяких Java, C#, C++ и пр. так принято, кто они такие, все так пишут.

Не правильно слово употреблено: не завязан, а поддерживается. Сюда же поддержка терминала. Лучше бы прокомментировал 2 предложения перед процитированным тобою куском текста, оно даже жирным выделено.

Не точно так же.

В плане проверок выхода за границы, а речь именно о них шла, именно так же. Хватит уже «воевать за явные типы» везде.

в том числе - по ссылке или нет, const или нет.

В расте точно так же. Плюс можно сам контейнер «переместить». Тип переменной действительно явно задать нельзя.

Опять язык говорит тебе - забей уже на типы для переменных

И много ты видел «range based for» с указанием типа в С++? Все пишут auto (в том числе в книгах) и правильно делают. Так что там язык говорит?

В расте точно так же. Плюс можно сам контейнер «переместить». Тип переменной действительно явно задать нельзя.

Не точно так же, не выдержан общий подход. Одни и те же вещи разруливаются разными способами.

Все пишут

http://st-im.kinopoisk.ru/im/kadr/1/1/7/kinopoisk.ru-Interstate-60-1171203.jpg

Пишут по разному, кто как лично для себя считает нужным.

Не точно так же, не выдержан общий подход. Одни и те же вещи разруливаются разными способами.

Не понял, объясни подробнее, что тебя смущает.

Пишут по разному, кто как лично для себя считает нужным.

Дык, я поинтересовался часто ли ты там указание типа видел. Мой опыт говорит, что никто его там не пишет. Опять же, про «навязывание» - в книгах предлагают писать именно так.

Не понял, объясни подробнее, что тебя смущает.

В for идет по сути объявление переменной. Как мы их объявляем?

let mut x : isize

Как мы пишем для параметров замыканий?

|mut x: isize| или (mut x: isize)

Как мы пишем для параметров функций?

(mut x: isize)

А для for сделали по-другому. Причем если говорить про C++, там можно написать:

auto f = []( auto i ) ->auto { return ++i; };
auto v = f( 1 );

А в rust нет.

Дык, я поинтересовался часто ли ты там указание типа видел

Да, хотя на самом деле еще далеко не везде range for вообще используется, совместимость со старыми компиляторами и все такое.

Ядро должно что-то делать: сперва подгрузить драйвера. Куда и как их подгрузить?

в память, конечно, куда ж еще.

Можно ли написать другое ядро с использованием поддержки железа от линукса? Или тут всё линуксо-специфично и придется самому портировть драйвера под новое ядро?

вообще да,

тут всё линуксо-специфично

но теоретически

написать другое ядро с использованием поддержки железа от линукса

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

линуксо-специфично

что это значит? фактически, это набор соглашений, которым следуют и ядро, и драйвера.

что вообще можно использовать в расте для написания ядра ОС?

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

А в rust нет.

Хотя нет, то меня клинит, иду спать.

Драйвера — части ядра. Ядро же обращается к оборудованию напрямую. Для обращения к оборудованию есть инструкции процессора, которые вызываются кодом на С или расте через ассемблер.
Приложения обращаются к ядру через системные вызовы (например, http://docs.cs.up.ac.za/programming/asm/derick_tut/syscalls.html). Которые, для кроссплатформенности и удобства использования обёрнуты в [стандартную] библиотеку. Которую ты и используешь в своём коде.
Компилятор ко всему этому отношения не имеет, он просто генерирует бинарный код для заданной архитектуры процессора.
Короче, читай «Современные операционные системы» Таненбаума.

Драйвера — части ядра

ИМХО так говорить некорректно, все же многие драйвера могут быть собраны в виде модулей. опять же, есть сторонние драйвера, которые частью ядра уж точно не являются (та же NVidia)

Для обращения к оборудованию есть инструкции процессора

для обращения к оборудованию уже успели наделать специальных инструкций? в те времена, когда я интересовался ассемблером и устройством процессоров (это было всякое вроде Z80 и 8086) я о таких не слышал. ну, разве что такими инструкциями считать IN/OUT, но, ЕМНИП, большая часть работы с оборудованием происходит через выделенные участки памяти.

Итераторы жи есть.

ИМХО так говорить некорректно, все же многие драйвера могут быть собраны в виде модулей. опять же, есть сторонние драйвера, которые частью ядра уж точно не являются (та же NVidia)

Модуль и есть часть ядра.

Вот хочу я, например, свой процессор изобрести с уникальной архитектурой, значит ли это, что мне, минимум, придется портировать компилятор того же С?

И только C. И добавить новую архитектуру — не портировать компилятор. И это будет так легко, что будет твоей наименьшей проблемой.

Ее корень - ядро, его пишут на ЯП, компилятор которого уже завязан на поддерживаемых им платформах (читай: ОС), значит ли это, что написать свое ядро на том же расте невозможно?

Не читай «ОС». Возможно.

но в данном случае он безопасный «на слово»

«сгинь с лора троль» ©

разве что такими инструкциями считать IN/OUT

Да, именно их я и вспомнил.

большая часть работы с оборудованием происходит через выделенные участки памяти

Кстати, как эти участки памяти привязывают к оборудованию?

Но где эта грань завязанности?

В сисколлах

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

что за говно я только что недочитал? еще одна заедушная макака прошла курс по операционным системам и ничего не поняла?

как эти участки памяти привязывают к оборудованию?

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

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

Лучше бы

В данном случае мне лучше знать, что советовать.

прокомментировал 2 предложения перед процитированным тобою куском текста, оно даже жирным выделено.

На Rust уже написана ОС - она учебная, но тем не менее. Есть и другие ядра на Rust. Читай учебники.

На Rust уже написана ОС

в этом ключе мне стало интересно: а существует ли язык (из более-менее живых), на котором еще не написана ОС

а существует ли язык (из более-менее живых), на котором еще не написана ОС

UNIX shell %)

А вообще - я не слышал об ОС на Python/Ruby/Perl/Lua/PHP, на Scala.

На Rust уже написана ОС

омайгадэбл, Данила!

Сложновато объяснил

потому что ты ничего не понимаешь

ОС на Python

pycorn, например. на Lua тоже, вроде, какие-то попытки были. такое впечатление, что существует какая-то олимпиада, участники которой должны написать ОС, но ЯП при этом не должен повторяться.

Кстати, как эти участки памяти привязывают к оборудованию?

DMA. Специальный контроллер

Сразу видно ЛОРовыкидыша, у которого в башке нет знаний, только слова, заимствованные из местных слабеньких тредов таких же бездарей.

Ну и не только DMA, в общем-то

https://en.wikipedia.org/wiki/Memory-mapped_I/O

Х...ёр. а не контролёр. Нафиг ты вообще про дма трындишь тут?

На «нормальном С++» такой код будет выглядеть примерно так:
for(auto& val : arr) {
...
}

Хорошо, сколько тут проверок?

ЯП, компилятор которого уже завязан на поддерживаемых им платформах (читай: ОС)

Завязка компилятора на ОС достаточно мала. Она выражается, ЕМНИП, в двух вещах:

1) Заголовок исполняемого файла. Его добавляет линковщик в последний момент и это легко изменить. Как пример - кросскомпиляция.

2) Соглашения о вызовах функций ОС. Тоже чисто механическая тасовка байтов.

А у тебя от этого проблемы? Или ты забыл принять лекарство?

Тут не нужны проверки. Ты итерируешься по существующей последовательности.

ОС на Python

pycorn, например

Насколько я могу судить, это не ОС, а просто Python на голом железе. Такие есть, конечно - MicroPython, например. И версии Lua такие есть.