OSDev

Говорю же

Кстати, исправил баг один. Можете проверить.

Сегодня попытался в Си с помощью классов реализовать симулятор (там же легко перехватывать смену уровня clock оператором = имитации тактирования. Так что-то не получается пока разобраться с локальными переменными.

P.S.: В своё время скачал Visual Studio 6 мини-сборку - 90Мб установщика. И очень доволен!
Вообще, есть ли компактные пакеты VHDL/Verilog разработки?
Могу обойтись и без опций проверки на железе, а лишь в программной симуляции. Спрашиваю на форумах - молчат.
Нужен пакет умеренного размера - 50-120Мб.

> Си
> классов
you're doing it wrong. В общем, прошу не смешивать в кучу C и плюсы.

> Нужен пакет умеренного размера - 50-120Мб.
gtkwave + verilator или gdhl даже на порядок меньше занимают, насколько понимаю.

_________________
Found a CPU. LAPIC ID: 00

Спасибо. Разобрался.
Правда, на дворе - XXI! И "я крут, т.к. сижу в консоли" уже не актуально.
Лично у меня уже сложился устойчивый стереотип: Если скачанная программа - консольная, значит разработчики - серъёзные люди. НО!
Повторяю, на дворе - XXI! Графическое разрешение дисплея и камеры у сотовых телефонов скоро на порядок превзойдут рядовой ПК (у одной сотки камера - 40Мп! а у меня и 640x480 с тормозами захватывается). А в сети всё ещё актуальны темы "подключить к LPT дисплей 128x64 - офигительная круть!".
Достало спартанство!

Короче, есть ли пакеты со свистелками-перделками? Т.е. полноценный редактор и отладчик в рамках Windows интерфейса. Чтобы вообще забыть про консоль...
Имею ввиду симуляции работы ПЛИС до уровня внедрения в аппаратную часть моего ПК. Т.е. после запуска симуляции становится доступен виртуальный порт (LPT или COM), а также область в памяти и т.п.
Короче, если я написал простенький видео девайс, то из любой программы на Си можно было бы запросить доступ к его видео памяти.
Т.е. полная симуляция на общем уровне.
Помнится лет 13 тому назад была актуальна тема софт-модема.

P.S.: Чтобы облегчить себе задачу, все листинги пишу как bat-файлы с шапкойи запускаю через F9 не выходя из редактора BrEd.

В общем, сел снова изучать сорсы KlbrInWin и совсем запутался. Нашёл процедуру обеспечения доступа к видео памяти десктопа (gs:[pixel]). Однако не выделю никак предпосылки на этот механизм.
Где там настраивается среда Винды, чтобы обращение через gs передавало управление в нужную точку...
В сорсах слишком мало комментов.

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

И у меня концепция немного созрела. API стал более чётким и в принципе можно было бы KolibriInWindows переделать, получив работающую реализацию. Но никак не докопаюсь до нужных механизмов.

Я вроде писал что нужных механизмов нету.
Есть только несколько:
1) Прерывание вызванное при обращением к несуществующей странице, неправильной и тп. Оно вам по определению не подходит так как не даёт увеличения объема.
2) прерывание вызванное при обращение к несуществующему сегменту, неправельный дескриптор и тп.. Вот тут можно играться. Но насколько помню это вас не устраивает из-за того что вам 24 ГБайта мало.
3) Эмуляция каждой команды.

Что касается эмулятора колибри, то исходника нет под рукой. Но скорее всего 99,99% gs:[pixel] - работает так. Есть единое линейное пространство. В котором для видео буфера отведён диапазон адресов к примеру 80000000h-80100000h один мегабайт. А в эмуляторе стоит таймер который периодически останавливает процесса эмулируемой среды читает из него через ReadProcessMemory и делает blitbit для вывода картинке. Запускает эмуляцию дальше.

Хм. Какие 24Гб?

Кстати, за это время концепция немного созрела:

Поясню. Создаём процесс и выделяем ему минимум:
Шаг №1:

• На код - страницу "//usr/code" 4кб;
• На стек - страницу "//usr/dump" 4кб;
• На данные - страницу "//usr/data" 4кб;
• На остальное - страницу "//usr/dumb" 4кб.

"//..." - условная ссылка на локальное пространство текущего процесса
Далее, так как в LDT допускается до 8192 сегментов, назначаем их все.
Все 8189 сегментов, исключая #6655, #6143 и # 7176 направляем на "//usr/dumb". Оставшиеся 3 распределяем следующим образом:

• CS:0xCFFF="//usr/code";
• SS:0xBFFF="//usr/dump";
• DS:0xDFFF="//usr/data";
• ES:0xDFFF="//usr/data";
• FS:0xFFFF="//usr/dumb";
• GS:0xEFFF="//usr/dumb".

Тут программа имеет в своём распоряжении все 8192 сегмента, но они предоставляют всего 16кб виртуальной памяти в нижних адресах [0x00000000..0x00000FFF] по любому сегменту.

Шаг №2:
Теперь делаем так, чтобы обращение по адресам за пределом 4кб ( > 0x00000FFF) на убивало программу. Так как страниц может быть 1048576, а по нижним 4кб лежит страница #0, все страницы [1..1048575] зеркалим на #0. Т.е. программа, обращаясь по остальным адреса (0x00001000..0xFFFFFFFF) будет иметь дело с отражением основной (на 0x00000000..0x00000FFF). Тем самым, имея 8192 сегмента по 4Гб каждый, программа получит все 32Тб пространства (но не памяти). И всего 16кб реальной виртуальной памяти.
Тем самым, программа сможет работать в этом "лабиринте зеркал" и никогда не получит ошибки обращения к несуществующей странице памяти.

Шаг №3:
Тут наступает самое интересное.
Нужно всем этим 8192 сегментам памяти создать другие формальные 8192 сегмента контекста.
Т.е. получается так:

• 0xCFFF - сегмент ресурса "//usr/code", 0xCFF8 - сегмент контекста "//usr/code".
• 0xDFFF - сегмент данных "//usr/data", 0xDFF8 - сегмент контекста "//usr/data".
• 0xBFFF - сегмент стека "//usr/dump", 0xBFF8 - сегмент контекста "//usr/dump".

Иначе говоря, если программа хочет узнать имя контекста сегмента 0xCFFF, ей нужно попытаться считать данные из глобального сегмента 0xCFF8, где и будет лежать сама строка "//usr/code". Т.е. при попытке загрузить в регистр сегмента (FS/GS) значение 0xCFF8 сгенерируется исключение. Процесс застынет, мой "демон" получит управление для отладки ситуации. Он "поймёт", что раз нижние три бита обнулены в 0xCFF8, значит программа "стучится" в нижний уровень (демона) с вопросом "дай имя контекста"...
Получается некий API-вызов, но без традиционных call/int. А через "диалог" с памятью.

Например.
Мы хотим, чтобы программа открыла файл по сегменту 0x1237. И мы теперь знаем, что доступ к контексту сегмента будет в 0x1230. Нам нужно прямо в контекст сегмента вписать имя файла, чтобы оторвать все 1048576 зеркал сегмента 0x1237 от 4кб страницы "//usr/dumb" и переключить их на проекцию всего файла.
Делаем это так:
Как видно, операции fopen..fclose вызываются не напрямую, а диалогом с памятью.
Замечу, что при открытии файла тут генерируется два исключения. Первое - при записи в fs значения 0x1230. Где файл не открывается, а лишь проверяется его наличие и он ставится на очередь. Второе - при чтении (записи, обмена, вызова и т.д.) из сегмента. Где уже становится ясно, для чего сегмент нужен.
Хорошо.
Скажете в очередной раз.
Более-менее, но понятно.
Но зачем организовывать такой чудовищный API!?
Отвечу так:

1. API-интерфейс становится абстрактным, эфемерным. Сама OS уходит на более далёкий план;
2. API-интерфейс такого вида легко переключить на аппаратный уровень, где сам чипсет сможет играть роль "демона";
3. API-интерфейс с псевдо-аппаратным демоном по-сути уже кроссплатформенен.

На счёт пункта №3 Вы начнёте жёстко возражать. Поясню...
Все процессоры имеют операции чтения-записи - кроссплатформенность.
Если реализовать мою задумку, можно подобным кодом написать десятки нормальных программ.
Т.е. изначально все прикладные программы жёстко привязаны к своей операционной системе набором библиотек, функций и их особенностью (скажем, нужен cygwin для запуска *nix-приложений под Windows с адаптацией).
А если все операции будут производиться только с памятью, оболочку для таких приложений можно перенести на плечи виртуальной машины и вообще легче воспроизвести аппаратно (чтобы понять этот момент, нужно забыть весь свой опыт работы со всеми операционными системами и компьютерами).

Космическая Одиссея 2001 - позиция 111 минут 55 секунд.
Оператор ЭВМ отключает модули физическим извлечением и отключением.
Так как фильм я видел ещё в детстве, то идея идеальной операционки стала базироваться на желании, чтобы дома на столе создавалось нечто большое и похожее на ту супер-ЭВМ. Так, ради забавы и даже в ущерб производительности.

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

• Адресное пространство: 8192 сегмента по 4Гб каждый, свёрнутые в единый дамп 4Кб;
• Программа не имеет никакого доступа к файлам, т.к. файловая система для приложения отсутствует;
• Все ресурсы (от bmp до mp3 и avi) подобны картриджам (NES/Sega) и появляются в памяти приложения как новые сегменты;
• Все библиотеки с API - также подключаются физически (виртуально) как картриджи как новые сегменты (горячий Plug'n'Play);
• ...

Иными словами, нет никакой многозадачности (формально). Приложение запускается в полном вакууме.
Имеется формальная таблица и 256 векторов прерываний. Когда пользователь тащет свой mp3-файл на проигрыватель, OS иницирует свободный сегмент под зеркало на этот mp3-файл, а затем генерирует прерыванию по нужному вектору (типо, авария: внедрение в память). Приложение должно само просканировать все 8192 сегмента и обнаружить изменения (вторжение инородного устройства в шину дешифратора адреса).
Т.е. никаких путей к файлу, а также его имя, расширение и атрибуты, приложение не видит. Тупо, эдакий сегмент памяти занялся под эдакий бинарный ресурс. Этот ресурс нужно проанализировать, распознать и отработать...

P.S.: Один мой знакомый из сферы IT, выслушав мою идею операционки, задумался и сказал, что очень напоминает зачаточное состояник ИИ. Где система - не просто набор нужных папок и файлов. А неизвестно что неизвестно где. С одной стороны, шаг назад, к хаосу. Но, если задуматься и копнуть глубже, напоминает нейронную сеть. Где клетки соединяются друг с другом вслепую, хаотически и без всяких формальностей. Что моя операционка напоминает некий организм. Вот только найти надо единомышленников...
Да, легко сказать. Найти, в обществе, где подавляющее большинство - думают по-шаблону, работают с шаблонами и шаблонят везде, где можно...

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

Хочу подкинуть вам идею. Тут была передача научно познавательная про ВИЧ. У человека существуют беки которые атакуют всё неизвестное. Атаковать начинают по команде, для просто ты пусть некоторое прерывание. А есть другие белки которые по этой команде начинают анализировать это неизвестное и выробатывают стратегию тактику для борьбы с этим неизвестным.

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

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

Полимерная память
У меня это не физический термин, а сугубо виртуальный.
Суть моей полимерной памяти заключается в том, что она просто имеет дополнительное измерение.
Когда приложением запрашивается у ОС объявить некоторый регион памяти полимерным, этот регион, всего навсего, резервируется. Любое обращение к нему провоцирует исключение.
Однако, позвольте! Я не такой дурак, чтобы тупо объявить в своей идее ОС полимерностью флажок MEM_RESERVE функции VirtualAlloc Win-API, так как суть несколько в ином.

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

Каждая ячейка региона полимерной памяти имеет совершенно независимое собственное измерение.
Т.е. когда мы запрашиваем у ОС минимальный полимерный регион размером в 4Кб, это вовсе не значит, что его размер - 4Кб...
Да, в памяти приложения он займёт ровно 4096 ячеек от 4Гб. Но это не 4096 байта.
Каждая из 4096 ячеек является неким хэндлом в "иное измерение".

Как видно, организуется некий API взаимодействия с ОС. Таким образом, в одну полимерную ячейку можно отправить:

• До 4 гигов байт;
• До 4 гигов слов;
• До 4 гигов двойных слов.

Полимерные ячейки напоминают "чёрные дыры", "проколы" в пространстве памяти приложения, некие сетевые "порталы", потоковые каналы и т.д.

Как я уже сказал, если Windows выделяет одному приложению до 2Гб памяти (или до 3Гб, не важно), а верхние 2Гб занимает сама. То в идеологии концепции моей ОС лежит принцип полностью скрытого API.

Допустим, приложению нужен "картридж" с mp3-файлом. Говоря "русским" языком, нужно открыть файл с музыкой через диалог с пользователем.

Тем самым, если изначально полимерная ячейка №77 была пуста, то после приклепления её к "/dev/media/*.mp3" любой доступ к ячейке будет контролироваться mp3-библиотекой.
А установка режима ячейки "mode:MP3_OPEN | MP3_STOP" (подобно специфической командной строке) пошлёт библиотеке команду на вызов диалога с выбором файла и подготовку потока к воспроизведению.
Тем самым, как видим, никаких явных инкладов, никаких call и ничего привычного.
Просто, постоянно генерируем исключения, а ОС сама "угадывает", что мы хотим от неё...

Если мы полимерную ячейку объявим OpenGL-средой, то туда загрузится соответствующая библиотека. Причём, в памяти приложения библиотека уместится ровно в 1 ячейку, отнимет 1 байт пространства (можно запросить миллиард хэндлов на различные нужды. это займёт всего миллиард байт). И работать с этой библиотекой нельзя через обычные call...
(Хотя, если очень "приспичит", можно в описатель режима ячейки добавить указатель на проекцию в память, где библиотека будет доступна как в "традиционных операционках". Но тогда 4Гб общей памяти может приложению не хватить, если оно будет запрашивать проекции на тысячи библиотек. Но, это отдельная тема.)

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

Эту мысль всюду критиковали за то, что такие ячейки, генерирующие исключения при каждом доступе, предстанут самым медленным API в мире!
Потому, хочу снова повторить: Эта операцинная система придумывалась концептуально не как очередная операционка, и не как эмулятор некоей ЭВМ.
Операционная система с самого начала задумывалась как эмулятор супер-ЭВМ. (почему "супер"? с самого начала концепция ОС предполагала, что клавиатура может быть в Канаде, мышь - в Австралии, а принтер - на Луне. т.е. любая программа в данной ОС может даже изначально не подозревать, где находятся её оборудование. тупо "втыкаем" в программу "шнур" клавиатуры с любой точки планеты и всё. включая и зеркала проекции файла для одновременного доступа. сама ОС напоминает "облако")
Т.е. если в Windows в кольце 3 инструкции CLI/STI/IN/OUT/INS/OUTS запрещены и вызывают крах приложения, то в задуманной ОС они доступны для обращения к устройствам этой виртуальной ЭВМ. Причём, in/out команды никак не дадут доступа к реальным портам IBM-PC или к симуляции портов IBM-PC (DMA, SoundBlaster, Keyboard etc.). Здесь in/out будут работать как ещё один уровень взаимодействия с аппаратурой (наряду с полимерными ячейками). Т.е. можно объявить порт №54 (EDX=54) IRC-протоколом и отправлять туда сообщения или команды (REP OUTSD).
Можно построить совершенно любую ЭВМ со своими портами и своими девайсами.

А главное: Не смотря на то, что полимерные ячейки и порты в таком случае - крайне медленный API, концепция ОС базируется на том, что (идеализируя) можно пойти к "Китайцу" и заказать материнскую плату на базе x86, но с чипсетом "моей разработки". Т.е. сам чипсет будет контролировать аппаратно ширину слова при доступе к памяти (B, W или D) и "полимерно" воспринимать доступ к ней.
И если программно ОС будет жутко тормозить с моей "полимерностью". То, имея такой "чудо-чипсет", машина будет просто летать (конечно, распаковка mp3-файла - аппаратная, OpenGL - аппаратный)!

Вы скажете, я отстал от жизни, так как OpenGL и DirectX - давно аппаратные.
Но, доступны же из приложения не напрямую, а сквозь уйму программных "костылей": Библиотеки - HEL - HAL...
Как ни крути, без API никак не обойтись.

А в моей концепции ОС имеется ввиду, что любое аппаратное устройство - картридж. И как в DOS - программа может его напрямую программировать через порты и память, будто система - однозадачная.

(раньше в Windows'XP если в программе открыт захват с карты аналогового ТВ-тюнера, в других приложениях доступа к нему уже не было. а вот в Vista и в последующих - можно открыть кучу сеансов работы с тюнером. если где-то переключить канал, во всех программах канал тоже переключится: нет конфликта единоличного управления тюнером. т.е. частично реализована концепция моей ОС. напоминаю, я её задумал в 1996-1998, ещё до знакомства с DOS 3.11, сидя за РАДИО-86РК)..
[code]
mov edi,PolyDump ; Указатель на