Процессор для изучения ОС

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

Пустая трата времени. Послушай старого и больного человека. :)

есть ли эмулятор процессора+периферии?

qemu?

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

Вопрос не в том, есть ли вообще эмулятор (так-то Bochs лучше qemu, так как, емнип, эмулирует работу процессора полностью), а есть ли эмулятор для той самой «идеальной» архитектуры? То есть есть ли следующая связка: «архитектура без костылей» + эмулятор процессора этой архитектуры и периферии под него.

Это реально пустая трата времени. Просто поверь.

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

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

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

Может и пустая, но интересная. ;)

Тот же AVR годится для написания примитивных OS, и познания, как оно работает.

Примет: моя маленькая multitasking soft-rt os для avr: http://www.dim13.org/cgi-bin/cvsweb/src/avr/kernel/

Но не абсолютно. Иначе б Линус не стал отцом linux-а. Но ему просто повезло. Скажем так: это лотерея.

А ты уверен, что вообще хочешь именно ковыряться в железе? Насколько я понимаю, ты хочешь изучить именно операционные системы, а не аспекты работы в них с железом. Почему бы не написать мини-ОС, работающую внутри основной системы через твой же простейший эмулятор нужных фич железа?

Не слушай клоунов, которые только php и могут осилить.

под какую архитектуру писать?

Любую. Можно взять что-нибудь простое, типа AVR (atmel'овские мк, тот же arduino и клоны).

а есть ли эмулятор для той самой «идеальной» архитектуры?

Поскольку описания той самой «Идеальной» архитектуры не существует, то будь мужиком - напиши эмулятор!

Хм, а вот это уже интереснее. Вы правы в том, что работа с железом, не очень приятная вещь (поэтому я и ищу архитектуру с минимальным количеством костылей), но можно ли реализовать, например, определенное управление памятью через эмулятор? Меня интересует больше архитектура ОС, чем как она работает с регистрами и дёргает прерывания. Потом, если всё же реализовывать своё эмулятор, то как он должен выглядеть? Что-то a la интерпретатор машинных кодов?

А есть хорошие, точные эмуляторы AVR? Или брать макетку и делать не ОС, а «компьютер» сразу?

Как хочешь, так и делай. Я бы сделал эмулятор как библиотеку: нужно такое-то действие от железа — дёргаю такую функцию из библиотеки. А библиотека уже либо либо дёргает хост-систему, либо что-то делает со своим внутренним состоянием.

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

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

Нахрен недо? Лучше книжку почитай.

+

Лучше книжку почитай

О вкусной и здоровой пище? Пусть лучше ОС пишет

ТС, пиши для x86, остальное такое же УГ только информации про него меньше

То есть некоторая виртуальная машина?

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

А чем он лучше того же AVR?

Кстати, а если взять какой-нибудь softcore processor? OpenRISC или PicoBlaze?

В некотором смысле да.

Чуть более удобен для программирования на ассемблере чем tinyAVR (CISC vs RISC). Хотя если ты будешь писать на C, бери лучше AVR32 или ARM (только не rpi).

купи себе SBC (single board computer) который втыкается в PCI/PCI-x и наслаждайся написанием драйверов для него и хост-машины.

А в чем преимущество перед макетной платой с каким-нибудь ARM? И сколько они ст́оят (на pci)?

Может и пустая, но интересная. ;)

Ну вот если есть интерес к системным вещам, то лучше сразу направлять усилия на практически значимые задачи. Тема ОС минимально наукоемкая. Чего там изучать, мне совершенно непонятно. Если уж касаться этой темы, то лучше сразу вливаться в реализованные проекты. Но писать свою ОС... Зачем?

У нас на кафедре а Бауманке, когда я учился, аспиранты написали свою многозадачную операционную систему для своих нужд (касалось телеметрии). Потом я с ними беседовал, они мне говорили, что это, конечно, было пустой тратой времени. Какой-то опыт кем-то получен, а применить его некуда. Молодость только зря прожгли. Я вот тоже прожигал так, а сейчас сижу и жалею, молодежь удерживаю от распыления энергии, хе-хе. :)

Тот же AVR годится для написания примитивных OS, и познания, как оно работает.

А чему это поможет? Этот опыт испарится вместе с AVR. Да и ОС для AVR, ИМХО, какое-то дикое извращение. А для тех архитектур, для которых есть смысл в ОС, она уже как бы есть. Надо только влиться.

А в чем преимущество перед макетной платой с каким-нибудь ARM? И сколько они ст́оят (на pci)?

А зачем деньги тратить? ARM на QEMU можно гонять. Например, Android Emulator вроде на базе QEMU сделан. AVR можно на simavr или simulavr. Прямо живые прошивочки гонять. У меня на simavr модель железки вертится. Вот тут кратенько описывал в посл. абзаце и по ходу где-то.

Чтобы вливаться в проекты нужен хоть какой-нибудь опыт, а максимум что я сделал был простенький загрузчик для x86, который считывал с определенного адреса на дискете elf, и разбирал его без всяких проверок на корректность архитектуры и т.п. После чего он прыгал на сишный код, но дальше дело не пошло, потому что любой код на Си, использующий указатели, отказывался работать.

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

ARMv8 обещает сервера с маленькими куллерами и мощные мобильные устройства, но есть мнение, что Intel перейдёт на 5 нМ техпроцесс и сервера на ARM будут сливать в производительности.

Истина где-то рядом. Я бы учил ARMv8 на примере Linux. Архитектура новая. Проектировалась с учётом ошибок прошлого. Может исполнят ARMv7 код, но система грузится новым набором инструкций и если ARMv8 так крута, как про неё говорят, то за ней будущее. И легаси в ней меньше, т.к. набор инструкций со старым не совместим.

Чтобы вливаться в проекты нужен хоть какой-нибудь опыт

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

Есть такая scmRTOS, есть и FreeRTOS. Очень советую начать с них - процессоры 8-ми битные такие примитивные, но главная суть работы ОС (любой распространенной) будет ясна. По ним есть книжки с отличным описанием, разжевано до мелочей. А вот про Linux тоже есть книги хорошие, дает понимание как решены все проблемы на многопроцессорных системах.

Про x86 vs ARM я скажу что не советую тебе вот так упрощенно вершить судьбы процессорного рынка...

(любой распространенной)

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

А вы какие операционные системы собираетесь изучать? И на каком уровне ? Если *nix то учите всякие шелы, топы, псы, sysctl (для линукса /proc /sys). Если вындовс - то реестры, повершелы, netsh и тд. Если хотите знать как работает система на уровне ядра - изучайте ее на уровне конкретного ядра (ядро FreeBSD != OpenBSD != Linux - есть много чего похожего но всеже отличий тоже довольно много). Если хотите знать как работает ОС на конкретном железе - изучайте как работает эта ОС на этом железе (x86/AMD64, ARM, Itanium, Power ...) - а если вы напишете чтото что можно будет назвать ОС для AVR - то вы будете имень предстовление о том что из себя представляет AVR на низком уровне. Если это то что вы хотите получить в результате - вперед.

Я хочу изучить ядра, а именно их архитектуры (сюда входят разновидности планировки задач, памяти etc). Про уровень: если это «степень» изучения, то хотелось бы, например, уметь писать свой ipc с блекджеком.

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

IPC - в ядре какбы и нету вовсе, в разных ядрах разных ОС есть различный API который можно использовать для IPC (если это posix совместимые системы то должны быть сигналы, шареная память, пайпы, *nix сокеты, семофоры ...). Но с точки зрения ядра (linux) выделить отдельный модуль и сказать что вот он обеспечивает IPC там такого нету. Шаред мемори - лежит в менеджере памяти, семофоры вообще платформозависимы, сокеты рядом с сетевым стеком и тд. И опять таки их внутрення реализация в разных ОС разная (FreeBSD, Linux, и тд). И даже если ты все это реализуеш - я не вижу практической пользы от этого. Для того чтобы понять какие там есть подвойдные камни и проблемы - их нужно активно использовать и смотреть что не устраивает и что нужно менять.

Тема ОС минимально наукоемкая. Чего там изучать, мне совершенно непонятно.

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

retrobsd

DUINOMITE-MEGA

А в чем преимущество перед макетной платой с каким-нибудь ARM?

- фактически это полноценный комп с той-же архитектурой и на нём можно пускать такую-же «убунточку». А можно с хоста грузить чё-нить своё и при этом «прошиватор» не нужен

- с хост-машиной общается очень быстро и на него можно перекладывать числодробилки с хоста. Если удастся воткнуть более 1-й ( хватит питания, разъёмов на хосте и нет каких-нить конфликтов по шине) получается кластер.

недостатки - ровно теже :)

если цель - просто «тренироваться на кошках», без определённой практической задачи, то вам всё равно что использовать.

Если уж ограничиваться 8-ю битами, то лучше взять что-то вроде MOS 6502 — там реализовано 13 способов адрессации, включая косвенные и относительные, которые добавила Zilog в свой Z80 по сравнению с 8080.
У i8080/8085 со способами адрессации всё печально - там нет относительной адрессации и куча драгоценной памяти уйдёт на обслуживание перемещения исполняемого кода по адресному пространству, и в результате всё равно получится хрень с какими-то ограничениями.

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

Но если архитектура та же, то чем оно лучше эмулятора? Производительность меньше, но она не нужна, для самописной ОС. К тому же у меня основной рабочик компьютер - ноутбук. И стоят они (sbc) наверное много.

Лапшу-то переделывают потом, чтобы было правильно. А «как надо» пытался делать, например, Танненбаум с Minix или, например, Столлман с HURD. И все равно там нет никакой наукоемкости. Ну ни капельки. Сложные инженерные замуты - да: идея (скажем, микроядро), проектирование, реализация.

Однако, привычный Linux на таких крохах не поднять.

баян :)

А есть ли какое-нибудь простенькое микро- или наноядро (не Minix), реализующее самый минимальный набор функций? Может проще дописывать сервера?

И будет говнописателем коих миллионы.

L4 посмотри или GNU Mach.

А есть ли какое-нибудь простенькое микро- или наноядро (не Minix), реализующее самый минимальный набор функций?

Советую посмотреть на эту

http://prex.sourceforge.net/

Код чист как слеза :) портируемая, компактная и при этом даже POSIX частично реализован. Для изучения ОС - неплохое начало. Процессоры - однозначно ARM.

DCPU-16