Разработка новой операционной системы. WinOS.

[RccHD 136]

Чтобы бы там не говорил Fingercomp по поводу написания своих ОС, я таки пишу свою ОС

Планы такие:
1) разработать операционку с многозадачностью на основе OpenOS с полной совместимостью
2) запуск нескольких программ одновременно(в том числе графических)
3) возможность разбивки экрана на прямоугольные зоны для предоставления программам доступа к этим зонам(программы не будут рисовать графику вне предоставленной зоны)
4) буферизация графики с ускорением отрисовки (как у ECS). Я не стал брать либу от ECS потому что она использует другие либы того же автора и потому что реализована эта библиотека довольно коряво в плане стиля написания кода(мое личное мнение). В общем, я переписал либу ECS с нуля под нужды операционки, кол-во кода сократилось в 5 раз. Все программы написанные на моей OC будут иметь "графическое ускорение" по умолчанию.

Пункты 2 и 3 фактически уже закончены(по-крайней мере мне так кажется)
Буферизация(пункт 4) работает прекрасно, отрисовка графики в некоторых случаях может быть в 3-15 раз быстрее(относительно gpu api)

Также планируется написать несколько очень простых программ для демонстрации возможностей ОС
В частности, хочу реализовать ОЧЕНЬ сильно урезанную реализацию моего любимого оконного менеджера xmonad


Важно: все OpenOS-программы можно будет запустить на моей OC

Изменено 16 апреля, 2018 пользователем Alex

[RccHD Автор темы 136]

Надеюсь, что мне не надоест разрабатывать эту OC, иначе будет еще одна R.I.P операционка

Планирую закончить разработку максимум через месяц. По истечении этого времени, я либо выложу готовый результат/альфа-версию, либо забью на разработку

 
P.S. я школьнег и мне кроме написания OC еще учиться надо

Изменено 1 сентября, 2017 пользователем RccHD

[eu_tomat 2 154]

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

Важно: все OpenOS-программы можно будет запустить на моей OC

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

 

Основные проблемы:

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

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

[Zer0Galaxy 2 187]

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

Программы, запускаемые многозадачно, вовсе не обязаны быть ориентированными на многозадачность. Здесь я показывал вариант как можно реализовать такую многозадачность. Вот с подвисанием согласен.

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

Оборудование доступно программам через объект component. Если система подменит этот объект своим, то она сможет разруливать аппаратные коллизии. Например, если одна программа использует редстоун-карту, то другой программе можно не давать к ней доступ.

[Totoro 3 563]

Ну, если пост Фингера прочитан, все риски взвешены, план битвы составлен и мосты сожжены - желаю удачи =)

Посмотрим, что получится.

[ECS 1 903]

блиотека довольно коряво в плане стиля написания кода(мое личное мнение)

 

Ну блин, стараешься тут, стараешься, разбивая код на суб-сегменты по классическим идиомам проектирования, минимизируя нагрузку на оперативку и ЦПУ, а потом его "корявым" называют. Обидно 

 

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

Изменено 1 сентября, 2017 пользователем ECS

[eu_tomat 2 154]

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

Без доработки приложений этот пример последовательно выполнит сначала одно, затем другое приложение. Вряд ли @RccHD стремится к такому результату.

Оборудование доступно программам через объект component. Если система подменит этот объект своим, то она сможет разруливать аппаратные коллизии. Например, если одна программа использует редстоун-карту, то другой программе можно не давать к ней доступ.

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

 

Поэтому данное утверждение не соответствует действительности:

Важно: все OpenOS-программы можно будет запустить на моей OC

«Все» программы придется сначала адаптировать к новой OS, а это уже заметный недостаток.

[RccHD Автор темы 136]

«Все» программы придется сначала адаптировать к новой OS, а это уже заметный недостаток.

Во, первых это ты сам решил что "все программы придется адаптировать", я такого не писал

Я постараюсь написать такую ОС, на которой можно будет запустить большинство программ без доработки

[RccHD Автор темы 136]

Ну блин, стараешься тут, стараешься, разбивая код на суб-сегменты по классическим идиомам проектирования, минимизируя нагрузку на оперативку и ЦПУ, а потом его "корявым" называют. Обидно 

 

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

По поводу моей субъективной оценки твоего кода:

 

Я вот такие вещи вообще видеть не могу, это вообще не по-человечески так писать:

changes[buffer.currentFrame[index]] = changes[buffer.currentFrame[index]] or {}
changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] = changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] or {}
				
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], x)
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], y)
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], table.concat(sameCharArray))
				

 

Когда я вижу подобный код, я начинаю думать:

1) У автора этого кода паническая боязнь переменных(или он проспорил кому-то)

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

3) У автора Крутой Продвинутый Текстовый Редактор ™, который позволяет написать "buffer.currentFrame[index]" сразу в трех местах

 

 

Так как я не фанат различных навороченных редакторов текстовых редакторов и не боюсь переменных и знака "=", я бы написал этот код вот так:

 

local el0 = buffer.currentFrame[index],
      el1 = buffer.currentFrame[indexPlus1]

changes[el0] = changes[el0] or {}
changes[el0][el1] = changes[el0][el1] or {}
				
table.insert(changes[el0][el1], x)
table.insert(changes[el0][el1], y)
table.insert(changes[el0][el1], table.concat(sameCharArray))
				

По поводу нагрузки на ЦПУ:

писать "buffer.currentFrame[index]" плохо так как система будет каждый раз выполняет следующие действия:

1) получает значение переменной "buffer"

2) получает поле "currentFrame" объекта "buffer"

3) получает поле "index" объекта "buffer.currentFrame"

 

А если хранить это значение в переменной, то будет одно действие:

1) получает значение переменной "el0"

Изменено 1 сентября, 2017 пользователем RccHD

[ECS 1 903]

По поводу нагрузки на ЦПУ: писать "buffer.currentFrame[index]" плохо так как система будет каждый раз выполняет следующие действия: 1) получает значение переменной "buffer" 2) получает поле "currentFrame" объекта "buffer" 3) получает поле "index" объекта "buffer.currentFrame" А если хранить это значение в переменной, то будет одно действие: 1) получает значение переменной "el0

 

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

[RccHD Автор темы 136]

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

Всегда считал, что переменные(они же указатели на объекты) не могут занимать много памяти...

 

Хотя бы потому что исходники библиотек OpenOS прямо-таки напичканы переменными. Может дело все-таки не в таких мелочных деталях как переменные, а в самой реализации?

 

 

function buffer:readLine(chop, timeout)
  self.timeout = timeout or (computer.uptime() + self.readTimeout)
  local start = 1
  while true do
    local buf = self.bufferRead
    local i = buf:find("[\r\n]", start)
    local c = i and buf:sub(i,i)
    local is_cr = c == "\r"
    if i and (not is_cr or i < #buf) then
      local n = buf:sub(i+1,i+1)
      if is_cr and n == "\n" then
        c = c .. n
      end
      local result = buf:sub(1, i - 1) .. (chop and "" or c)
      self.bufferRead = buf:sub(i + #c)
      return result
    else
      start = #self.bufferRead - (is_cr and 1 or 0)
      local result, reason = readChunk(self)
      if not result then
        if reason then
          return nil, reason
        else -- eof
          result = #self.bufferRead > 0 and self.bufferRead or nil
          self.bufferRead = ""
          return result
        end
      end
    end
  end
end

[ECS 1 903]

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

 

В большинстве случаев дело именно в реализации, да. Если имеется какой-нибудь вшивый цикл на пару итераций, то куда выгоднее использовать локальные переменные, как ты и предлагал, чтобы минимизировать нагрузку на ЦП, это логично. Однако в нашем случае рассматривается функция, вызываемая весьма часто со множеством вложенных циклов и способная в самый неподходящий момент перегрузить сборщик мусора. В принципе, если памяти хватает - то и фиг с ним. Вообще за наводку на идею ускорения спасибо, можно вынести локальные сокращения за пределы циклов отрисовки - и тем самым сэкономить тики ЦП без ущерба для памяти. Хотя придется изрядно повозиться, да

 

А насчет исходников OpenOS - с каких это пор они стали эталоном грамотного и эффективного кода? Лично я вообще не понимаю, что в ней может кушать столько памяти (пс-с-ст, более 200 КБайт по дефолту, жуть какая). Хотя приведенный тобой пример вносит определенную ясность хд

[RccHD Автор темы 136]

Реализована возможность запуска нескольких программ одновременно!!!
В этом примере каждая программа запущена в отдельном окне 10х10 символов.



Это 2 одинаковых программы. Эта программа будучи запущенной в "одиночном" режиме занимает все окно:



Примечание: в скиншоты попал мой терминал(фиолетовая область). Я криворукий и мне лень переделывать

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

Изменено 1 сентября, 2017 пользователем RccHD

[RccHD Автор темы 136]

Осталось только сделать так, чтобы программа реагировала на события клавиатуры и мыши только тогда, когда мы переключились на нее. Ну, это легко, вроде бы
 

Изменено 1 сентября, 2017 пользователем RccHD

[RccHD Автор темы 136]

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

Приведи пример такой коллизии. Я пока не придумал ни одного

Изменено 1 сентября, 2017 пользователем RccHD

[RccHD Автор темы 136]

Вот еще интересный, красочный пример. Запустил две змейки на одном компе:



Проблема только в том, что обе змейки реагируют на нажатия клавиш, но эта проблема легко решаемая

P.S. Программу "змейка" я скачал с форума и запустил в своей ОС без каких-либо доработок

Изменено 2 сентября, 2017 пользователем RccHD

[Seryoga 184]

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

RccHD немного не убедительно написал, я попробую его поправить.

1. выполнение buffer.currentFrame[index]

    -- обращение к переменной buffer

    -- обращение к полю объекта. Но мы имеем дело с lua, по-этому buffer это HashMap а currentFrame это ключ.

        - расчёт hash("currentFrame")

        - определение смещения по хешу

        - выборка списка (может дерева) элементов по смещению из массива

        - разрешение коллизий (дорого)

        - ...

    -- выборка из полученной таблицы элемента с индексом, что приводит к 'см выше'

    -- если вы 'lucky boss' то разрешение кеш промахов (это очень затратная операция)

2.  выборка значения переменной

    -- если интерпретатор lua переменную положил на стек, то это бесплатная операция, иначе:

        - чтение данных из ОЗУ (если есть кеш, то это тоже почти бесплатная op)

        - в худшем случае разрешение 1 кеш промаха

Мне что-то подсказывает, что выполнять операцию (1) много раз не стоит.

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

Но таких проблем быть не должно.

Мне кажется, что кто-то просто забывает писать ключевое слово local.

И переменная весит ровно 64 бита.

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

то можно написать var = nil. И gc, по возможности, удалит объект, на который ссылалась переменная.

А сама ссылка удалится как закончится её область видимости (без gc).

Изменено 2 сентября, 2017 пользователем Seryoga

[ECS 1 903]

RccHD немного не убедительно написал, я попробую его поправить.

1. выполнение buffer.currentFrame[index]

    -- обращение к переменной buffer

    -- обращение к полю объекта. Но мы имеем дело с lua, по-этому buffer это HashMap а currentFrame это ключ.

        - расчёт hash("currentFrame")

        - определение смещения по хешу

        - выборка списка (может дерева) элементов по смещению из массива

        - разрешение коллизий (дорого)

        - ...

 

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

 

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

 

Ручной вызов GC в OpenComputers невозможен, эта фича отключена авторами мода по понятным причинам. Если бы я мог активировать сборку мусора - то неужели стал бы писать сюда о проблемах с локальными переменными?

 

И переменная весит ровно 64 бита.

 

Переменная весит столько, сколько определено ее типом: строки занимают 17 байт + длина самой строки, таблица кушает 40 байт + ее содержимое, каждая функция - 20 байт + локальные данные. Пожалуйста, не пиши глупости без знания матчасти.

 

Мне кажется, что кто-то просто забывает писать ключевое слово local.

 

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

[Seryoga 184]

Переменная весит столько, сколько определено ее типом: строки занимают 17 байт + длина самой строки, таблица кушает 40 байт + ее содержимое, каждая функция - 20 байт + локальные данные. Пожалуйста, не пиши глупости без знания матчасти.

Переменная весит сколько весит ссылка в ОS.

А вот объект на который ссылается переменная весит в зависимости от типа.

Как ты понимаешь ссылка это не объект на стеке и она ссылается на объект в твоей мапе который ты и так хранишь.

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

[Seryoga 184]

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

Даже если это так, то ты наверное понимаешь, что это всё равно не сравнимо с чтением объекта по ссылке.