Как процессор понимает ОС?

Question

[Moro Zota]

Объясните пожалуйста. Если к примеру ядро unix написано на Си, а процессор понимает только двоичную систему счисления, то как тогда всё это работает?
Процессор же не может понимать компилятор который тоже написан на яп.

Comments

[Johny Smith]

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

[Александр]

Olek1, процессор работает на электричестве. Любой язык программирования - абстракция над электрическими сигналами процессора/памяти.

[Johny Smith]

Александр,

процессор работает на электричестве.

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

[Михаил Усоцкий]

Вообще-то, у процессора всегда существует система команд, чтобы мог понимать, как выполнять ту или иную операцию. А операционные системы содержат набор последовательностей команд. А язык программирования необходим для задания последовательностей выполнения. А компилятор переводит написанный программистом код в последовательность команд, понятный для процессора. Чтобы процессор мог выполнять код, всегда надо компилировать код программы в последовательность двоичных кодов. Нельзя так просто взять и скормить ядро Unix на Си процессору. Написанное на СИ ядро всего лишь общее, как должна работать операционная система вне зависимости от архитектуры процессора с его набором команд.
Компилятор - это программа, где уже задана последовательность выполнения команд, для перевода исходного кода на Си в машинный код. Компилятор тоже не появился на пустом месте, он развивался вместе с языками программирования. Нет языка программирования - нет компилятора. Если раньше программисты писали алгоритмы и рисовали на черновиках, а затем переводили вручную в машинный язык (перфокарты и перфоленты), то сейчас компиляторы делают сами, а программисту остаётся только проверять результат выполнения.
Мне кажется, что вы пропустили целые разделы прежде, чем задавать подобные вопросы. Вы должны изучить, как вообще работают процессоры и микроконтроллеры. Потом изучить язык ассемблера и системного программирования. А потом изучить вопрос, что такое вообще программа и с чем её едят.

[Moro Zota]

Михаил Усоцкий, может вы подскажите материалы для чтения ?

[Александр]

Olek1,

опкод вроде самая мелкая единица в этой цепи

https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D...

[Johny Smith]

Александр, ооооооо

[Михаил Усоцкий]

Moro Zota, книга по процессорам: Современные микропроцессоры Корнеев В.В., Киселев А.В. Там достаточно хорошо разъясняют, как работают процессоры, в том числе и современные. Чтобы поближе понять, как работает процессор, можно потренироваться на ассемблере (подойдёт любая книга по ассемблеру для x86/x86-64). Вроде ещё на Linux есть специальная программа-эмулятор, которая визуально показывает, как меняется состояние процессора. Также можно потренироваться на современных микроконтроллерах (по сути, они тоже являются процессорами, только адаптированы для узких задач) типа MCS51 или ARM. Любой написанный код, скомпилированный и загруженный в устройство становится программой. А чтобы продвинуться дальше, чтобы понять, что такое операционная система, то лучше будет потренироваться на микроконтроллерах ARM что-то из семейства Cortex-M. Для него есть исходный код операционной системы реального времени RTOS. Она достаточно маленькая, чтобы разобраться в базовых частях. А как освоите, можно попробовать осилить Minix вместе с книгой Современные операционные системы Эндрю Таненбаума уже для компьютера.

Answer 1

[pfg21]

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

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

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

компиятор тоже написан на "человеческом языке" и потом скомпилирован в исполняемый файл.

Comments

[Игорь]

поток команд исполняемых процессором с трудом понимает человек-програмист.

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

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

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

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

гораздо больше

[jcmvbkbc]

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

Чувак, 25 лет назад я, будучи школьником, написал ассемблер (программу) в машинном коде. И многие мои знакомые делали тогда что-то подобное. Это было в порядке вещей. Уверяю тебя, этот уровень разумности никуда не исчез.

[pfg21]

"в советское время и трава была зеленее !!" :) так и думал что фраза слишком короткая и кривая.

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

ну распечатай бинарь в hex-коде и попробуй его прочитать :)
даже в дебагере ассемблерное представление машинных кодов придется долго допиливать для понимания.
как минимум надо расставить текстовые имена переменным и функциям, а это неплохо жрет время.
даже из активного embedded ассемблер уже ушел и используется только для дебага.
Игорь, тогда приведи пример проекта на несколько тысяч строк на ассемблере, сделанного в последние года :) мне действительно интересно если еще такое, ибо выпал из той среды.
jcmvbkbc вполне верю, ибо в те времена других средств разработки практически не было.
в универе были стандартные лаболаторки, на которых надо было продумать алгоритм, написать ассемблерную прогу, правильно распихать переменные между памятью и регистрами, преобразовать ассемблер в машинные коды. ввести все енто в 16ричном в УМПК-80 и запустить с аппаратным дебагом.
иэх веселые *опы вылезали на элементарнейших алгоритмах.
но сейчас совершенно другие времена....

[Валентин]

jcmvbkbc, а что ты там писал? транслятор мнемоник в байт-код? Так это пофакту "найти-и-заменить".

[jcmvbkbc]

написать алгоритм в командах проуцессора

а что ты там писал?

Валентин, какая разница? Алгоритм? -- алгоритм. В командах процессора? -- в командах процессора.

Так это пофакту "найти-и-заменить".

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

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

[#]

pfg21, году в 90м.. написал свой драйвер клавиатуры под дос (3,3 тогда).. потом правил... и он даже попал в раздачу региональным сборщикам компов (после снятия эмбарго)..
назвал тогда keyb866...
фишка была в размере - кажется 800 байт в оперативе.. это при том что досовский занимал 6 или 8 килобайт.. тогда был резон драться за каждый килобайт )))
.. вторая фишка была в том, что у нас в принципе был проект по портированию дос, путем эмуляции биос, на отечественную машинку..
.. я был потрясен, что встроенную функцию биос (int 15) ни кто в нешенел дровах клавы так и не использовал..

[pfg21]

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

Answer 2

[Александр]

Если к примеру ядро unix написано на Си, а процессор понимает только двоичную систему счисления, то как тогда всё это работает?

Компилятор, компиляция
Операционная Система

Comments

[Johny Smith]

мне кажется там не всё на Си написано а много на ассемблере всё что связано с процессором, потому что там нужна максимальная скорость

[Александр]

Olek1, https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D...

[awesomer]

Olek1,

мне кажется там не всё на Си написано а много на ассемблере всё что связано с процессором, потому что там нужна максимальная скорость

это было в те времена.
тогда сначала компиляторы не достаточно оптимально выводили код.
а потом и люди не могли поверить, что компиляторы достаточно хороши и продолжали лабать вручную.
потом просто было много когда и его было проще поддерживать чем переписывать с нуля.
сейчас бы то же самое вполне прекрасно можно было бы реализовать на чистом С с минимальнейшими вкраплениями ассемблера.
в Linux/FreeBSD не так уж много ассемблерного кода.

Answer 3

[Андрей Буров]

https://nsu.ru/xmlui/bitstream/handle/nsu/9054/tan...

Answer 4

[#]

далеко не всегда правильно ))

(по тому так часты патчи/апдейты во всех системах)

однако вы не верно циклитесь на языке "на котором написана ОС".. после того как "ОС написана" - она скомпилирована

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

есть особый случай - jit-компиляция (обычно это означает компиляцию "на лету") (node.js, .Net).. а еще есть "интерпретация" (js, python)

Comments

[Александр]

А еще когда то был .COM, являющийся сырым сегментом памяти из реального режима, за вычетом первых 256 байт, которые формировала ОС.

[#]

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

[Александр]

Шарпер, Ну, кто его знает... Самый распоследний i9 до сих пор стартует из реального режима.

[#]

Александр, эмм... сколько вакансий в топе hh.ru где это будет первым фактором? ))

ps если найдете хоть одну в первой десятке - да, я погорячился ))

но не по тегам i9+asm.. но, допустим "программист".. ;))

[Александр]

Шарпер, если мыслить только вакансиями, мы бы до сих пор работали на строительстве пирамид =)

[#]

Александр, сам обучался с асма.. и компилеров )).. даже был в больших интересных проектах )) ... которые не взлетели (Ульяновский Центр Микроэлектроники) даже прикольно, что в отделе, был отдан в подручные, мужику, который писал интерпретатор BIOS для "не совсем совместимой платформы" - там была рабочая станция, "Афтограф 1840" содранная с СЕКАПы (а не с писюков)... со многими вытекающими последствиями
... однако, интерпретатор был написан и запущен, (я наваял нн-ое количество демок на турбопаскале, котороые тоже были и приняты, и приложены)... но и че толку?

ща вот "байкал" впаривают госструктурам

Answer 5

[АртемЪ]

Если к примеру ядро unix написано на Си, а процессор понимает только двоичную систему счисления, то как тогда всё это работает?

Работает очень просто- процессор исполняет машинный код.

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

Comments

[Johny Smith]

Не машинный код, а микрокод, машинный код уровнем выше, инструкции процессору может содержать и язык ассемблера

[АртемЪ]

Olek1, Чем отличается микрокод от машинного кода? Первый раз слышу такой термин.

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

Любой язык даже PHP содержит инструкции процессору.
Но процессор понимает только машинный код.

[Johny Smith]

АртемЪ,

Чем отличается микрокод от машинного кода?

Не углублялся, но интересно

[Mercury13]

Olek1, АртемЪ,
Современные процессоры работают по микрокомандному принципу. Один из блоков переводит команды машинного кода в команды для всех остальных блоков по определённым правилам. Вот эти правила, которые хранятся в особо быстродействующем ППЗУ — это и есть микрокод.

Микрокод позволяет ускорить работу процессора ценой удлинения конвейера, и позволяет программно запатчивать ошибки в процессорах. Почему Meltdown не запатчили? Потому что это подслушивание по сторонним каналам (никакой ошибки в логике нет), проблема во внеочередном исполнении команд (а вот не в курсе, контролируется ли это микрокодом), и в некоторых процессорах Meltdown если не закрыли, то облегчили.

[АртемЪ]

Mercury13,

Вот эти правила, которые хранятся в особо быстродействующем ППЗУ — это и есть микрокод.

Ну что такое микрокод в плане того, что это прошивка процессора, его внутренний код, я в курсе.

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

[Михаил Усоцкий]

Olek1, не всегда и не везде. У RISC-процессоров нет микрокода. В качестве примера таковыми являются процессоры MIPS. Так как система команд у них весьма простая, что можно обойтись всего лишь исполнительными блоками. А вот у CISC-процессоров, да, есть микрокод. Но это всё связано с историческим аспектом. Когда появились первые процессоры x86, Motorolla 6800x0 инженеры старались делать наборы команд так, чтобы не занимать много памяти (тогда память была совсем крошечной). Но платой стал то, что каждый микрокод всегда выполнялся за несколько тактов за несколько микроопераций. Например, атомарная операция со значением из памяти (упрощённо) одной командой: загрузка в аккумулятор, арифметическая операция над аккумулятором, загрузка в память. В RISC-процессорах такого нету. Для этого надо задействовать все три команды.
В современных процессорах x86/x86-64 используются изощрённые методики по ускорению выполнения операций. Но платой стал огромный декодер команд. Но зато большая часть простых и средних команд можно выполнять за такт или даже несколько операций за такт. Правда в первое время процессоры сильно страдали перегревом. В процессорах Core iX используется несколько хитрый приём: декодированные команды сохраняются в кэш-память, и остаются до востребования. Таким образом поток команд уже по нескольку раз не приходится декодировать, поступают сразу в исполнительные блоки. Поэтому инженеры и сумели снизить теплопакет.
P.S. В качестве дополнения могу сказать, что существуют и другие типы процессоров помимо RISC и CISC. Например, VLIW. Это, по-сути дальнейшее развитие RISC-процессоров с EPIC-архитектурой. Имеет все возможности CISC-процессора, но нет декодера команд как такого и имеет очень длинное командное слово вместо кода операции. И это всё поступает сразу напрямую в исполнительные блоки. Такой процессор греется куда меньше. Но и плотность кода ниже (требуется больше памяти) и очень сложный компилятор (надо сказать, что компилятор для VLIW-процессоров - самый сложный из всех). Но плюсом станет то при хорошей оптимизации компиляции хорошая производительность и низкие температуры.

[Mercury13]

АртемЪ,

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

Если только в технических и отладочных режимах. В нормальной работе нельзя.

[Ингвар]

Язык программирования это удобный для человека язык

не для каждого человека )

[Johny Smith]

Ингвар Воржев, и не каждый язык ))

Malbolge, Hello, World!:

('&%:9]!~}|z2Vxwv-,POqponl$Hjig%eB@@>}=<M:9wv6WsU2T|nm-,jcL(I&%$#"
`CB]V?Tx<uVtT`Rpo3NlF.Jh++FdbCBA@?]!~|4XzyTT43Qsqq(Lnmkj"Fhg${z@>

Answer 6

[Станислав Бодро́в]

Как процессор понимает ОС?

С трудом это делает. ОС универсальные рассчитанные под всевозможные и даже невозможные задачи, процессоры тоже. И не всегда это совпадает.

процессор понимает только двоичную систему счисления

Брехня! Процессор поднимает только перепады потенциала в строго определённом уровне. Что там будет какая логика, камню до лампочки.

Процессор же не может понимать компилятор который тоже написан на яп.

Обычно вначале идёт ОС, а потом компилятор. Операционка абстрагирует полностью оборудование от кода приложений. Поэтому голову, над тем что выложил компилятор, ломает операционка. Вначале себе, потом процессору.

Answer 7

[Johny Smith]

Как процессор понимает ОС?

Только через драйвер