Применительно к ядру насчёт терминологии не соглашусь. Точней, объявить-то можно, но вопрос заключается в режиме работы процессора при исполнении этого кода: именно он определяет, ядро это (работа в привилегированном режиме) или не ядро (работа в непривилегированном режиме). В остальном -- да, согласен.
На самом деле, ядро даже не обязано целиком быть в памяти. Скажем, в древней OS/360 (вообще, кажется, первая "большая" и "настоящая" ОС в истории) и во вполне современной Винде часть кода ядра находится в памяти постоянно, а часть -- по нужде (хотя механизмы подгрузки/выгрузки кода пространства ядра в этих двух системах кардинально различаются).
Во-первых, если писать обзорную статью и говорить о "сферической ОС в вакууме", то останавливаться на сегментации, применяемой в интеловской архитектуре (IA-32 aka x86), нет никакого смысла: рассказывать надо об общих идеях, а не о специфических реализациях. То же относится к конкретным разновидностям файловых систем и т.д. и т.п.
Во-вторых, останавливаться в обзорной статье на интеловском механизме сегментации смысла нет ещё и потому, что 1) он специфичен для интеловской архитектуры, и в других архитектурах ничего подобного нет; и 2) он оказался крайне неудачным, и им пользовались только потому, что были вынуждены. Когда появился 80386 с его нормальным MMU "как у всех", от сегментации, по сути, отказались и используют плоское адресное пространство. Естественно, технически без сегментации обойтись всё равно невозможно, так как этого требует аппаратура, но сегментные регистры настраиваются ОС так, что используется единое плоское адресное пространство -- т.е. технически сегментация есть, а логически -- нет. Ну а AMD, расширяя архитектуру до 64 битов, в 64-разрядном режиме вообще сегментацию, по большому счёту, выпилила: если память не изменяет, FS и GS можно использовать как дополнительные базовые регистры, но сегментов как таковых, со всеми их атрибутами, уже нет; они сохраняются только в 16/32-разрядных режимах для обеспечения обратной совместимости.
Ну а в-третьих, в "ранних компьютерных системах" сегментной модели как раз не было. Когда появилась поддержка виртуальной памяти, она сразу была организована по страницам, причём у разных архитектур отличия лишь технические, но не концептуальные. Сегментацию, вполне возможно, придумала Интел -- и ничего хорошего из этого не вышло. (Замечу попутно, что под сегментацией и в статье, и мною понимается то, как это определено в интеловской архитектуре; само слово "сегмент" применяется и в других архитектурах, но имеет совершенно иной смысл. Например, в IBM System/370 таблицы переадресации, лежащие в основе работы MMU, имеют два уровня: на нижнем лежат таблицы страниц, а на верхнем -- таблицы сегментов; в современной IBM z/Architecture уровней уже пять: помимо классических таблиц сегментов и страниц, пришедших с некоторыми расширениями из Системы 370, там реализовали три уровня таблиц регионов, чтобы эффективно управлять всем 64-разрядным виртуальным адресным пространством).
Проблема не только в компиляторах, но и в том, что процессор выполняет программу не в сферическом вакууме, и всего не предусмотришь. Наиболее очевидная проблема -- конфликты при доступе к памяти. Если программе нужен доступ к области памяти, которой нет в кэше, приходится обращаться к реальной памяти, а это не только во много раз медленнее само по себе, но может натолкнуться на одновременный доступ со стороны других процессоров или периферии, использующей DMA, -- и, как следствие, выполнение операции доступа к памяти придётся задержать на довольно неопределённый срок. Если VLIW не может завершить выполнение текущего "командного слова" до тех пор, пока не будут выполнены все заданные операции, проц, очевидно, вынужден стоять и ждать завершения обращения к памяти. Классический суперскалярный проц с внеочередным выполнением в такой ситуации стоять не будет -- он продолжит выполнять команды, расположенные уже после ожидающей операции доступа к памяти, если между ними нет зависимости по данным.
Ну, списывать кусками, не особо вникая в смысл, не очень затратно по времени. Правда, на выходе нередко получается чушь, ведь для грамотной компиляции надо и самому быть в теме.
Ну, откуда современному подростку знать, что собрать свой компутер в СССР можно было, только украв детали на родном предприятии? В магазинах были только лампы с транзисторами да несколько типов усилительных микросхем, логики не было вообще, а уж про КР580ВМ80А можно и не вспоминать. Где-то видел воспоминания создателей "Микро-80": к ним в контору случайно отправили совершенно неведомую микросхему К580ИК80 (название первого варианта того самого КР580ВМ80А), которой не было ни в каких справочниках, но, поскольку они по долгу службы имели доступ к забугорной информации, кто-то связал 580 и 80 с интеловским 8080 -- ну, они по интеловской документации и слепили свой компутер. По сути, они для собственного развлечения украли и случайно попавший к ним микропроцессор, и кучу других микросхем, к которым имели доступ по работе.
Всех источников не найдёте никогда, ну а многие доступны только в архивах. И даже если основываться только на открытых источниках, придётся потратить, наверное, несколько лет, чтобы "войти в тему", а не писать тот бред, что был написан.
У буржуинов ферритовую память окончательно сняли с производства, если не ошибаюсь, в 2018-м. Вояки везде очень долго сидят на старой технике: им же надо, чтоб работало, а не чтоб котики в тырнетах.
А как, например, поступать, когда есть обычный большой открытый мир (где, как понимаю, вполне достаточно автоматической загрузки/выгрузки, что сделает World Partition), но при этом есть дома/пещеры/телепорты, и есть желание для ускорения процесса перемещения игрока ручками подгружать на всякий случай дополнительные уровни, которые для автомата не будут очевидными?
И конвейеры, и FIFO я встречал именно в советской литературе -- только за давностью лет уже не скажу, в какой. Плюс, более-менее устройство конвейерного проца расписано, по меньшей мере, применительно к ЕС-1050/1052, о чём надеюсь как-нибудь написать серию статеек -- но это уже не учебник, конечно, был.
Любой микроконтроллер с архитектурой ARM имеет флэш-память -- которая вполне себе неизменяемая (ну да, в неё можно записать, но путём плясок с определёнными регистрами и т.п., а не простым выполнением команды записи по адресу).
Если сами исходные данные в процессе выполнения функции меняются -- да. Но если они являются, по сути, константами (те же строковые литералы) -- нет, и их копирование является излишним.
Это да, но в данном случае я сравнивал переменные, объявленные внутри функции (где static определяет время жизни), с переменными вне функции (где время жизни от наличия или отсутствия static не зависит) -- ведь обсуждение идёт про создание и инициализацию, что зависит от времени жизни, но не от области видимости.
Применительно к ядру насчёт терминологии не соглашусь. Точней, объявить-то можно, но вопрос заключается в режиме работы процессора при исполнении этого кода: именно он определяет, ядро это (работа в привилегированном режиме) или не ядро (работа в непривилегированном режиме). В остальном -- да, согласен.
На самом деле, ядро даже не обязано целиком быть в памяти. Скажем, в древней OS/360 (вообще, кажется, первая "большая" и "настоящая" ОС в истории) и во вполне современной Винде часть кода ядра находится в памяти постоянно, а часть -- по нужде (хотя механизмы подгрузки/выгрузки кода пространства ядра в этих двух системах кардинально различаются).
Во-первых, если писать обзорную статью и говорить о "сферической ОС в вакууме", то останавливаться на сегментации, применяемой в интеловской архитектуре (IA-32 aka x86), нет никакого смысла: рассказывать надо об общих идеях, а не о специфических реализациях. То же относится к конкретным разновидностям файловых систем и т.д. и т.п.
Во-вторых, останавливаться в обзорной статье на интеловском механизме сегментации смысла нет ещё и потому, что 1) он специфичен для интеловской архитектуры, и в других архитектурах ничего подобного нет; и 2) он оказался крайне неудачным, и им пользовались только потому, что были вынуждены. Когда появился 80386 с его нормальным MMU "как у всех", от сегментации, по сути, отказались и используют плоское адресное пространство. Естественно, технически без сегментации обойтись всё равно невозможно, так как этого требует аппаратура, но сегментные регистры настраиваются ОС так, что используется единое плоское адресное пространство -- т.е. технически сегментация есть, а логически -- нет. Ну а AMD, расширяя архитектуру до 64 битов, в 64-разрядном режиме вообще сегментацию, по большому счёту, выпилила: если память не изменяет, FS и GS можно использовать как дополнительные базовые регистры, но сегментов как таковых, со всеми их атрибутами, уже нет; они сохраняются только в 16/32-разрядных режимах для обеспечения обратной совместимости.
Ну а в-третьих, в "ранних компьютерных системах" сегментной модели как раз не было. Когда появилась поддержка виртуальной памяти, она сразу была организована по страницам, причём у разных архитектур отличия лишь технические, но не концептуальные. Сегментацию, вполне возможно, придумала Интел -- и ничего хорошего из этого не вышло. (Замечу попутно, что под сегментацией и в статье, и мною понимается то, как это определено в интеловской архитектуре; само слово "сегмент" применяется и в других архитектурах, но имеет совершенно иной смысл. Например, в IBM System/370 таблицы переадресации, лежащие в основе работы MMU, имеют два уровня: на нижнем лежат таблицы страниц, а на верхнем -- таблицы сегментов; в современной IBM z/Architecture уровней уже пять: помимо классических таблиц сегментов и страниц, пришедших с некоторыми расширениями из Системы 370, там реализовали три уровня таблиц регионов, чтобы эффективно управлять всем 64-разрядным виртуальным адресным пространством).
Проблема не только в компиляторах, но и в том, что процессор выполняет программу не в сферическом вакууме, и всего не предусмотришь. Наиболее очевидная проблема -- конфликты при доступе к памяти. Если программе нужен доступ к области памяти, которой нет в кэше, приходится обращаться к реальной памяти, а это не только во много раз медленнее само по себе, но может натолкнуться на одновременный доступ со стороны других процессоров или периферии, использующей DMA, -- и, как следствие, выполнение операции доступа к памяти придётся задержать на довольно неопределённый срок. Если VLIW не может завершить выполнение текущего "командного слова" до тех пор, пока не будут выполнены все заданные операции, проц, очевидно, вынужден стоять и ждать завершения обращения к памяти. Классический суперскалярный проц с внеочередным выполнением в такой ситуации стоять не будет -- он продолжит выполнять команды, расположенные уже после ожидающей операции доступа к памяти, если между ними нет зависимости по данным.
Всё вокруг колхозное, всё вокруг моё (с)
Ну, списывать кусками, не особо вникая в смысл, не очень затратно по времени. Правда, на выходе нередко получается чушь, ведь для грамотной компиляции надо и самому быть в теме.
Ну, на самом деле, не так уж и много таких мест было. В Москве и прочих крупных городах -- ещё куда ни шло, а в провинции?
Ну, откуда современному подростку знать, что собрать свой компутер в СССР можно было, только украв детали на родном предприятии? В магазинах были только лампы с транзисторами да несколько типов усилительных микросхем, логики не было вообще, а уж про КР580ВМ80А можно и не вспоминать. Где-то видел воспоминания создателей "Микро-80": к ним в контору случайно отправили совершенно неведомую микросхему К580ИК80 (название первого варианта того самого КР580ВМ80А), которой не было ни в каких справочниках, но, поскольку они по долгу службы имели доступ к забугорной информации, кто-то связал 580 и 80 с интеловским 8080 -- ну, они по интеловской документации и слепили свой компутер. По сути, они для собственного развлечения украли и случайно попавший к ним микропроцессор, и кучу других микросхем, к которым имели доступ по работе.
На сайте "виртуального компьютерного музея", пожалуй, наиболее полный набор из того, что есть в открытом доступе.
Всех источников не найдёте никогда, ну а многие доступны только в архивах. И даже если основываться только на открытых источниках, придётся потратить, наверное, несколько лет, чтобы "войти в тему", а не писать тот бред, что был написан.
Вероятно, работали там, где Кобол не нужен. Я, наоборот, работал там, где только на Коболе и писали -- сплошь экономические задачи.
А я для той же задачи прошил несколько К155РЕ3 :)
У буржуинов ферритовую память окончательно сняли с производства, если не ошибаюсь, в 2018-м. Вояки везде очень долго сидят на старой технике: им же надо, чтоб работало, а не чтоб котики в тырнетах.
А как, например, поступать, когда есть обычный большой открытый мир (где, как понимаю, вполне достаточно автоматической загрузки/выгрузки, что сделает World Partition), но при этом есть дома/пещеры/телепорты, и есть желание для ускорения процесса перемещения игрока ручками подгружать на всякий случай дополнительные уровни, которые для автомата не будут очевидными?
Средства синтеза учитывают. С большей или меньшей степенью успеха.
И конвейеры, и FIFO я встречал именно в советской литературе -- только за давностью лет уже не скажу, в какой. Плюс, более-менее устройство конвейерного проца расписано, по меньшей мере, применительно к ЕС-1050/1052, о чём надеюсь как-нибудь написать серию статеек -- но это уже не учебник, конечно, был.
Дефайнить типы -- в любом случае зло. Ничто не мешает в чистых сях typedef использовать для простых типов, а не только для структур.
Любой микроконтроллер с архитектурой ARM имеет флэш-память -- которая вполне себе неизменяемая (ну да, в неё можно записать, но путём плясок с определёнными регистрами и т.п., а не простым выполнением команды записи по адресу).
Если сами исходные данные в процессе выполнения функции меняются -- да. Но если они являются, по сути, константами (те же строковые литералы) -- нет, и их копирование является излишним.
Это да, но в данном случае я сравнивал переменные, объявленные внутри функции (где static определяет время жизни), с переменными вне функции (где время жизни от наличия или отсутствия static не зависит) -- ведь обсуждение идёт про создание и инициализацию, что зависит от времени жизни, но не от области видимости.