OSDev

Делайте. Вас никто не отговаривает напротив.
Я и не говорил использовать. Я сказал сделать по образу и подобию.

простите, но вы сами написали

Можете посмотреть как устроен эмулятор программ для КолибриОС. Этот эмулятор позволяет запускать приложения для КолибриОС в ОС WinXP. Это ближе всего к тому что вы пытаетесь сделать.

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


Ну это конечно ваш выбор. Можно из упрямства, например, ходить на руках. Неудобно, но я так хочу


Это вполне возможно. Однако, есть несколько рекомендаций:
1. Не стоит проектировать x86-подобную архитектуру. При общей её слабости она очень сложна для интерпретации и изобилует кучей подводных камней. VHDL-описание легко может не поместиться в ваш FPGA, либо потребуется баснословно дорогой FPGA и сложная в разработке плата для его монтажа. Повторю: x86 - ОЧЕНЬ плохой выбор. Здесь или нужна полная совместимость (тогда вопрос: зачем копировать то, что уже есть), либо полный и бесповоротный отказ от кривой архитектуры.
2. Прежде, чем моделировать проц в железе лучше смоделировать его программно, в виде интерпретатора виртуальной машины, поработать с ней, написать для неё приличное количество софта, чтобы выявить недостатки/преимущества. В принципе, вполне можно ограничиться и ВМ без аппаратной реализации. Но ВМ в любом случае чрезвычайно важна для отладки VHDL-описания аппаратной модели. Если что-то не работает в железке, это всегда можно сравнить с ВМ.
3. Помните, что железо без программной поддержки - ноль. Как минимум нужен ассемблер, кросс-компилятор, набор стандартных библиотек. Это всё нужно писать и портировать. Работа не из простых даже при портировании на новую ОС с той же архитектурой.
4. Работа с железом затратна и трудоёмка. 10 раз подумайте, есть ли у вас достаточно мотивации для такого шага?


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


Если все говорят одно и то же, может, есть в этом правда и стоит, наконец, прислушаться?


Не, не так. Java Byte Code - вполне себе аппаратная архитектура (т.е. "свой процессор"), однако ставится и демонстрируется двумя кликами без всяких FPGA.


Я бы не стал называть его венцом. С моей, сугубо личной, точки зрения, Linux - кошмарный сон цивилизации, который порождает чудовищ. Поэтому смысл есть.

А вообще у меня такое впечатление, что здесь очень много слов. Я одного никак не могу понять: чего вы от нас-то хотите?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Архитектуру процессора кстати было бы не плохо создать для готовой полноценной, оптимизированной ОС. Т.е. посмотреть какие команды востребованны, а какие нет, хотя с другой стороны эти команды могут пригодиться в будующем. Чтобы создавать новый процессор нужно иметь конкретные претензии к имеющимся. Я не имею, а вот к ОС существующим имею конкретные притензии. И писать нужно с нуля а не колечить существующие. У меня были похожие мысли по создании Процессора в детстве, когда я не знал ни чего.

В итоге все оказались заложниками старой архитектуры x86. Логичнее создать с нуля новый процессор - а для совместимости программный эмулятор x86 . Именно такой вывод напрашивается. Я думаю архитектуры будут сменять друг дуга не раз. Может тогда и новую ОС разрабатывать с учётом этой возможной и непредсказуемой истории. Примерно так я обьясняю зачем нужна виртуальная машина для моей H2O. Что-то типа пока я сделаю свою ось - она не сможет работать просто потому что не на чем будет её запускать - а так может напишу для неё эмулятор для какого-нибудь устройства - вот и перспектива. Потому и стараюсь ВМ делать попроще - мне же потом и разбираться. Но в общем есть сомнения. Мы ремесленники. Будущее изменит весь инструментарий разработчика и т.д.. Здесь в том и проблема что время на разработку ОС требуется очень много. А меняется всё быстро.

Ну это получается двойная работа, сначало для своей архитектуры, потом для других. Я если свою систему буду переносить на другую архитектуру, то буду переписывать её оставляя все алгоритмы и меняя драйверы. Во первых при переписывании могут быть дороботки, во вторых размер и скорость работы больше.
Я за постоянное переписывание алгоритмов на системы. Если бы интел не обеспечивала поддержку старых технологий а предлагала бы переписывать всё с выходом новых процессоров, то возможно они былибы более развиты. Тем более говорить, что много архитектур и они постоянно меняются не приходиться.
Сейчас интел запускает в производство всё на той же архитектуре и с тем же багажом поддержки Ivy Bridge четырехъядерных семейств Core i5 и Core i7для ноутбука, так что нужна поддержка многоядерности. Переход от 32- на 22-нанометровую технологию с уменьшением размеров чипов, улучшением их производительности и снижением энергопотребления.

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

Впрочем, интел захватил и нишу тех кому неймётся переписывать: для этого есть всякие армовые XScale.

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

Хм
15 лет назад за компьютером однажды просидел не вставая все 15 часов в среде TurboPascal 5.
А пока писал пробный код с загрузкой дампов памяти и дескрипторов - поднялось давление! И это за пару часов
Неужели возраст своё берёт? Или просто отвык кодить...

P.S.: Скачал сорс KolibriInWindows... Интересный код. Эмулить всю операционку механизмами Windows. Правда многие куски ставят меня в тупик. Надо бы перевести всё ви Си-- синтаксис.
Вот что сильно не нравится в ассемблере - одна инструкция на строку. Дофига скроллить приходится и стыковать куски в мозгах... Пф-ффф...

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

В принципе, я уже говорил, от идеи не откажусь. Впрочим, если появятся доказательства, что в среде Windows, а также и со своим ядром, такая концепция не реализуема. Придётся либо концепцию подправить, которая ещё, благо, не сформирована и на 99% туманна. Либо отказаться от неё под IA-32 вообще!

Вы говорите, заняться разработкой собственного CPU заточенного под plutOS. Но зачем мне тогда вообще plutOS, если сам процессор аппаратно будет поддерживать концепцию? Тогда plutOS замениться обычным BIOS с поддержкой особенностей процессора.
К тому же возраст своё берёт и спустя 17 лет я не знаю, хватит ли сил и терпения браться за сам процессор.
Кратко опишу его архитектуру:
1. Шина адреса 64-разрядная;
2. Каждая задача работает в нулевом пространстве:
2.1. Нету рабочих ячеек OS, тем самым, нечего и защищать;
2.2. Большинство инструкций высокоуровневые. Т.е. выполняются через OS:
2.2.1. Создание локального файла (VirtualAlloc);
2.2.2. Создание глобального файла (CreateFileMapping).
2.3. Нижние 4Гб памяти полностью в распоряжении задачи;
2.4. Остальные - доступ к файловой системе, сетевым ресурсам, графике и т.д.;

В общем, как уже понятно, полное отражение концепции plutOS: Никаких API с тысячями функций. Только окна памяти на такой-то ресурс.

P.P.S.: Идея родилась под впечатлением от последней сцены фильма "Газонокосильщик", где он пытается найти открытый порт и выбраться в глобал.
Тогда я подумал, нафиг все эти хэндлы на файлы и прочие ресурсы?
Традиционные системы словно пришёл в архив, сделал запрос и тебя послали в такой-то корпус к материалам с таким-то индексом. И начал бегать по коридорам, кабинетам.
Нет уж вам! Это я сам с потолка возьму индекс (номер телефона девушки) и назначу ему такой-то ресурс.
Т.е. наоборот всё. Имею хэндлы, какие мне легко запомнить, а не те, которые выдаёт бюрократическая номенклатурная система!
И никакой моей суеты! Не я бегаю по функциям с хэндлами (по инстанциям с кучей документов), а система.
Типо Взял чистый лист и ручку, тысяча чиновников сами ко мне подошли. Стал писать шапку, отсеялись чиновники до сотен. Стал писать вступление, отсеялись до десятков! Я на них не смотрю, а они за мной следят. Как только ставлю подпись в конце, нужный оставшийся чиновник уже сразу либо ставит печать, либо просит сделать поправку. Поняли?
Я (приложение) сижу на месте (eip/esp в ожидании) пока чиновники (драйверы) суетятся (интерпретируют исключения доступа к чистому листу).
На листе написал "обои красные" и комната перекрасилась. Добавил "в синий горошек" и рабочие перекрасили. Не надо кричать "Repaint/Redraw"! Они сами затаив дыхание следят за тем, что я пишу. И сразу делают ещё до того, как ставлю точку.
А пока я жду результат (обрабатывается исключение) - пью чай. А не как, скажем, в Windows: Сделал ошибку и тебя прихлопнуло!!!
Пусть из-за моей ошибки прихлопнет какого-то чиновника. Всё равно система тут же его восстановит, пока я жду результата за чашечкой чая.

Понимаете?

P.P.P.S.Если Вы примерно понимаете, могли бы помочь в одном пустяке?
Например, описать (во вступлении) концепцию одной строкой (фразой). Типо, операционка имеет исключительный (на базе механизмов исключений) API с доступом к ресурсам через сегментные регистры (хэндлы).
Ну, короче Вы поняли. Как максимально кратко и исчерпывающе описать интерфейс, низкоуровневое переназначения смысла lock/int/cli/sti и т.д?

Внимательно прочитал всю ветку.

Идея, положенная в основу PlutOS, благородна, но негодна. Если по-простому, то это попытка решить системными средствами задачу, лежащую за пределами системы.

Главное, что мне удалось понять за время анализа разных ОС, -- бо́льшая часть проблем проистекает от непродуманности и неорганизованности, а потом уже идёт всё остальное. В экономике есть термин -- недофинансирование. В разработке ОС и программировании наблюдается нечто похожее, но общепринятого обозначения не имеет. Как правильно назвать недостаточное покрытие задач абстракциями? Недоабстрагированность?

Полностью согласен с последним комментарием об одном предложении. В проектировании ОС, как и в физике, главная задача -- теория всего. "Всё есть файл", -- и будет UNIX. Считается, что следующей концепцией должно стать: "Всё есть объект". Но мало кто отдает себе отчет о последствиях, и концепция превращается в химеру.

Какова "теория всего" PlutOS? Всё есть сегмент?

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

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

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

Кстати, замечу, что сейчас пытаюсь продвигать одну из сотен других своих идей.
На дворе - вторая декада XXI века! Объёмы памятоперативной и жёсткой памяти, а также траффик сети - не жалеют!
Я подумал, а почему в недрах HiTec ничего не меняется радикально? Гуглил - не нашёл ничего по теме.
А именно. Года с четыре назад я пытался разработать наброски процессора без абстрактной системы команд. Т.е. вместо условно байт-кода и его мнемонического представления используется прямая синтаксическая запись ASCII-символами на уровне синтаксиса языка Си формальных выражений.
Иными словами, процессор сам является парсером текстового листинга. Причём даже без польской записи языка Форт. Экспериментально написал JavaScript так, будто это - заготовка vhdl. Т.е. каждый вызов функции является одиночным фронтом тактового генератора. Имеются переменные, симулирующие шины адреса и данных, а также управления. На чтение одного байта уходит три такта (вызова функции).
При этом, симулятор написан предельно просто и без лишних ухищрений, чтобы с лёгкостью мог быть портирован в аппаратуру.
Четыре года назад я хватался за идею и переусердствовал, так-как сразу пытался считывать имена переменных за такт, путём включения десятков ПЗУ цепочкой. Но, недавно попал на один сайт и заинтересовался. Если встроенный Бейсик позволяет легко программировать порты, при этом ставка на супер скорость не ставится из-за интерпретации. То почему бы не перевести высокий уровень на аппаратный?
Иными словами, пусть у задуманного мною процессора на одну инструкцию уходят десятки тактов! Ведь Бейсик-программа жрёт на порядки больше! Так зачем я буду гнаться за гиперскоростью?

Итак, первый шаг я сделал - устранил фобию перед пожиранием тактов.
Потом я сформировал основные принципы, то есть обрисовал жёсткие ограничительные рамки. Например, имена переменных являются кодированным адресом. Т.е. переменная "A" уже имеет фиксированный адрес в памяти. Т.е. ячейку 028h (0Ah << 2). Все имена кодируются шестью битами на символ (26x2=52 буквы лат.алфавита + 10 цифр и подчёркивание "_"). Тем самым, обращение к любому порту происходит через указание переменной, где её имя - шифрованный адрес. Тем самым, 4Гб пространства - 32 бита минус (помните 0Ah << 2?) 2 = 30 разрядов делим на 6 бит под каждую букву = 5 букв.
Если мы таким процессором хотим состряпать домашний кодовый замок, подобная расстановка принципов вполне приемлема.

Синтаксис, однако, отличен от Си и имеет особенности. Так, вместо *(long*)(0x0D << 2) = (long)(*(char*)(0x0A << 2)) + 1 записываем 040D = 010A + 1. Где 040 и 010 - соответственно 32 бита и 8 бит в восьмиричном представлении.

Правда, убегая от байт-кода в процессе разработки симулятора я всё равно пришёл к своеобразному байт-коду. Вот сырое введение.