Только человек должен быть довольно доверенным ))

Тут вроде исправил все, с учетом вложенности все работает

Для теста взял фрактал который кто-то уже написал на bf

Работает очень медленно (без оптимизации)

@Snusmumriken надеюсь, пишу в уместное время) Была группа pro.lua, не могу найти, мб там бот какой меня кикнул, ты вроде там админ help

@Snusmumriken надеюсь, пишу в уместное время) Была группа pro.lua, не могу найти, мб там бот какой меня кикнул, ты вроде там админ help

https://t.me/ProLua

🤷‍♂

банан

анбанан пж

Работает очень медленно (без оптимизации)

Сейчас я думаю написать компилятор под bf, сложность в том, что в bf нету условного перехода и придется через [] делать блоки if-else

Сейчас я думаю написать компилятор под bf, сложность в том, что в bf нету условного перехода и придется через [] делать блоки if-else

Блин. Прикольно)

🤷‍♂

Не нашёл тебя в списке удалённых юзеров, хмм

Странная фигня

С Пк тож не заходит, хотя группа по ссылке кликается Мб проблема на моей стороне, ток почему...

Не нашёл тебя в списке удалённых юзеров, хмм

Так скопируй его username и добавь в группу

Уже, запрещено

Я попробовал добавить, пишет что этого пользователя может добавить только администратор 🤷‍♂️

С Пк тож не заходит, хотя группа по ссылке кликается Мб проблема на моей стороне, ток почему...

Если есть 2 аккаунт, то можно с него войти

Если есть 2 аккаунт, то можно с него войти

Ну да, хотел с этого, как никак основа)

А ок, вроде прерывания работают, пока что пустой обработчик для всех прерываний, но для клавиатуры уже все работает (есть обработчик).

33 (0x21) это клавиатура. 0 это для теста заполнил пустым обработчиком, если без него в kernel.c, написать к примеру: asm volatile("int $0x00"); То ядро перезагружается, скорее всего не может обработать прерывание т.к оно было не заполнено в таблице прерываний.

Самое трудное наверно будет это реализация динамического выделения памяти

@fhello_world do you ever use PascaL ?

@fhello_world do you ever use PascaL ?

Only at school

Only at school

same my old school use turbo pascal

language is a bit pretty but not efficient, but why do all schools have this lesson for generations even if it's only 2 days.

it's the first language i know 🤣 before actionscript

my first language is C

my first language is C

awesome C is for everything

А ок, вроде прерывания работают, пока что пустой обработчик для всех прерываний, но для клавиатуры уже все работает (есть обработчик).

А исходники выкладываешь куда-нибудь?

Самое трудное наверно будет это реализация динамического выделения памяти

malloc/free? есть же уже готовые реализации, надо только под себя допилить их немного

А исходники выкладываешь куда-нибудь?

Нет, не выкладываю. По сути я ещё практически нечему не научился в osdev, возможно через какое-то время я начну лучше разбираться и тогда на github создам репозиторий

Щас я просто практически всё беру из уроков по osdev (но некоторые части уже могу сам без проблем написать, так сказать небольшой прогресс)

malloc/free? есть же уже готовые реализации, надо только под себя допилить их немного

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

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

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

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

кстати, виртуализацию памяти в системе планируешь делать?

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

Хех, сейчас регулярно борются примерно так: выделяют больше памяти для приложения ))

А что-то дефрагментировать начинают только когда уже и память и своп закончились

Есть такой интересный подход: неиспользуемая память как бы не нужна. Типа, что толку от твоих 64гб оперативки, если не использовать их на 100%?

В результате, правда, когда надо запустить что-то свежее или память таки начинает заканчиваться, ос судорожно начинает чистить под это место

А что-то дефрагментировать начинают только когда уже и память и своп закончились

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

Да я просто смотрю например на организацию памяти ведра, например, и она настолько же упоротая, для телефона, несколько смешная.

Мало того, для планшета или например ноутбука - точно так же смешно.

Заметно буквально следующее: Ведру даже в режиме энергосбережения насрать на время автономности, количество и нагрузку фоновых процессов и так далее. Он не может в менеджере сделать простои для них, обязательно выводить все всплывающие окошки СРАЗУ а не условно раз в несколько секунд для экономии. Ведро не будет нормально "усыплять" процессы или суспендить, если они сами этого не делают. Плюс обожает гонять свои службы, в тысячный раз индексируя одно и то же наплевав на заряд батареи и то, что телефон не подключен к зарядке.

кстати, виртуализацию памяти в системе планируешь делать?

Да, т.к система многопоточная должна быть

Как виртуализация влияет на многопоточность?

Ответ: никак

Знаешь зачем виртуализация памяти в принципе нужна?

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

Как виртуализация влияет на многопоточность?

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

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

Ты думаешь, хоть кто-то ДУМАЕТ где он располагается?

Ты получаешь от ОС поинтеры определённого размера — трахайся с ними как хочешь.

Единственная разница — без виртуальной памяти, читая рандомные участки ты можешь прочитать память других приложений, или записать в память других приложений. С виртуальной памятью — нет. Но процесс замедляется на проверки доступа и трансляцию указателей туда-сюда-обратно. Это ВСЯ разница.

Ты получаешь от ОС поинтеры определённого размера — трахайся с ними как хочешь.

виртуализация памяти это ещё и возможность... барабанная дробь... борьбы с фрагментацией памяти xD. Так как все блоки одинакового размера - переставлять и миксовать их можно как угодно (но желательно чтобы у одного потока его блоки находились поближе)

А то что у тебя условно начальный поинтер в приложении начинается с 0 или с 12345667 — для тебя, как для писателя приложения, не играет вообще ничего. Это просто цифра.

виртуализация памяти это ещё и возможность... барабанная дробь... борьбы с фрагментацией памяти xD. Так как все блоки одинакового размера - переставлять и миксовать их можно как угодно (но желательно чтобы у одного потока его блоки находились поближе)

На самом деле ОС может выделять блоки памяти для приложений вперемешку. N байт приложения А, M байт приложения Б, F байт приложения А.

Просто если приложение А что-то избыточно запишет в свой первый блок, оно запишет в приложение Б, и то похерится.

Странички — тоже тема на самом деле, потому что их просто переставлять и чистить, плюс на индексацию уходит меньше памяти чем каждому выдавать "ровно запрошенный" диапазон, но те же косяки что и у харда.

А то что у тебя условно начальный поинтер в приложении начинается с 0 или с 12345667 — для тебя, как для писателя приложения, не играет вообще ничего. Это просто цифра.

Дело в том, что приложение залезлит в память другого приложения и всё там сломает

Дело в том, что приложение залезлит в память другого приложения и всё там сломает

Дело в том, что приложение залезлит в память другого приложения и всё там сломает

Чел, я это написал буквально четыре раза.

На самом деле ОС может выделять блоки памяти для приложений вперемешку. N байт приложения А, M байт приложения Б, F байт приложения А.

и в этом и проблема - выделение блоками гораздо удобнее для системы - приложение запрашивает у системы больше блоков - она добавляет их ему к последнему блоку (так в лине работает вроде), и 1. никто ни с кем не конфликтует 2. можно писать свой аллокатор в приложении и паковать данные максимально плотно в нём же, а ОС самой решать как распоряжаться блоками.

Не, приложение запрашивает у системы больше блоков — и они присобачиваются куда угодно в физической памяти (ну, со смещением страниц). Виртуальная же память как бы непрерывна.

Чел, я это написал буквально четыре раза.

У меня интернет не стабильный в дороге

Сообщения не сразу доходят

Не, приложение запрашивает у системы больше блоков — и они присобачиваются куда угодно в физической памяти (ну, со смещением страниц). Виртуальная же память как бы непрерывна.

если нет никакого алгоритма расположения блоков поближе для минимизации промахов, то да.

если нет никакого алгоритма расположения блоков поближе для минимизации промахов, то да.

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

если нет никакого алгоритма расположения блоков поближе для минимизации промахов, то да.

А что ты имеешь ввиду под промахами? Какие тут могут быть промахи? Это же не кеш.

Трансляция из виртуальной в реальную память будет проводиться в любом случае, без промахов, потому что просто есть табличка трансляции, промахиваться некуда. Просто добавляешь к виртуальному указателю смещение для данной странички, и всё.

Гипотетически, можно "промахиваться", если дополнительно оптимизировать эти смещения, на стыках страничек.

Дело в том, что приложение залезлит в память другого приложения и всё там сломает

ещё кстати виртуальная память позволит осуществлять mmapинг... файлов например, группировку одинаковых readonly страниц, выгрузку неиспользуемых страниц в подкачку и т.д и т.п. А самими страничками можно жонглировать как угодно и подстраиваться под плюсы и ограничения оперативки на которой система работает.

Трансляция из виртуальной в реальную память будет проводиться в любом случае, без промахов, потому что просто есть табличка трансляции, промахиваться некуда. Просто добавляешь к виртуальному указателю смещение для данной странички, и всё.

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

Не, кеш это кеш, кеш действительно подгружает "ближние" данные из физической оперативки. Просто.. Чем больше странички тем меньше промахов. На стыках — да, будут промахи, как это и происходит ирл. И в этом нет ничего особенно страшного — промах означает подгрузку из свежей области. Ну например. Допустим, у тебя аудиофайл который ты.. Нормализуешь по громкости? Каким-нибудь линейным однопроходным алгоритмом. Он расположен на трёх виртуальных страничках, расположенных вразнобой. И при его последовательной обработке будет три промаха кеша. И всё. Тысячи промахов? Миллионы? Нет ))

good night