Вот понимаешь, я смотрю на твою картинку и думаю про себя, что есть 2 типа кодеров. Даже не типа кодеров, а типа кодерского мышления, так что каждый кодер будет знаком с обоими способами думать.
Тип 1: делать код, «чтобы было». Вот прочитывается где-то описание многозадачности или просто интересно поиграть в большие машины — и пишется вот такая программа как у тебя на скриншоте. Это всё замечательно, но конечно у больших машин огромный запас вычислительной мощности + архитектура, которая вообще говоря была продумана для такого использования. И выясняется, что DI делать нельзя, что память не защищена, что машина не приспособлена. И получается какое-то разочарование, вроде прозвучавшего в твоём первом комментарии.
Тип 2: делать код для решения конкретных задач. В старых демах было обычным делом сделать декранч или распаковку с бегущей строкой или просто на чёрном экране. Реализовав двухпоточность, оказывается можно делать дему почти без швов или даже совсем без швов. Конечно, все ограничения выше остаются в силе. Ты забыл ещё упомянуть координацию потоков, чтобы данные одного потока поступали в другой без разнообразных конфликтов. Тем не менее, на выходе мы получаем то, что раньше делать не выходило.
По сути выходит, что в первом случае у тебя стакан наполовину пост, а во втором — наполовину полон.
Данный пример генерирует в 8 страницах (максимум в зависимости от карты и количества написанных объектов) код для каждого объекта игры. Этих объектов от 0 до 127, каждый может иметь логику работы, в зависимости от того, что было придумано при рисовании карты в конкретном уровне. В одном уровне объект номер 3 может быть камнем, а в втором может быть водой, какую графику подставят, и какой напишут код, то и ляжет в страницы. Далее при обработке карты на каждый объект исполняется написанная автором код. Движок игры не знает что это за объект, как его опишут такое и будет поведение.
Всё ООП не более чем описание правил в зависимости от данных, будет правило, что пришедшие данные это код, будет исполняться, просто ссылки в памяти на ссылки в другую память и обвязка тонной «ифов», а не ноль-ли там. Ну правда можно менеджером памяти пользоваться, пытаясь поймать exception'ы, ну тогда это ещё хуже «ифов», ибо скорость ПО резко снижается в разы.
В примере EXE_MAP_ADD_ALL_GROUP и занимается генерацией кодовых блоков в зависимости от данных в карте. Кодовые блоки лежат в таблице PROC_GROUP_TBL, которая генерируется автором уровня, и подгружается с носителя.
Все зависит от задачи. И за все надо платить. За наличие софта- универсальностью инструмента (стандартная ОС против узкоспециализированного ядра). За универсальность — скоростью работы и необходимостью защиты.
А вот если рассматривать «защиту системы от дурака» как право на ошибку (а человек, как известно, к ним весьма склонен), то акцент несколько смещается. И точно такой же сторонник сугубо практического применения может тебе сказать «я не хочу забивать себе голову дурацкими правилами работы с системой, я хочу просто решать задачу».
Это не дисковая утилита. Это я давным-давно увлекался темой многозадачных ОСей, в частности на спеке. Но подхватил вирус мышедрочерства графического интерфейса:)
На скриншоте честно-многозадачно работающие системный монитор, консоль, карта памяти и мегатормозной просмотрщик текста.
Вот она, истина! Точно так, ибо сложных программ не существует. И с самого начала я написал — «Thread'ы очень просты».
На АРМе я вообще не буду использовать модель MMU, не вижу в ней смысла. Меня вообще не интересует путь, где нужно защищаться от того, что автор ПО будет лезть в левые адреса, и простого переключения задач хватит на все случаи жизни. От АРМа мне нужна «молотилка данных», ну или ещё более мне важна обвязка ядра, для практического применения в разработках.
Спасибо, что делишься своими наработками.
Так же можно сказать, — «О, да, Vitamin, дышит простым 23% кислородом», и после сделать циничное выражение лица. Только вот вопрос, зачем эти слова? Цель какова?
Не надо искать в моем комментарии цинизм, сарказм или еще какой негатив — я его туда не закладывал. Это просто всплеск эмоций в связи с нахлынувшими воспоминаниями по теме (пикрелейтед).
Любой код после DI перестаёт исполнять прерывания, можно на контроллере таймер выключить, и сказать, — «ой ваш АРМ перестал задачи переключать», а можно ещё и питание выключить. Любой код после порчи его перестаёт работать.
Ну попробуй на АРМе из пользовательского пространства ОС сделать DI или выключить на контроллере таймер или испортить код.
И, кстати, любой шедуллер простейший, он состоит из простых логических действий.
По этой логике сложных программ не существует, ибо все они состоят из простых логических действий.
Прикол в том, что ты действительно реализовал самый простой циклической шедулер типа Round Robin. А есть более сложные, учитывающие приориеты и группы приоритетов, с разной вычислительной сложностью и т.п.
Речь не о ММУ или защите от говнокода/злоумышленника. Речь об удобстве распределения вычислительной нагрузки между разными задачами. Ваш КО, обращайтесь.
Любой код после DI перестаёт исполнять прерывания, можно на контроллере таймер выключить, и сказать, — «ой ваш АРМ перестал задачи переключать», а можно ещё и питание выключить. Любой код после порчи его перестаёт работать. Это просто качество написания кода, и поточность тут не играет никакой роли. Процесс нужно прибивать только после того как код этого процесса написан с учётом того, что он может сделать DI, или попортить память, — не более чем качество написания кода.
И, кстати, любой шедуллер простейший, он состоит из простых логических действий. Можно трижды написать «он простой и наколенный», но от этого ничего не изменится. Так же можно сказать, — «О, да, Vitamin, дышит простым 23% кислородом», и после сделать циничное выражение лица. Только вот вопрос, зачем эти слова? Цель какова?
Тип 1: делать код, «чтобы было». Вот прочитывается где-то описание многозадачности или просто интересно поиграть в большие машины — и пишется вот такая программа как у тебя на скриншоте. Это всё замечательно, но конечно у больших машин огромный запас вычислительной мощности + архитектура, которая вообще говоря была продумана для такого использования. И выясняется, что DI делать нельзя, что память не защищена, что машина не приспособлена. И получается какое-то разочарование, вроде прозвучавшего в твоём первом комментарии.
Тип 2: делать код для решения конкретных задач. В старых демах было обычным делом сделать декранч или распаковку с бегущей строкой или просто на чёрном экране. Реализовав двухпоточность, оказывается можно делать дему почти без швов или даже совсем без швов. Конечно, все ограничения выше остаются в силе. Ты забыл ещё упомянуть координацию потоков, чтобы данные одного потока поступали в другой без разнообразных конфликтов. Тем не менее, на выходе мы получаем то, что раньше делать не выходило.
По сути выходит, что в первом случае у тебя стакан наполовину пост, а во втором — наполовину полон.
Всё ООП не более чем описание правил в зависимости от данных, будет правило, что пришедшие данные это код, будет исполняться, просто ссылки в памяти на ссылки в другую память и обвязка тонной «ифов», а не ноль-ли там. Ну правда можно менеджером памяти пользоваться, пытаясь поймать exception'ы, ну тогда это ещё хуже «ифов», ибо скорость ПО резко снижается в разы.
В примере EXE_MAP_ADD_ALL_GROUP и занимается генерацией кодовых блоков в зависимости от данных в карте. Кодовые блоки лежат в таблице PROC_GROUP_TBL, которая генерируется автором уровня, и подгружается с носителя.
А вот если рассматривать «защиту системы от дурака» как право на ошибку (а человек, как известно, к ним весьма склонен), то акцент несколько смещается. И точно такой же сторонник сугубо практического применения может тебе сказать «я не хочу забивать себе голову дурацкими правилами работы с системой, я хочу просто решать задачу».
мышедрочерстваграфического интерфейса:)На скриншоте честно-многозадачно работающие системный монитор, консоль, карта памяти и мегатормозной просмотрщик текста.
На АРМе я вообще не буду использовать модель MMU, не вижу в ней смысла. Меня вообще не интересует путь, где нужно защищаться от того, что автор ПО будет лезть в левые адреса, и простого переключения задач хватит на все случаи жизни. От АРМа мне нужна «молотилка данных», ну или ещё более мне важна обвязка ядра, для практического применения в разработках.
Спасибо, что делишься своими наработками.
«Не надо искать в моем комментарии цинизм, сарказм или еще какой негатив»
:))
а так — реально даже часть операционки, чем кусок демо.
Это средство обеспечения надежности системы, в частности многозадачной.
Ваш адмирал Ясен Хуй.
Ну попробуй на АРМе из пользовательского пространства ОС сделать DI или выключить на контроллере таймер или испортить код.
По этой логике сложных программ не существует, ибо все они состоят из простых логических действий.
Прикол в том, что ты действительно реализовал самый простой циклической шедулер типа Round Robin. А есть более сложные, учитывающие приориеты и группы приоритетов, с разной вычислительной сложностью и т.п.
И, кстати, любой шедуллер простейший, он состоит из простых логических действий. Можно трижды написать «он простой и наколенный», но от этого ничего не изменится. Так же можно сказать, — «О, да, Vitamin, дышит простым 23% кислородом», и после сделать циничное выражение лица. Только вот вопрос, зачем эти слова? Цель какова?