бред имхо. ну а вообще такие вещи как mbr гораздо проще кодить на асме (ибо полный контроль над каждым байтом у тебя в руках), а дальше... не знаю, хотите на асме кодьте, хотите на сях, главное подготовить проц к защищенному режиму, перевести его собственно в этот режим и передать управление "адекватному" кодесу. а дальше, каждый др.чет так как хочет, хочешь как Линус Торвальдс, хочешь как Билл Гейтс.... все это мое большое ИМХО.
Простите конечно что влезаю без стука, но вы немного заблужваетесь. От асма нужн не только доступ к управляющем регистрам. Дело в том что все к чему мы так привыкли и так любим в Си (выделение памяти, потоки ввода вывода) это не что иное как системные вызовы реальная работа которых проходит в глубинах ядра и зачастую на асме. К тому же асм это переключение процессов, это менеджмент памяти (сегментация и управление страницами), асм это управление портами ввода\вывода (не забываем что все устройства все таки висят на системных шинах и что за передачу сигналов им отвечают ассемблерные инструкции). Да в ядре все это покрыто очень толстым слоем сишного кода так что до асемблера порой даже добратся сложно, но сделано это не от любви к искусству а от желания сделать код менее архитектурно зависимым. Это я все на примере ядра линукс говорю.
friackazoid все верно, но пока чел сам не попробует все сделать, как он и хочет, на С++ + ком, он не поймет кстати, миллион разрозненных функций - это свойство ядра выни. есть архитектуры ядер куда круче кома. все интерфейсы/протоколы предопределены и общение через них. правда, писаны они не на С++. для ядра он немного слишком высокоуровнев. в ядре очень важны детали, а для интерфейсных языков юзермод придуман
я и не заявляю о том, что всё от и до нужно писать на с++. есть небольшой набор платформенно зависимых функций - пусть даже на асме. переключение адресных пространст, сохранение регистров, обращение к портам ввода-вывода, обработка прерываний - это несколько десятков килобайт ассемблерного кода. использование интерфейсов я предлагаю вместо АПИ, а не как интерфейс для взаимодействия ядра и юзермодных библиотек, что вполне оправдано, т.к. почти весь софт пишется на с++. сейчас получается, что между АПИ и непосредственно самой программой торчит какой-нибудь MFC. qqwe я не знаю что вы понимаете под термином "операционная система" и какие функции вы на неё возлагаете. имхо, главная функция ОС - абстрагирование ПО от конкретного железа. я под этим абстрагированием понимаю единый интерфейс. в выне он реализован в виде набора корявых апишек, перерождающихся в тот-же COM. я предлагаю этот интерфейс представить в виде таблиц виртуальных функций - гораздо лучшая структурированность да и работать будет значительно быстрее, чем заполнение таблиц импорта. я видел оси под арм - там ассемблерного кода - буквально один только стартап в 400 байт. честно говоря, не заметил что обсуждается вопрос написания ОС именно под х86.
И что? Свою реализацию менеджера памяти можно написать на Си без единой строки ассемблера. С потоками ввода/вывода - то же самое. Критической необходимости в ассемблере нет - хотя иногда на нём писать удобней. По поводу оборудования: достаточно на ASM написать функции вида IO_READ_BYTE/WORD/DWORD, IO_WRITE_BYTE/WORD/DWORD. Остальное всё без проблем пишется на Си. Для Memory mapped устройств вообще ничего на ассемблере писать не надо. Если вкрытце - на ассемблере пишется HAL, остальное - на чём хочешь на том пиши.
cppasm ++ qqwe что значит высокоуровнев? чем язык С низкоуровневей, чем С++? я и дровишки спокойно пишу на С++ - ничего такого. писать значительно удобнее. что касается качества кода, то это уже зависит от программиста - понимает ли он к чему приводит та или иная конструкция.
cupuyc ? вы декомпилят обоих лангов видели? высокоуровневость тут будет количество теневых операций, те не заметных с уровня программы. и тут перегрузки/шаблоны/автосоздания-автоудаления и прочая беготря по памяти может вылезти серьезным боком в выни куча юзермод фич зачемто перенесена в кернелмоду. такие дровишки уже некоторые и на # пишут а насчет более удобства писанины дров, тех что к железу, на С++, чем на С (вы еще буст или мфц сюда приклейте), то я бы сильно поспорил в целом и общем, С++ старается скрыть то, к чему приводит та или иная конструкция. более того, это краеугольный камень объектно-ориентированого програмления. и во многих случаях это оправдано. но не в ядре. (хотя планирощик процессов/потоков можно рассмотреть с объектной стороны. но для того, чтоб он работал максимально эффективно - не стоит)
qqwe да я видел дизассемблерные листинги. но вы опять уходите от темы. суть вопроса, поднятая автором: можно ли написать ось на си или возможностей языка категорически не хватает и без асма тут никак. что касается моего вопроса про низкоуровневость - я про качество кода не спрашивал. я спросил именно про низкоуровневость. расшифровываю: можно ли на си сделать то, чего нельзя на си++? что касается оверходов и пр. вопрос спорный и этому нужно посвещать отдельный топик. вообще, это уже миллион раз обсуждалось и у меня нет желания спорить. ответ один - без твоего хотения компилятор код не изпоганит. что пишешь - то и получается и от конкретного языка, будь то си или си++, это мало зависит.
cupuyc ответ давно дан. без асма, а может и хекса не получится. пусть по минимуму (всякие читы типа inb|outb итп не считаются, поскольку это не сам язык, а тот же асм, только писано соседом) учитывая, что С++ - языковая надстройка над С? давайте спросим так, можно ли чего нибудь сделать на С или С++, чего нельзя сделать на асме(-мах)? тут вопрос в соответствии инструмента задаче. набросайте регулярный поиск по маске чуть выше примитивной используя только стандартные средства С++ (буст это не стандартное средство) и только стандартные средства перла. я не говорю, что на С++ это не возможно. просто С++ не всегда идеал. идеала вообще нет. не надо поэтому бутсектора писать на трижды отнаследованных классах и делать рантайм перегрузку машкодов для разных процев/платформ, только чтобы именно С++ с побольше перегрузок/шаблонов. а если еще на одну платформу придется через 5 лет перенести, да еще и не вами? вот у меня вчера сторонняя либа не собиралась (мсвс2008). точнее собиралась без ошибок, но потом творила фиг зна что. теже члены(переменные типа string) разные методы того же класса искали в разных местах памяти, причем либо-демка шла нормально. методом научного тыка удалось все нормализовать методом удаления компилер-ключей "/Og /Os /Ob2 /Gs /GF /Gy", причем, я пока не проверял какой из них дает такой эффект. поведайте, в чем мое хотение чтоб компилятор забыл где он стринг переменные он положил? кроме того, перегруженные операторы и локальные переменные/параметры-классы частенько приводят к теневым работам, иногда сложным и тормозным, например, выделение и освобождение из кучи (переменные-классы) в 3-тьей функции рантайма. (это то, что я вижу в данный момент, но вообще их много. всего не упомнишь) в юзермод-интерфейсных прогах это может и почти всегда прокатывает, но ближе к середке подобная самодеятельность от нежелательной, до недопустимой. ну и еще маленькое "но". С код гораздо проще вылизать и отладить до блеска, чем С++. а это самая важная часть в критических местах. я б даже не советовал пользоваться мсвс компилером, во всяком случае 2008, тк он любит чудить в заголовках. а есть еще моменты, где заголовки тонко задать неплохо бы. причем, автоматом. кстати, комы того же дх ведут к совсем не комовскому int 2e и дале в глубины много-разрозненно-функциевого ядра.
что тут остаётся сказать? тут уже и спорить не о чем. сдаюсь! приду сегодня на работу и скажу начальнику что проект срочно нужно передлывать под vc6, а ещё лучше переписать все несколько сотен мегабайт кода заново - на си. кстати, васмовцы, вы до сих пор что-то пишите на vc2008? срочно его в топку!
cupuyc странная реакция.. попахивает максимализмом.. (кстати, а как вы предлагаете решить на 2008 указанные вопросы?) кстати, другой компилер это не обязательно вообще компилер от мс (вс6 имеет иногдавсплывающие ошибки и свой взгляд на стандарт. 2003 мне нравится больше). есть и другие прекрасные. вы тоже рассчитываете крылья для боинга на кластере суперкомпьютеров по работе?
тролям не дали поесть? каков ввопрос - таков ответ. человек, для которого vs2008 работает неправильно (оказывается даже неправильней чем vs2003) сразу отбивает всё желание к дальнейшей беседе. о чём тут можно говорить? если хотите обсудить тему: какой же гавёный этот язык, С++ - создавайте новую тему. по данной теме вопрос уже дан. p.s. удачи с написанием ос на ямк ))))
cupuyc таки максимализм. либо С++ строго от мс, строго 2008 (чем новее скорей всего) - наше все, либо С++ - говеный язык. любые доводы против подобного разделения - ересь и троллизм, причем, троллем вы меня обзываете вместо ответа на вопрос, а не после его. (я вполне допускаю, что вы ответа не знаете. но зачем так болезненно реагировать?) вот вам еще вопрос - в вашей проге зачемто надо (зачем - одному начальнику/заказчику ведомо) реализовать легкие нити. реализовать так - в начале каждой функции идет обращение к менеджеру нитей и тот либо возвращает управление обратно, либо переключвает контекст на другую нить. иногда это очень удобно и полезно. вопрос, как вы сделаете этот момент (обращение к менеджеру в начале каждой функции. сам менеджер, нити итд - не надо) на мсвс? что такое "ямк"? язык микроконтроллеров? ну так есть же оси написанные полностью на асме х85, асме авр, асме арм. а чем вас этот момент так веселит?
qqwe язык машинных комманд. в ответ на ваше очень хочу посмотреть что за ось вы напишите в своём хексе. это я вообще не понял к чему. при чём здесь конкретно наш проект? и ваш вопрос про нити?
cupuyc ну так хекс весьма активно используется и не на ядерном уровне. как по вашему компилеры (включая жит, те виртуалки) машкод вылепляют? или вы думаете, что их не люди пишут, а ловят в местах природного обитания? а релоки? (про морферы/протекторы/крипторы/самомоды и прочую защиту обязательную, например, для коммерческого софта я умалчиваю. чтобы вам поменьше материться.) чувствуется, что времена радио - синклера вы пропустили. а хотите увидеть - пишите требования, объявляйте стартовый бюджет, сроки, обсудим. както вас носит, не замечаете? Вопрос топика был о необходимости асма, вами/не вами? ник не похож. вы взяли трибуну о написании ядра с 0 на чистом С++ и боже упаси С стиль, а все остальное - отстой и вам не надо. потом сказали, что С++ это строго мсвс2008. потом обвинили меня в троллизме за вопрос по мсвс2008С++, причем, нисколько не выдуманный и потребовали от меня написания оси в машкодах (бесплатно, видимо. и без уточнения своего понимания слова "ось". юмор). и не смогли ответить на задачку о вызове функции без параметров (история про нити это объяснение. чтоб небыло вопросов - а зачем это и как это к теме топика. нити часто используются в местах где нужно быстрая многопоточность, но не обязательна параллельность) в начале каждой функции (включая сторонние либы представленные в сорцах) под мсвс(!важный момент), приплетя в этой связи зачемто свой проект (который на сотни мегабайт С++ кода). а причем тут ваш проект то? как он к теме топика или ко мне? у вас проблемы какието? нервничанием вы их врядли решите. ну а впоследствии и сами поймете, что на мсвс С++ и даже на просто С++ свет клином не сошелся. и те же скрипты применяются куда как ширше.
кстати говоря, чтобы писать ось, надо иметь более веские основания (пакет идей, требования к назначению, архитектуре), чем идея написать "ось" на чистом С++ или чистом хексе. как вы вообще понимаете слово "ось"? мс(рс)-дос всех номеров и сп/м тоже оси в противном случае лучше выбрать или даже модифицировать существующую (они есть очень разные. включая переплевывающие иные футуристические медиа-прожекты). вы упомянули свой проект, вы ось пишете?
нужно читать посты до конца. я никак не могу понять при чём здесь мои проекты? что касается ОС - я на данный момент (не на работе) пишу как-раз таки что-то вроде hal. ассемблера там - только стартап (байт, наверное, в 300). всё остальное, от и до начистом Си ++.
вобщем чтобы всё это не тянулось бесконечно, я задаю конкретный вопрос и жду конкретного ответа. безо всяких эмоций и ухода от темы. какие элементы ОС невозможно написать на С++? перечислите по пунктам. морферы и пакеры к понятию ОС не имеют никакого отношения.