Разве микроядро не тормоз?

>>1017411
>Разве микроядро не тормоз?

На этот счёт есть разные мнения. Чтобы ответить на этот вопрос нужно понять, откуда пошло.

Пожалуй, самым ярким сторонником микроядер считатается Эндрю Таненбаум и его Minix. Minix это микроядерная ОС для архитектуры x86 написанная для учебных целей.

Главный оппонент Таннебаума - Линус Товральдс. У них был эпический спор, в котором, отчасти благодаря темпераменту Линуса, он победил. С тех пор пошла молва, что микроядра это тормоз. Это предыстория.

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

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

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

Ну и вторая причина мнения о тормознутости микроядер происходит когда драйвер или подсистема ядра запускается как пользовательская задача. В этом случае обращение к драйверу/иодулю произзводят переключение контекста со сбросом TLB, что занимает много тактов на его актуализацию.

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

Подпишусь на тред на всякий случай, как интересующийся FPGA. Это сложно вообще, если я веб-макака без вузовских знаний?

Что на счет использования аналоговых компонентов и, например, FPAA?

>>1017426
>Это сложно вообще, если я веб-макака без вузовских знаний?

Это не сложно, если есть интерес, то можно и самому. Однако, нужны базовые знания о булевой алгебре и электронике.

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

>>1017428
>Что на счет использования аналоговых компонентов и, например, FPAA?

Я в аналоговой части не силён. Ну, что-то навроде Covox ЦАП могу соорудить и, вероятно, посчитать со справочником. А вот обратно из аналога в цифру, такого опыта не имею. Хотя во многих современных алтеровских и ксилинковских ПЛИСах есть АЦП и инструменты работы с ними. Например, Картусе можно найти подходящую мегафункцию.

>>1017429
Есть базовые знания по дискретке. Схемотехника нужна? А где кроме Танненбаума нормально про логические вентили можно прочитать?

>>1017431
>Картусе
Квартусе же.

>>1017406 (OP)
Какой профит от всего этого? Какие проблемы решает? И чьи проблемы?

>>1017434
>Схемотехника нужна?
Базовых понятий для начала хватит. Когда будешь вытягивать частоту из своей схемы, придётся использовать множество инструментов из Картуса. Но чтобы начать это не нужно. Ставишь делитель частоты на основе PLL и сильно не паришься.
Возможно я тебя подбадриваю, но если пользоваться примерами и демками, то начать довольно не сложно.
Кстати, если всерьёз интересуешься, то вот хорошее место где обитают плисоводы - https://marsohod.org/


> А где кроме Танненбаума нормально про логические вентили можно прочитать?


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

>>1017437
Добра, анон! Рад очередному небыдлокодерскому треду.

>>1017436
>Какой профит от всего этого? Какие проблемы решает? И чьи проблемы?

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

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

>>1017440
Ну а в реальной жизни прямо сейчас, есть профиты интересоваться этим? Я понимаю интерес к машинному обучению, его можно применять сегодня же, и оно решает определенные задачи. Понимаю интерес к новым языкам вроде Rust, они решают свои задачи, и их можно использовать уже сегодня.

А какие задачи могут решать эти микроядра не понимаю. Вот сижу я на Линуксе, пишу код, что мне могут дать эти микроядра? Не понял для чего они нужны, с чем конкурируют. Для чего мне этим заниматься, пытаюсь найти интерес для себя?

Чем отличается microkernel от unikernel?

>>1017440
>Полезно для ответственных применений - например, в космосе или в атомной энергетике.

QNX и VxWorks активно используются в космосе и авионике.

>>1017446
>Ну а в реальной жизни прямо сейчас, есть профиты интересоваться этим?

Некоторые профиты есть. Легче найти работу - конкуренции меньше. Большой выбор стран, где востребованы такие специалисты.

>А какие задачи могут решать эти микроядра не понимаю.

Например, ровер Curiosity использует в качестве операционной системы VxWorks.

> Вот сижу я на Линуксе, пишу код, что мне могут дать эти микроядра?

Встречный вопрос - твоему коду важен именно Linux или POSIX совместимость? Будет ли работать твой код, например, на FreeBSD?

> Не понял для чего они нужны, с чем конкурируют.

С Real Time Operating System. Условно, в интеллектуальную кофеварку ты можешь воткнуть Embedded Linux, а можешь и QNX или VxWorks. Во втором случае ты, вероятно, сэкономишь на "железе", ибо требования к нему будут меньше.

> Для чего мне этим заниматься, пытаюсь найти интерес для себя?
А зачем? Если не интересно - не пытайся. Делай то, что тебе нравится. Но если хочешь поработать за границей, то эти знания пригодятся.

>Чем отличается microkernel от unikernel?
Простотой. Единое адресное пространство для всех задач у unikernel. В то время как современные микроядра предлагают изолированные адресные пространства.

>>1017446
>А какие задачи могут решать эти микроядра не понимаю
Обеспечение стабильности ядра и переносимости кода, который в монолитном ядре является аппаратно-ависимым.

18 сентября в Мюнхене будет конференция Minix, до 4 сентября для студентов билет будет стоить 30 евро.

>>1017452
>Некоторые профиты есть. Легче найти работу - конкуренции меньше. Большой выбор стран, где востребованы такие специалисты.
Вряд ли. Системщики сейчас никому не нужны. Если и нужны, то задачи там неинтересные.

>Встречный вопрос - твоему коду важен именно Linux или POSIX совместимость? Будет ли работать твой код, например, на FreeBSD?
Разницы нет. Я привел линукс как свою домашнюю ОС. То есть мои задачи решает полноценная ОС, а значит как пользователю профита от микроядра мне нет.

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

>А зачем? Если не интересно - не пытайся. Делай то, что тебе нравится. Но если хочешь поработать за границей, то эти знания пригодятся.
Вот именно, что эта не та сфера где есть задачи и спрос. Поэтому и спрашивал про задачи, дабы понять для чего это. Теперь ясно. Спроса на это нет. Проще найти работу на Haskell.

>>1017472
>Системщики сейчас никому не нужны. Если и нужны, то задачи там неинтересные.
Нужны нужны. Чем развитее IT в стране, тем выше ценятся системные программисты. Ну и интерес это как бы дело личного вкуса.

> как пользователю профита от микроядра мне нет.
Так это штука и не для пользователей. Во всяком случае пока. Но где-нибудь в недрах твоего автомобиля ему место есть.


> Это экономия на спичках.
Зависит от вала. Например, неоторые производители современных телевизоров ставят в свои изделия безумно дешевый специализированный процессор. При тех количествах продукции, которую они производят, цена имеет значение.

>Микроядро под каждую архитектуру писать не будешь.
Все популярные микроядра уже портированы на все популярные процессоры.

> К тому же писать на ассемблере очень долго и неудобно. Проще взять высокоуровневый язык.
Так и не пишут сейчас на ассемблере под микроядра. На Си и С++. В прикреплённой теме, в которой я начал повествование, речь шла о о конкретном процессоре с оригинальной системой команд, который реализован только в FPGA. Ну да, я хочу плавно подвести тему к этому устройству. Несколько позже. Когда народ втянется в обсуждение.

Кстати, вот эта вот модульность микроядер позволяет писать модули в том числе и на Паскале. Но при этом придётся отказаться от готовых библиотек и реализовывать их самому. И это не будет "костылями".

>>1017491
Ручное управление памятью ненужно.

>>1017502
Ещё скажи, что динамического управления памятью хватит всем.

>>1017502
Потомки, как там в 2030?

>>1017502
Память не нужна

>>1017508
>>1017541
Почти всегда хватает. Про расиянские контроллеры речи не идет. Например Erlang давно используют в телефонии. Его можно запускать без операционной системы.

>>1017508
>>1017541
Про какой объем памяти идет речь?

>>1017561
>Его можно запускать без операционной системы.
Ещё скажи что он сам на себе написан.

>>1017597
Насчет Эрланга не интересовался, а вот компиляторы Си, Go, Python, Ruby, Scheme, etc - написаны на самих себе. Почему язык не может исполнять самого себя, если он Тьюринг полный?

>>1017597
Раскрутка компилятора - метод написания транслятора для языка, при котором транслятор пишется на том же языке.

Список самотранслирующихся языков:

Ada
BASIC
BCPL
Burroughs Algol
C
C++ (compilers: Visual C++, clang, probably others)
C# and Visual Basic .NET via Microsoft Roslyn
Ciao
Cobol
CoffeeScript
Common Lisp
Crystal
Curry
D
Delphi
Eiffel
F#
>FASM
Factor
Forth
Free Pascal
Go
Haskell
LiveScript
Java
Mercury
Modula-2
Nemerle
Nim
Oberon
OCaml
Pascal
Perl 6 (compilers: Rakudo Perl & Niecza Perl 6 are both self-hosting)
PL/I
Python
Rust
Scheme
Scala
Smalltalk
SML
TypeScript
Virgil[5]
XPL

https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

>>1017485
>Нужны нужны
Но сейчас вакансий в России очень мало, да и те, в основном, либо НИИ, либо военная промышленность.

>>1017615
>Раскрутка компилятора - метод написан

Что было первым - курица или яйцо?

Когда уже есть стабильно работающая версия какого-то языка, то можно и реализовать его на самом себе. А самую первую версию?

>>1017644

Есть разные подходы, один из них такой:

Создание транслятора языка L методом раскрутки подразумевает выполнение некоторых шагов.

На первом шаге из языка L выделяется подмножество L0, которое не требует больших усилий для реализации, но является достаточным для написания транслятора самого себя. Затем, используя какой-либо существующий для этой платформы язык (например, C), составляется исходный код транслятора для L0.
Затем на языке L0 составляется транслятор для самого языка L0. Исполняемый файл транслятора создаётся с помощью транслятора, полученного на первом шаге. После этого у программиста имеется транслятор L0, способный обработать свой исходный код.
Далее начинается постепенное расширение L0 до L: добавляется какая-либо ранее не реализованная возможность языка L, после чего предыдущей версией транслятора создаётся новая, а вновь добавленную возможность можно использовать в трансляторе для последующего расширения языка.

Скопировано с википедии.

>>1017628
Как бы да. Я особо не с этим не спорю. Но надеюсь что со временем ситуация выправится. Да и заграницей перед системными программистами открыто больше дверей.

И всё же давайте обсуждать тут технические аспекты, а трудоустройство обсудим в других темах.

>>1017651
А что обсуждать. Писать надо. Ты в этом больше разбираешься, накинь какая платформа и функционал нужны.

http://www.barrelfish.org/

Давно уже думают.

>>1017406 (OP)
Ты пишешь на ассемблере? Как на асм реализуют конкурентность и параллельность?

>>1017653
>накинь какая платформа и функционал нужны.

Мне нужно пару дней чтобы оформить мысли. Речь идёт о двух с половиной проектах, которые должны соединиться в единое целое. Извини, что приходится уклоняться от прямого ответа.

Сегодня предлагаю посмотреть на, пожалуй, лучшее из всех когда либо существовавших в истории микроядер - https://github.com/l4ka/pistachio

Чтобы ознакомиться с ним понадобятся Linux со средствами разработки (g++, gnu toolhain, etc) и виртуальная машина, любая на выбор - VmWare, VirtualBox, MS Virtual PC или любая другая. Она понадобится чтобы запускать в ней микроядро и если кто использует Windows на своём десктопе, то в виртуальной машине придётся поселить Linux.

Если делать всё по инструкции, можно собрать образ загрузочной дискет с тестовыми программами, этот образ можно подсунуть виртуальной машине и загрузиться с него. Разумеется, ни о какой графической оболочке речь не идёт. На демке микроядра даже не будет командной строки, файловой системы - вообще ничего, только микроядро, представляющее некоторый интерфейс. Это на порядок меньше чем предоставляет даже голое ядро Linux.

Не страшно ещё?

>>1017658
>Ты пишешь на ассемблере? Как на асм реализуют конкурентность и параллельность?

В прикладной программе реазовывать такие фичи бессмысленно и неэффективно. Тогда уж лучше суперцикл.

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

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

>>1017681
176 712 строк кода. Чей это проект вообще и почему не развивается?

>>1017681
Писать столько кода на C/C++ это боль. Как вариант Ocaml.

>>1017689
>176 712 строк кода. Чей это проект вообще и почему не развивается?

Это проект университета Karlsruhe. Почему он не развивается - есть несколько причин. Где-то четыре - 1) сообщество не раскушало все прелести, 2) подковёрный конфликт между университетом Karlsruhe и университетом UNSW
3) лучших результатов на основе этого ядра достиг неправильный человек с проектоом с неправильной лицензией, 4) вероятно, ВПК Германии не очень приветствует распространение этой штуки.

Но я не утверждаю что вторая и четвёртая причины реальны. На уровне слухов и догадок.

Почему бы не экзоядро?

>>1017695
>Писать столько кода на C/C++ это боль. Как вариант Ocaml.

Эта штука работает напрямую поверх железа. Ниже уровня уже не бывает. Чтобы на этом запустить Ocaml, понадобится несколько программных слоёв между микроядром и Ocaml.

>>1017700
>Почему бы не экзоядро?

L4 Pistachio довольно близко по смыслу к тому, что называют экзоядром. API минимален - абстагированы процессы/нити и адресные пространства.

>>1017701
Зачем запускать окамл на ядре. Написать ядро на окамле. Он компилируется в машинные коды.

>>1017701
Еще есть конкатенативные языки программирования как интересная альтернатива.

>>1017406 (OP)
https://stepik.org/course/Операционные-системы-1780/syllabus

Я ньюфагам (себе в том числе) покушать принес.

Вы что-то с обработкой сигналов (и в частности сигнальными процессорами) будете городить?

>>1017729
> Написать ядро на окамле. Он компилируется в машинные коды.

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

Но я бы в такой проект не подвязался.

>>1017738
Почему не на Rust?

>>1017733
>Вы что-то с обработкой сигналов (и в частности сигнальными процессорами) будете городить?

Не совсем. Задача поместить нечто навроде микроядра L4 непосредственно в железо. Ну а дальше как получится.

Что касается блоков обработки сигналов, то вероятно будет рассматривать их как отдельные функциональные блоки в составе процессора или в виде сопроцессоров.

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

А каков бамплимит у тем в /po/?

>>1017738
Да. Он позиционируется как замена C/C++, при чем в некоторых тестах он быстрее их.

>>1017741
Первый компилятор Раста был на Окамле, потом его переписали на Раст.

>>1017747
Ты смотрел forth-процессоры?

>>1017741

Хочу сразу раз и навсегда ответить на такие вопросы. Само по себе микроядро это нечто очень простое, выполняющие лишь функции по управлению задачами и адресными пространствами. Благодаря взаимодействию посредством сообщений, нет нет необходимости помещать все задачи в единый исполняемый модуль. Поэтому, например, сетевой стек TCP/IP при желании можно написать на любом языке, независимо от того, функциональный он или процедурный, в простейшем случае компилятор должен уметь генерировать объектные файлы в формате ELF. Или в каком-то другом - не суть важно.

Нельзя лишь использовать интерпретаторы или среды программирования, которые генерируют исполняемый код посредством линковки исходного текста программы и интерпретатора, оформляя это в виде исполняемого файла.

>>1017758

Конечно. Обратная польская запись - нашё всё.

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

>>1017763
>Просто говорю, что вместо микроядра пожалуй в железо лучше впихнуть нечто другое.

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

>>1017759
У тебя есть опыт написания ОС?

>>1017741
>Почему не на Rust?
Зачем кучу времени на изучение нового (сложного) языка?

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

>>1017759
То-есть фитчи типо kernel-alloc тоже будут как модули и можно будет их заменять?

>>1017806
>>в некоторых тестах он быстрее их.
>Синтетические тесты мало говорят о реальной производительности.
На окамле скорость разработки минимум в 2 раза быстрее чем на крестах, и кода меньше будет раза в 4. Устраивает такой ответ?

>>1017780

Да, у меня есть такой опыт.

>>1017806
>То-есть фитчи типо kernel-alloc тоже будут как модули и можно будет их заменять?

В общем случае - да. Суть в том, что микроядре L4 работа с памятью реализована.... необычно и оригинально. Одновременно с микроядром стартует самый первый процесс - Sigma0, который владеет АБСОЛЮТНО ВСЕЙ оперативной памятью. В момент инициализации микроядро запрашивает несколько страниц под свои нужды.
Вся дальнейшая работа происходит через запрос маппинга физических страниц в адресное пространство задачи. Никаких аллокаторов микроядро L4 не предоставляет. Нужна эмуляция POSIX malloc? Пожалуйста - пиши свою реализацию аллокатора. Если нужно превратить микроядро в полноценное ядро, то придётся реализовывать системный вызов sbrk.

Другая фишка страничной памяти L4 это так называемые flexpages - фича, эмулирующая страницы с произвольым размером кратным размеру физической странице, поддерживаемой процессором, умноженным на 2 в степени N.
Где N, условно, произвольное число.

>>1017834
Что читать чтобы такие штуки писать? Подкинь литературы плиз.

>>1017837

Начать наверное лучше с Таненбаума.

Операционные системы: разработка и реализация ISBN 5-469-00148-2
Современные операционные системы, ISBN 978-5-498-07306-4
Архитектура компьютера ISBN 5-469-01274-3

Yf Хабре иногда толковые статьи на эту тему появляются.

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

Ещё неплохо разбавить это всё Майкрософтом. Вот можно почитать (на английском языке) о разработке драйверов для Windows - https://docs.microsoft.com/ru-ru/windows-hardware/drivers/gettingstarted/index

>>1017839
Пасиб

>>1017837

Есть хорошая книга - Ядро Linux. Описание процесса разработки.

>>1017806
>Синтетические тесты мало говорят о реальной производительности.
Собственно, там даже если обгоняет Си тот же, то ценой повышения потребления памяти.

>>1017770
>абстракцию понятия "задача", а в систему команд несколько инструкций для обмена сообщениями между задачами
Что-то знакомо, можно подробней? Это похоже на транзакционную память?
>аппаратный планировщик задач
Посмотрел немного это чудо. Говорят, что благодаря хитрой аппаратной схеме аппаратного планировщика задач получается сэкономить на переключении контекста. Но если брать стековые процессоры то там чудным образом переключение контекста уже и так стоит копейки (ибо используется в основном стек, конечно же, хех). Ты в общем посмотри на стековые процессоры и MISC, а так да, стремление к множеству ускорителей и гетерогенности вычислений весьма хорошо как по мне.

>>1017947
>схеме аппаратного планировщика задач получается сэкономить на переключении контекста
Странно, что интел/АМД не дают доступа к полному файлу регистров. Там же их сотни сейчас, и используются они только для переименования регистров. Почему бы не дать возможность скидывать/восстанавливать контекст? Гипертрединг же они туда привинтили, который по-сути именно это и делает - переключает исполнительный модуль на первый или второй набор регистров для эмуляции двух ядер.

>>1017947
>Но если брать стековые процессоры то там чудным образом переключение контекста уже и так стоит копейки
Ты и на регистровых так можешь сделать, если будешь точно знать, какие регистры используются процессом, и сохранять не все ебучие килобайты включая AVX-512, а только нужные. Им только нужно добавить инструкцию, которая позволит компилятору с некоторой периодичностью метить используемые/неисопльзуемые регистры.

>>1017980
>Почему бы не дать возможность скидывать/восстанавливать контекст?
СЛОЖНА
НЕПОНЯТНО НИЧЕГО
ЯДРА КАКИЕ-ТО
ПАРАЛЛЕЛЬНОСТЬ БЛЯДЬ!


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

Говно говном погоняется.

Итаниумы вон похоронили даже.

Сложна, непонятно.


А ТУТ ВЗЯЛ И СРЕШЬ КОД КАК БУДТО У ТЕБЯ ОДИН ПОТОК ИСПОЛНЕНИЯ
А ОС САМА ВСЕ ПОПЕРЕКЛЮЧАЕТ НАХУЙ
СЕГФОЛТ ПРАВДА ВЫСКОЧИТ И ДЕДЛОК
ЗАТО ПРОСТО И ПОНЯТНО

>>1017418
>растёт латентность
Переводишь как дебил. Сам читаешь что пишешь?

>>1017986
>если будешь точно знать, какие регистры используются процессом, и сохранять не все ебучие килобайты включая AVX-512, а только нужные.
Может я немного подзабыл, но кажется это NP-полная задача, особенно вроде выделение регистровой памяти.
>Им только нужно добавить инструкцию, которая позволит компилятору с некоторой периодичностью метить используемые/неисопльзуемые регистры.
И как это сделать аппаратно? Или компилятор... Как компилятор это будет делать? Кажется всё упирается в детали...

Да и просто я так могу предположить, что во всяких интелах и амд сидят умные люди и если бы это всё дало прирост без тех же проблем с совместимостью — тогда бы и внедрили.
И хотя сейчас я буду говорить как рекламный буклет, но всё-же. А вот если не стоит цели совместимости (хотя в общем, те же forth-процессоры, если хитро сделать могут запускать хоть php c небольшими накладными расходами, но то другое. Хотя в целом forth-процессоры как-раз хорошо подходят под языки высокого уровня) то тут прекрасно подойдут стековые процессоры, в том числе с асинхронной логикой. Вообще стековые процессоры как можно видеть дают много преимуществ — не порождают сотни лишних абстракций, переключения контекста и выделение памяти под локальные переменные проще простого, их простота и конечно же действительно возможность сделать крутой компилятор с действительно хорошими оптимизациями, а не так как сейчас, когда до некоторого уровня. В целом, эффективны (в том числе, энергоэффективны), низкая себестоимость и хорошая производительность, выжимает много. Нюансы решаемы. В общем, стековые процессоры заточены под реальность.
Но на данный момент они используются лишь в космической и военной промышленности. Ну, и асинхронная логика, которая в корне отличается от существующей требующей
синхронизации (от сюда и вся эта тактовая частота) и реализована, например, в процессоре GA144.
>Полностью асинхронное решение — никаких глобальных тактовых линий, никаких локальных схем тактирования ядер. Применена так называемая самосинхронная
схемотехника: сигналы, управляющие работой отдельных узлов процессорного ядра, генерируются по ходу выполнения инструкции. Подобное решение позволяет сократить
расход энергии за счет отсутствия тактовых генераторов и схем, управляющих их работой. В то же время скорость работы повышается вплоть до пределов используемой техно‑
логии изготовления самосинхронной схемы.
>Некоторым минусом можно считать появившуюся зависимость скорости работы схем от температуры (рис. 3) [17] и напряжения питания (рис. 4) [17], и определенный разброс по времени выполнения процессорных инструкций различного типа [13, 17].
Источник: http://kit-e.ru/assets/files/pdf/2011_11_111.pdf

В общем, я считаю, что вряд-ли принципиально новое и интересное можно надыбать в современных широко используемых процессорах. А вот стековые процессоры стоят того,
что бы их посмотреть. Ну, и немного пропагандистки можно упомянуть, что сходное используется (или почти) в различных вроде как java-ускорителях аппаратных и вообще внутри jvm,
что позволяет java хоть немного не тормозить и/или быть энергоэффективной. Ну, еще можно вспомнить http://sergey-frt.narod.ru/frt_sci.html где кучу всего (включая, например, простенькую игру с квадратиками, вывод графиков, разные программы чуть попроще и конечно же запускалку форта) вместили в где-то около 40 килобайт, может чуть меньше. И это для телефонов с j2me! Вспомнил, кстати историю какую-то, там заключенный решил учить программирование в тюрьме и ему нужно было что-то эдакое как-раз. Все советовали ему какие-то громоздкие онлайн-версии интерпретаторов, а это, наверное могло бы ему помочь. Ну, и опять о процессорах. Они не требуют никаких особых метаматериалов и могут быть сделаны на техпроцессе 350 нм.

>>1017993
Полностью согласен. Такие монструозные абстракции плохи. А если бы компилятор имел полное представление о процессоре (с MISC это было бы не так и сложно) то всё было бы отлично.

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

>>1018030
>Как компилятор это будет делать?
Во время аллокации регистров, например. Компилятор же все используемые регистры видит. Не обязательно к тому же метить каждый регистр. Достаточно говорить, что тут, например, включили использование SSE-AVX, тут выключили. И при переключении контекста можно будет сохранять только целочисленные регистры.

>>1018030
>Вообще стековые процессоры как можно видеть дают много преимуществ
У них основная проблема в том, что сложно делать суперконвейерность. Каждая инструкция мутирует стек, результат инструкции зависит от предыдущих, и поэтому сложно запускать в работу несколько инструкций сразу. Мур на GA144 все очень хитрожопо сделал - в машинное слово упаковываются сразу четыре инструкции, причем возможны "микроциклы" внутри этих четырех инструкций. Так он делает умножение, например: в одно слово упаковываются сложение, сдвиг и микроджамп. Только он пишет все это вручную, потому что на таком ограниченном железе как у него, ни один компилятор с оптимизацией не справится. То есть для форт-машин нужны в первую очередь форт-программисты. А обычный кодер как Мур вряд ли может работать. Тот же ОКАД, например, он десятки лет пишет и переписывает, постоянно упрощая и убирая ненужное. В таком режиме не один заказчик не даст работать.

Что за язык на ОП-пике?

>>1018030
>Полностью согласен. Такие монструозные абстракции плохи. А если бы компилятор имел полное представление о процессоре (с MISC это было бы не так и сложно) то всё было бы отлично.

Компиляторы должны быть проще.
Гепероптимизуриющие gcc - тупиковая ветвь, как мне кажется.

Программа должна быть ближе к аппаратной архитектуре(что не противоречит высокому уровню абстракций).

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

>>1018041
>суперконвейерность
суперкостыльность

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

>>1018056
Verilog

>>1018056
>Что за язык на ОП-пике?

https://ru.wikipedia.org/wiki/Verilog

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

>>1017947

Вот тут >>1017685 рассмотрены некоторые варианты переключения контекста, когда в работу вступает планировщик.

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

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

Но если "железо" аппаратно поддерживает многозадачность и имеет средства передачи сообщений, то это именно то место, в котором в подавляющем большинстве случаев будет переключаться контекст.

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

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

Увы. Я не могу выразить это более понятно или наглядно, может быть позже покажу примеры в коде.

>>1018095
Три дороги ведут в системное программирование:
1) программирование микроконтроллеров
2) программирование драйверов для Linux или патчи ядра
3)программирование драйверов для Windows

Ещё можно "на коленке" попытаться написать свою операционнку, но 99 из 100 программистов останавливались где-то на этапе написания начального загрузчика, вместо того чтобы использовать grub.

>>1018068
>Проблемы с параллелизмом возникают, когда аппаратная платформа начинает маскировать свою параллельную природу.
Ну так можно и сложение за 32 такта делать вместо одного. Зато блок АЛУ и параллелизм не маскируется.

>>1018106
>Увы. Я не могу выразить это более понятно или наглядно, может быть позже покажу примеры в коде.
Программные прерывания не можешь выразить это более понятно или наглядно а хотя аноним с двачей, понятно, понятно...

>>1018110
>но 99 из 100 программистов останавливались где-то на этапе написания начального загрузчика
Потому что надо сразу микроконтроллер брать, а не ебать себе мозг легаси-начинкой x86.

>>1018111
>Зато блок АЛУ
Блок АЛУ маленький. fix

>>1018110
Планирую вкатиться в микроконтроллеры.
С чего начать?

Сдилойти ОС, которая будет сидеть в кеше процессора и не будет занимать ОЗУ.

>>1018110
А как насчет реверс инжиниринга. К чему он ведет?

Если кому надо, курс - Разработка модулей ядра Linux

https://stepik.org/course/%D0%A0%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9-%D1%8F%D0%B4%D1%80%D0%B0-Linux-(08)-2051

>>1018175
Я думал вы тут будущее обсуждаете, а не всякую монолитную хрень, которую скоро заменят SystemDOS.

>>1018178
>которую скоро заменят
Уа-ха-ха, виндавс себе замени.

>>1018192
Ты не понял шютки? Операционная система на основе Systemd — SystemDOS. И полный отказ от юниксвея.

>>1018178
Ебало завали.

>>1018175
Ставь пробел перед выделеним ссылки.
https://stepik.org/course/Разработка-модулей-ядра-Linux-(08)-2051/syllabus

>>1018137
К саморазрушению. Выбирай жизнь

>>1018198
куда ставить?

>>1018196
Линух превратился в огромный костыль.

>>1018198

Сработало. А что дает пробел?

https://stepik.org/course/Разработка-модулей-ядра-Linux-(08)-2051/

>>1018202
Какую ОС юзаешь?

>>1018131
>Сдилойти ОС, которая будет сидеть в кеше процессора и не будет занимать ОЗУ.
Есть такие. Тащить любой Dos.

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

>>1018203
Очередная ебля с порядком байтами в utf вроде.
Уже не помню.

>>1018111
Я хз что ты имеешь ввиду.
Производительность возрастет.

>>1018207
Haiku Нет. Просто дистрибутив без systemd.

Нашел интересную книгу, мож кому пригодится

Low-Level Programming: C, Assembly, and Program Execution on Intel 64 Architecture

Легко гуглится для скачивания

>>1018253
фонатег штоле, че не так с systemd?

>>1018261
https://github.com/systemd/systemd/issues/6237
Не баг, а фича.

>>1018310
Слушай, написание виртуальной машины типа JVM и написание операционной системы схожи по задачам?

>>1018310
> системы команд
К какой системе команд она преближена?

>>1018316

Честно говоря - не знаю. Но могу предположить что что-то общее есть.

>>1018310
> Отсутствие аппаратного стека - стек "по соглашению"
В смысле, регистр можно выбрать самому и нет явных push/pop? У половины RISC-архитектур так.
> Операции с плавающей запятой не определены
Инстант фэйл.
> Спроектирована с учётом аппаратной поддержки многозадачности
А интел дропнул аппаратное переключение. Ну дураки, что с них взять.
> Абсолютно все переходы относительные - используется знаковое смещение от адреса инструкции
Прямо абсолютно все? Indirect-то хоть есть?

>>1018321
>К какой системе команд она преближена?

Вдохновлялся различными архитектурами, старался заимствовать идеи от PDP-11, x86 и от RISC. Вот вот сказать что она похожа на кого-то - не могу.

Например, долго боролся с проектированием стека - вводить ли PUSH/POP или делать как у RISC. У каждого решения свои плюсы и минусы, в результате решение отказаться аппаратнного указателя стека от перевысило.

>>1018310
>прототип устройства работает
Какой-нибудь софт уже есть под него?

>>1018316
Совсем не схожи.

>>1018329
Я со своей рекламой стековых процессоров начал вызывать ненависть даже ко стеку?

>>1018316
Если не идет речи о виртуальной машине работающей под некоторой ОС то весьма схожи.

>>1018328
>В смысле, регистр можно выбрать самому и нет явных push/pop?

Да. Но по соглашению это регистр R14

> У половины RISC-архитектур так.
Угу. Я в курсе.

>> Операции с плавающей запятой не определены
>Инстант фэйл.

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

>А интел дропнул аппаратное переключение.
Ты имеешь в виду переключение задач через TSS?

>Прямо абсолютно все? Indirect-то хоть есть?
Есть, но только один регистр позволяет это - регистр R15. Собственно, это команда RETURN.
RETURN это переход под адресу, который является содержимым регистра R15

>>1018333
> Какой-нибудь софт уже есть под него?

Транслятор ассемблера и несколько простых примеров на ассемблере.

>>1018329
Почему нельзя было сделать PUSH reg/POP reg? А вдобавок к ним еще операцию чтения со смещением чтобы сразу MOV [r0], r1; ADD 4 r0.
Только относительные джампы - тоже очень странное решение, даже таблицу виртуальных функций без геммороя не сделаешь.

Пилите квантовый процессор, епта.

>>1018338
>Я со своей рекламой стековых процессоров начал вызывать ненависть даже ко стеку?

Нет нет нет. Напротив, я стек очень люблю. Просто хитрая работа со стеком в другом проекте и есть часть "Know How", поэтому я стараюсь игнорировать эту тему и не привлекать к ней внимание, дабы ненароком не раскрыть секреты.

https://www.youtube.com/watch?v=1ZPLPD9yvnY

Какая цель всего этого? Сделать йобапроцессор и йобаПО?

>>1018310
Какая длина команды? Как иммидиаты задаются?

>>1018343
> Система команд может расширяться неограниченно
Нефиксированная длина команды (т.е., префиксы в том или ином виде) - это фуууу. Это необоснованные сложности при выборке и декодировании. Это было нормально в восьмидесятых, но не сейчас.

> TSS
Да.

> Есть, но только один регистр позволяет это - регистр R15
Т.е., вместо нормального вызова функций по указателю или оптимизации switch через табличку - пляски с сохранением R15, пляски с самостоятельной (как я понимаю), т.е., минимум 3 инструкции, считая сохранение адреса возврата (вручную!).

>>1018350
Ну как же так. Скрываешь самое интересное.

>>1018348
>Почему нельзя было сделать PUSH reg/POP reg?

Потому что планировал в будущем расширить систему команд автоинкрементом и автодекрементом, как у PDP-11.


> А вдобавок к ним еще операцию чтения со смещением чтобы сразу MOV [r0], r1; ADD 4 r0.

Это уже есть. И даже работает начиная с какой-то версии
http://everest.l4os.ru/0xd0_second_edition/

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

Изначально исходил из того, что весь код должен быть позиционно независим. Только позиционно независим.

Что касается таблицы виртуальных функций. Пока не появится соотвесттвущее расширение системы команд, придётся использовать ассемблерный макрос, который спрячет весь геморрой. Да, это будет не слишком эффективно в плане быстродействия, но увы.

>>1018360
>оптимизации switch через табличку
Свитч-то как раз лучше через смещение делать, там расстояния небольшие и известны заранее, поскольку компилируются в одном блоке.

>>1018364
Епт, сразу бы дал ссылку на сайт.

>>1018339
Гипервизоры имеешь ввиду? Вики говорит, что гипервизор представляет из себя микроядро.

>>1018356

Длина команды от 1 байта до пяти. Длина инструкции однозначно вычисляется по первым битам - все инструкции сгруппированы по их длиине.
Пространство системы команд начиная с 0xff не определено. Теоретически можно добавить инструкции, чья длина ограничена возможностями железа и здравым смыслом.

> Как иммидиаты задаются?
Три формы LOAD c 8, 16, 32 бита
В инструкциях с чтением/записью памяти со смещением, смещение это несколько бит в во следующих байтах инструкции.
Прибавить или удалить константу без использования промежуточного регистра нельзя.

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

>>1018366
> Свитч-то как раз лучше через смещение делать
Ну если jmp reg - это jmp ip+reg, то да. Но я не вижу на карте опкодов jmp reg. А значит, есть только вариант с return через жопу и абсолютной адресацией.

Уйдет ли это дальше студенческого проекта на fpga?

>>1018380
Нет, оно неюзабельно.

>>1018376
>Ну если jmp reg - это jmp ip+reg, то да. Но я не вижу на карте опкодов jmp reg
И правда. Я не посмотрел.

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

>>1018360
>Нефиксированная длина команды (т.е., префиксы в том или ином виде) - это фуууу. Это необоснованные сложности при выборке и декодировании.

Ну так я не только нарисовал табличку с инструкциями, но и реализовал это в Verliog. С иинструкциями вплоть до 5 байт особых проблем нет - пять байт никогда не могут занять три машинных слова, а два слова решаются довольно просто с точки зрения схематики.

>
>> TSS
>Да.
Я бы тоже отказался от этого решения. :)
Сообщение - вот лучший рычаг для переключения задач.

>Т.е., вместо нормального вызова функций по указателю или оптимизации switch через табличку - пляски с сохранением R15, пляски с самостоятельной (как я понимаю), т.е., минимум 3 инструкции, считая сохранение адреса возврата (вручную!).

Для всех этих вещей я использовал префикс - NOTCH. С его помощью на ходу относительные адреса транслируются в абсолютные. Этот префикс активно используется для всяких трюков, макроассмеблер во многих случаях использует его, при этом ассемблерный код выглядит более привычным для программиста.


А каков тут бамплимит? С такой скоростью тема быстро закончится.

Почитал немного о ваших этих хамелеонах.
>реализована на объектно-ориентированном языке программирования;
Я недоволен. Требовать функционального программирования! Тем более, где-то там завалялось формально верифицированное микроядро.

А разве все эти пересылки сообщений по своей сути не суть абстракция над семафорами и тд? Ведь тоже надо блокировать дабы сообщение не перекрыло друг друга или делать память отдельную но то медленно... ну сумбурно выразился

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

Эт почему?
И зачем что-то там явно вообще конвертировать?
Как раз в случае фиксированной точки, очень легко конвертировать, множитель и инкрементировать, и все.

Я в общем все еще не пони.

>>1018404
Ну попробуй написать. Тебе придется везде конверсии масштабов и декомпозиции вставлять. На 64 битах можно особо не париться, конечно. Но на 32, и тем более на 16, как во времена MMX, геммороя просто туча. Та самая матричная трансформация из простого умножения матрицы на вектор превращается в три - повернуть по базису, заданному нормалями, скейл в нужном масштабе, смещение в нужном масштабе. Для разных масштабов, соответственно, нужны разные матрицы. Самая засада в том, что точных алгоритмов для 1/х, квадратного корня, обратного корня, у тебя не будет. Под каждый масштаб нужно выбирать свою аппроксимацию и выдрачивать алгоритмы на нужную точность.

>>1018396
Самый главный вопрос - зачем все это? Чем вас существующие решения не устроили? И еще, какая у вашего проца ниша? Для микроконтроллеров аппаратный шедулер и виртуальная память вроде не особо нужны, а для более тяжелых задач проще готовое решение взять.

>>1018387
> Почему всюду пихают эту сраную плавающую запятую, почему не используют с фиксированной точностью?
В общем-то тебе тут уже ответили, но дополню. Для реализации фикседпоинта тебе не нужны специальные инструкции, ты просто берешь и пользуешься существующими инструкциями сложения-вычитания и умножения-деления (которых у ОПа нет, кстати), и тебе в общем-то норм. А вот "программно" с плавающей запятой работать ты охуеешь, будет слишком медленно.

>>1018376
>Ну если jmp reg - это jmp ip+reg, то да. Но я не вижу на карте опкодов jmp reg. А значит, есть только вариант с return через жопу и абсолютной адресацией.

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

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

>>1018429
Как говорят, - чтобы расти в шахматах нужно играть с более сильным противником. Также и программирование, если писать одни круды расти не будешь. Нужны сложные задачи.

>>1018429
Как говорят, - чтобы расти в шахматах нужно играть с более сильным противником. Также и программирование, если писать одни круды расти не будешь. Нужны сложные задачи.

>>1018403
> А разве все эти пересылки сообщений по своей сути не суть абстракция над семафорами и тд?
В некотором роде да, но тут стоит обратная задача - для совместимости с существующим кодом на основе сообщений реализовать объекты синхронизации.

> Ведь тоже надо блокировать дабы сообщение не перекрыло друг друга или делать память отдельную но то медленно..

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

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

>>1018433
Я тебе бы посоветовал взять дизасм движок какой-нибудь (capstone, например), какой-нибудь парсер PE и пройтись по секциям кода каждого исполняемого файла из C:\windows\system32. Кладешь результаты в базу, группируешь инструкции по типу, строишь гистограмму по частоте использования и видишь, чего "хотят" программы, думаешь, чего из этого у тебя нет, что имеет смысл делать несколькими инструкциями, а что вот прямо обязательно должно быть коротким и удобным. Для других архитектур аналогично.

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

>>1018440
Я не о том. Я про софтфлоат, т.е., эмуляцию FPU.

>>1018435
Чисто для развлечения, конечно, гораздо интереснее работать, особенно, если работу оплачивают.

>>1018429
>Самый главный вопрос - зачем все это?
По крайней мере это интересно.

>Чем вас существующие решения не устроили?
Много лет назад мне попало в руки Pistachio. Начал изучать, несколько раз на грабли наступил, а потом внезапно нашёл оригинальное решение по обработке сообщений. Отсюда всю пошло поехало. Короче, хобби такое.

> И еще, какая у вашего проца ниша?
Пока только микроконтроллер.

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

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

Господа, а микроконтроллеры/драйверы винды и линукса - можно начинать, если я являюсь веб-макакой мерзкой? И вообще, есть ли перспектива переката? Просто у C# индусов - есть варианты, а тут? Вопрос тупой, но интересны возможности переката за рубеж.

>>1018444
> А вот таймеры, которые так любят разработчики на микроконтроллерах, становятся лишней сущностью. Таймеры легко и непринуждённо заменяются таймаутами сообщений.
Приоритеты-то хоть будут? Возможность прервать обработку прерывания сообщения чем-то гораздо более необходимым в текущий момент?

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

>>1018445
Странные вопросы. Если ты можешь решить любую задачу, ты будешь ценным везде. Но сначала же нужно этот опыт получить. Глупо делить шкуру неубитого медведя.

>>1018447
> Приоритеты-то хоть будут?
Иерархия приоритетов древовидная. В корне планировщик, которому принадлежит 100% процессорного времени. Поскольку планировщика как-бы аппаратный, то подразумеваем что сам он не потребляет (ну почти) машинное время. Ветви дерева используют машинное время узла. Если все дочерние ветви блокированы, то время, неиспользованное узлом, передаётся следующему узлу. И по аналогии наверх. Если в какой-то момент все процессы блокированы, то устойство переходит в режим низкого энергопотребления до ближайшего таймаута какого либо сообщения или до прерывания сообщения от внешнего устройства.

> Возможность прервать обработку прерывания сообщения чем-то гораздо более необходимым в текущий момент
В оригинальном L4 Pistachio эта возможность есть. Поскольку прервыания в L4 транслируются в сообщения, то текущий менее приоритетны процесс блокируется, а ожидающий прерывания процесс с более высоким приоритетом разблокируется.

Сразу оговорюсь - в текущей версии устройства, реализованном в виде прошивки для платы Марсоход-2, ничего этого ещё не реализовано. Пока что работа с внешними портами организована через циклический опрос. Это не более чем учебное устройство. Если что и делать на нём сейчас (шутки ради), то только с помощью суперцикла.


?

>>1018455
>Ветви дерева используют машинное время узла. Если все дочерние ветви блокированы, то время, неиспользованное узлом, передаётся следующему узлу. И по аналогии наверх.

Чуть поправлюсь. Задача в узле дерева тоже потребляет машинное время. Дочерним ветвям время отдаётся только если узел заблокирован в ожидании приёма иди передачи сообщения, или если блокируется не выработав свой квант времени.

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

Для контроллеров это самое масло.

>>1018425
Я снова непони, а нельзя масштаб автоматически изменять?
Зачем это вручную делать?

>>1018440
Но Википедия говорит что флот в железе сложнее делать.

>>1018127
Со схемотехники.

>>1018131
И зачем это надо?

>>1018503
>а нельзя масштаб автоматически изменять?
Можно. Именно для этого и придумали числа с плавающей точкой.

Ключевое даже не микроядерность, а именно модульность.
Поэтому более старая BSD технически обходила linux — модульность там была чуть ли не с самого начала, в то время как в линухе это всё появилось относительно недавно.

>>1018570
щито?

Отдыхаете в шаббат значит.

Попалась книжка по разработке ОС. Книга правда закончена наполовину, но уже имеет 4000 звезд на гитхаб.

https://github.com/tuhdo/os01

>>1019011
> уже имеет 4000 звезд
Это называется "потом посмотрю". У меня примерно столько же закладок на хабре.

>>1019058
Может быть. С другой стороны, не так много проектов имеют столько звезд. Если потом посмотреть, достаточно кинуть в закладки, ленивый не станет ставить звезду.

И чё там?

>>1020516
Да ничё.

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

>>1024225

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

Всех поразило ООП головного мозга. Никто не может дать четкое определение ООП. Потому что его не существует. Если разобраться, под ООП нет никакого теоретического фундамента. Это просто выдумка, не подкрепленная никакой базой. Почему нельзя достичь ООП? Потому что нельзя достичь того, что нельзя четко определить. Была бы четкая спецификация, тогда можно было бы оценивать код ООП или нет. Спецификации такой нет и не будет. ООП стоит на мифах.

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

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

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

Как-то так все это вижу.

>>1024271
Айти создано, чтобы человекам проще жилось.
Хоть уровней абстракции много, но разработка становится проще и быстрее.
2 уровня абстракции - это какие?
1 уровень - ассемблер
2 уровень - любой компилируемый язык (т.е С или С++)?
Если так, то жс, джава, шарп, пеашпи, питоно находятся на третьем уровне абстракций

>>1024271
>включая уровни процессора
Собираешься копаться в микрокоде?
Зачем его переписывать?
Есть RISC ядро, а есть CISC инструкции, которые транслируются в RISC инструкции. Что ты хочешь там переписать?
За тебя все уже давно написали, просто скачай фреймворк и начинай работать

>>1024271
> Нынешняя аппаратная база довольна неплоха. Хорошо испытана. Вполне удобна и жизнеспособна
Наивный чукотский юноша. DRAM сломана, флеш сломан, DMA сломан, USB сломан дважды (на логическом и механическом уровнях), с SMP тоже не все гладко на большинстве платформ.

>>1024271
>Объем кода уменьшится. Сложность уменьшится.
С чего вдруг он уменьшится?
Или ты хочешь начать делать процессоры, которые будут напрямую исполнять си?
Такое будет стоить очень дорого, к сожалению.
Почитай таненбаума, там в первых главах все хорошо про это написано

>>1024287
>Айти создано, чтобы человекам проще жилось.
Я писал именно об этом. Айти вместо решения проблем, само превратилось в проблему.

>>1024289
>>1024290
>>1024292

Сейчас если не ошибаюсь, 5 программных уровней. 2-3 из них лишние. Они создают оверхед. Нужны только верхний уровень, и нижний уровень над аппаратурой. Верхний уровень сделать универсальным. Все скриптовые языки выбросить. Базы данных создающие файловую систему внутри другой файловой системы, которая внутри третьей файловой системы, - выбросить.

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

Сетевые протоколы все выбросить. Текстовые протоколы запретить. 7 слоев не нужны. Каждый слой добавляет свой оверхед и по объему данных и по скорости. Верхние слои протоколов сделать более компактными и универсальными. ХТТП это оскорбление программистов. В 21 веке использовать настолько нежизнеспособный протокол это преступление.

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

>>1024329
И как тогда Майкрософт будет своё говно продавать?

>>1024292
>С чего вдруг он уменьшится?
Легаси скопилось очень много. И в процессорном уровне, и в вышележащих. Уровень приложений уже сам состоит из нескольких уровней. Если все это выпилить, то уже производительность увеличится, и объем кода уменьшится.

>>1024332
И что?
Будешь писать браузер на ассемблере?
Сайты тоже на ассемблере?
Легаси скопилось уже на высоких уровнях и ОС, больше его нигде нет.

>>1024329
>Если нижний программный слой сделать универсальным
Нельзя сделать.
>Айти вместо решения проблем, само превратилось в проблему.
Это тебе на дваче так сказали. В действительности все спокойно делают сайты для себя, утилиты, чтобы облегчить себе жизнь.
А вот если все это писать на ассемблере или на си, то можно действительно превратить всю разработку в инфернальный пиздец с утечками памяти и прочими низкоуровневыми прелестями.
>5 программных уровней
Ну и какие же это уровни?

>>1024334
Нет. Сократить прослойку между аппаратной частью и высокоуровневыми языками. Легаси есть везде, достаточно отрыть мануалы интела чтобы понять это. Половина функционала уже не используется, либо стоит костылем под другим функционалом. Более высокоуровневые апи опустить на более низкий уровень, то есть уплотнить.

>>1024338
Можно. Все что можно реализовать аппаратно, можно реализовать и программно.

Сайтики лежать на множестве уровней абстракций. Сплошной оверхед. Сетевые протоколы устарели. Из-за всего этого невозможно открыть тяжелый сайт в браузере, даже на мощных машинах подтормаживает. Си не нужен. Есть Раст, Хаскелл, Окамл, Го. Процедурное программирование не нужно. ООП не нужно.

2 уровня абстракций на процессоре, уровень ассемблера, уровень ОС, прикладной уровень (в котором появляются свои уровни) - вот и 5 уровней. Если учитывать виртуальные машины, то 6 уровней.

Получается компилятор в компиляторе в компиляторе, ос в ос в ос, файловая система в файловой системе в файловой системе, сетевой протокол в сетевом протоколе в сетевом протоколе. Рекурсия короче. Это все не нужно. Слишком много лишних слоев.

>>1024358
>Сократить прослойку между аппаратной частью и высокоуровневыми языками.
Это повысит стоимость процессоров в сотни и тысячи раз.
>Сайтики лежать на множестве уровней абстракций.
В целом так и есть, но ниже прикладного уровня их не опустишь.
>Сетевые протоколы устарели
С чего вдруг? Что существенно нового произошло за последние 20-30, что нужно срочно менять сетевые протоколы?

Начать нужно с верхнего уровня. Разработать протоколы передачи. Удостовериться что они хорошо решают задачи. Разработать концепции хранения данных. Снова удостовериться в их удобстве. Разработать концепции удобных высокоуровневых языков. После построения удобного для использования верхнего уровня. Можно постепенно переработать все нижние уровни.

>>1024366
Процессоры оставить как есть. Сократить, упростить, улучшить срединные апи. Между машиной и высокоуровневыми абстракциями.

>>1024366
>С чего вдруг? Что существенно нового произошло за последние 20-30, что нужно срочно менять сетевые протоколы?
Множественная перепаковка с добавлением лишней информации. Слишком много уровней. Текстовые протоколы не решают задач. Сократить до 3-4 слоев протоколов. Важно чтобы прикладные протоколы стали соответствовать современным задачам. Веб сейчас борется с проблемами передачи данных. Не было бы их, сайтики да и любые сложные веб-приложения, создавались бы легко. Не было бы такого потребления ресурсов. Основная работа в сетях, это постоянная перепаковка и увеличение данных. От этого веб делать сложно и муторно.

>>1024370
>Сократить, упростить, улучшить срединные апи. Между машиной и высокоуровневыми абстракциями.
Я так понимаю это CISC инструкции? Выше идут С/С++, на которых уже написаны различные VM. Что конкретно ты хочешь упрощать?

И опять начали думать о чем-то вроде FORTH, forth-процессоров и контакатенативных языков программирования вообще. Поздравляю.

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

>>1024404
Объединить уровни микроархитектуры и набора команд. Лишнее все выбросить. Нет необходимости надстраивать низкоуровневое апи на другое низкоуровневое апи, это оверинжиниринг.

>>1024329
> 5 программных уровней
Ниразбирающийся школьник детектед.

> Все скриптовые языки выбросить
Хитрый план, чтобы убить айти нахуй?

> Базы данных
Проиграно.

> Сетевые протоколы все выбросить
Разбудил кошку.

> 7 слоев не нужны
Их нет. Сетевая модель OSI - абстрактная хуйня в вакууме, к реальности отношения не имеет. Если начать формализовывать, окажется, что слоев много больше.

> ХТТП это оскорбление программистов
Ты просто никогда не пытался отлаживать софт, использующий бинарные протоколы. А HTTP используется очень часто, и если избавиться от абстракций, отлаживать придется каждое использующее его приложение.

>>1024358
> Легаси есть везде
Конечно. Никому не нужна новая машина с красивой реализацией, если тебе придется выкладывать за нее деньги снова и снова. Только ради того, чтобы лично ты был счастлив из-за отсутствия легаси.

>>1024424
> Объединить уровни микроархитектуры и набора команд
Наслаждайся греющимся медленным говном (в разы более медленным, если мы подразумеваем x86) с кучей багов в реализации (в среднем несколько в год), которые никак не исправить - только выкидывать камень и покупать новый.

>>1024329
>ХТТП это оскорбление программистов. В 21 веке использовать настолько нежизнеспособный протокол это преступление.
Внезапно соглашусь.

>Базы данных создающие файловую систему внутри другой файловой системы, которая внутри третьей файловой системы, - выбросить.
Есть проблема такая.
Но это скорее проблема плохого дизайн, с одной тсороны.
И концептуальная сдругой.

Концептуальная проблема в том, что нельзя сделать универсальную базу данных.
У разных задач разные потребности.

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

>>1024329
>7 слоев не нужны. Каждый слой добавляет свой оверхед и по объему данных и по скорости.
Это абстракции же.
Они нужны.
Без них нет модульности.
Там же есть чисто аппаратные слои, а есть уже программные.

С другой стороны, кто-то где-то использует IP без TCP\UDP?
А ARP без IP?

Думаю тут есть некий простор для редизайна.

Но экономически\политически это практически невозможно.

>>1024358
>Сайтики лежать на множестве уровней абстракций. Сплошной оверхед.

То, во что сейчас превратился веб, и браузеры - это какой-то ПОЗОР.

Кому-то в голову пришла гениальная идея, писать приложения на языке верстки документов.

А потом под эту тему навыпускали новых апи и превратили бравзеры в аналог флешплеера.

И нужно заметить, флешплерр справлялся с задай гораздо лучше, он под это создавался.

А вот HTML\js\css\9999фреймворков - блядь, пидоры.

Каким же надо быть ебанутым чтобы обсуждать эту помойку

>>1024570
>Конечно. Никому не нужна новая машина с красивой реализацией, если тебе придется выкладывать за нее деньги снова и снова. Только ради того, чтобы лично ты был счастлив из-за отсутствия легаси.
Как насчет новая машина с старой галимой реализацией и заюбагованным софтом за которую тебе приходится выкладывать деньги снова и снова.
I N T E L
N
T
E
L

А андроид смартфончика не хочешь?
Что, через полгода вздулась батарея и разорвало склеенный корпус?
Как насчет еще одного смартфончика?
Рекламу показывает? Вирус украл деньги со счета?
Камера закрывается?
Выключился и не включается?
Нет времени объяснять, срочно покупай новый свежий смартфон, который делает все то-же самое.

>>1024626
> Ты что, ебанутый.
> Это HTTP то просто отлаживать?
Да, HTTP очень просто отлаживать. Любой монитор трафика показывает весь обмен, любой TCP-клиент на любом языке программирования позволяет отправить запрос тремя строчками кода даже без либ.

> URI КОДИРОВКА Windows1251
Ну так сходи настрой сервер, чтобы была UTF-8, как у людей. Это не проблема протокола.

> WebDav
Так я с этим и не спорю. Использовать HTTP в качестве транспорта для более высокого уровня нужно более обдуманно. Алсо, для файлов существует текстовый же FTP, он норм.

>>1024628
> I N T E L
Ты что-то путаешь. Я выкладываю деньги за повышение быстродействия примерно раз в пять-десять лет. Могу не выкладывать, легаси как раз и обеспечивает мне как работоспособность привычного софта на новом железе, так и наоборот работоспособность нового софта на старом железе. Ну если, конечно, некоторые компании на букву M не принимают гениальное решение эту самую десятилетиями поддерживаемую обратную совместимость сломать. А потом недоумевают, чоэта люди остаются сидеть на XP и денег не плотют.

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

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

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

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

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

Невозможно создать ничего хорошего постоянно оглядываясь назад и следуя за толпой.

>>1024623
>я предлагаю упразднять С
А что упрощать в сишке?
Она и так очень простая.
А вот насчет С++ соглашусь.

>>1024358
>Го
>Процедурное программирование не нужно
>Окамл
>ООП не нужно
Го дебил во всей красе, ничего у него не нужно.

>>1024338
>можно действительно превратить всю разработку в инфернальный пиздец с утечками памяти и прочими низкоуровневыми прелестями
Смотрите, скриптодевочка пугается байтиков. 80-е давно прошли, с современными тулзами, сишка простой в работе и безопасный язык. Хотя смузи-кодерки будут продолжать попытки запихнуть nodejs в микроконтроллер.

>>1024618
Предложи что-то лучше файловой концепции.
>>1024791
>язык со слабой типизацией
>простой в работе и безопасный

>>1024767
>А что упрощать в сишке?
>Она и так очень простая.
упразднять
не
упрощать

>>1024826
>Предложи что-то лучше файловой концепции.
Для чего именно предложить?
Какую задачу то решаем?

>>1018387
>Почему всюду пихают эту сраную плавающую запятую, почему не используют с фиксированной точностью?

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

Ну и как бы спорить какой язык лучше, это в наше время потеряло смысл. Для системного программирования пойдёт любой компилятор, умеющий генерировать объектные файлы. Язык значения не имеет. Если компилятор не умееет генерировать обхектные файлы, то он не подходит для системного программирования.

А микроядро даёт вам возможность компоновать систему из модулей. Это не единственная возможность микроядра и не каждого микроядра, но это одна из самых вкусных возможностей.

>>1017406 (OP)
Что за язык на пикче?

>>1025380

Язык описания аппаратуры - Верилог (Verilog).
Клёвая штука. Но программисту будет непривычная.

>>1025383
Что этой штукой можно делать? Кроме как засунуть себе в анус.

>>1025386
'Ну например вот тут посмотри - https://marsohod.org/projects

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

>>1025388
Но ведь и из C можно синтезировать?

>>1025409
Можно. Но где ты такую ПЛИС найдёшь? В этом случае количество использованных логических элементов возрастает на порядки. Тогда тебе придётся покупать не любительскую девборду, а потратить несколько (возможно несколько десятков) тысяч долларов на старшую модель девборды. Причём, делая то же самое на HDL, ты поместишь свой проект в любительскую девборду.

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

>>1025073
Для тех, что решает файловая концепция в том числе. Да и вообще предложи лучше.

>>1017628
На самом деле достаточно, смотрел вчера выборку по HH. Если, конечно, мы не с PHP сравниваем.

>>1025502
Это беспредметный разговор.
Я говорил о файловой системе, ты начал о какой-то файловой концепции.
Я тебе говорю - давай конкретные задачи, ты опять предлагаешь неопределенный беспредметный концепт "Для тех, что решает файловая концепция".
Хорош пургу нести.

Давай четкое определение "файловой концепции" и перечь проблем ею решаемых.
Тогда будет о чем говорить вообще.

>>1025594
>файловая система - странная концепция

>>1025594
Чой-та вы не то обсуждаете.
Файл вполне себе нормальная абстракция, которая покрываешь даже устройства.

C:> copy mytext.txt prn:
$ cp mylog.txt /dev/ttyS0

Что не так с файлами?
Древовидная структура весьма удобна.

>>1025597
> copy mytext.txt prn:
> Файл вполне себе нормальная абстракция
Это нормально работало, пока принтер был печатной машинкой, которая выбивала указанный символ и еще парсила полтора спецсимвола. А сейчас у моего принтера два лотка с бумагой и стопицот режимов. Покажи-ка мне, как выбрать нужный лоток, 4 отпечатка на одном A4, 40% экономию тонера и автоматическую печать на двух сторонах, и все это с помощью вот этой твоей "нормальной абсракции". Внезапно окажется, что нужен не один файл, а целая папка. Внезапно окажется, что нужно запоминать какой-нибудь синтаксис, разный для разных устройств. Внезапно окажется, что сигнализировать о заканчивающейся бумаге принтер программе не сможет.
Заодно расскажи, вот у меня есть mp3, в mp3 музончик и метаданные, а еще в метаданных обложка в жипеге, а в том жипеге картиночка, превьюшка и метаданные. Но ведь mp3 - это жи файл, а ты говоришь, что файлы весьма удобны? Так как мне вытащить GPS-координаты из того жипега?

>>1025597
>Файл вполне себе нормальная абстракция, которая покрываешь даже устройства.
Есть мнение, что обмазывать ей даже устройства небо и Аллаха - не стоит.

>Древовидная структура весьма удобна
Удобна.
Но часто недостаточна и оверюзанна(одновременно).

/home/development/cpp/home_projects/projects_in_work/coolapp/src/main_module/

/home/projects/home/coolapp/

/home/docs/projects/coolapp/bestdock.docx

Или c:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive\ru-RU\

И попробуй в этом всем что-то найди.

И это далеко не худшие примеры.

Далеко не все данные хорошо хранить в древовидной БД.

Вот всякие конфиги - хорошо, но их зачем-то наоборот в фалы пихают в виде списков.

>>1025610
>Покажи-ка мне, как выбрать нужный лоток, 4 отпечатка на одном A4, 40% экономию тонера и автоматическую печать на двух сторонах, и все это с помощью вот этой твоей "нормальной абсракции".


Для это в стандарте POSIX есть системный вызов IOCTL с помощью которого можно управлять устройство. И, внезапно, в качестве одного из параметров используется дескриптор открытого устройства.

> Заодно расскажи, вот у меня есть mp3, в mp3 музончик и метаданные, а еще в метаданных обложка в жипеге, а в том жипеге картиночка, превьюшка и метаданные. Но ведь mp3 - это жи файл, а ты говоришь, что файлы весьма удобны?

А чем тебе не удобно что всё одном месте хранится? Вот то, что ты написал, это и есть удобство. А картиночку из внедрённого jpeg тебе покажет твоя любимая Desktop Environment

> Так как мне вытащить GPS-координаты из того жипега?

Подозреваю что нечто вроде клика правой клавишей мыши на иконке, Меню "Свойства" подменю "Подробно".

Или тебе программно нужно? Ну так ищи соответствующую либу, линкуй к своему проекту и вуаля - то, что тебе нужно.

>>1025614
>Далеко не все данные хорошо хранить в древовидной БД.

Я знал что будет такой аргумент. А что ты предлаешь взамен? Уж не вот это ли - https://en.wikipedia.org/wiki/WinFS ?

>>1025666
> Для это в стандарте POSIX есть системный вызов IOCTL с помощью которого можно управлять устройство.
Очевидно, что если у нас есть вызовы, то мы можем сделать и вызов, с помощью которого можно печатать. И тогда наличие PRN: совершенно избыточно, и даже вредно.

> Подозреваю что нечто вроде клика правой клавишей мыши
Ты не понял. Я говорю о том, что фс вредна, потому что, как бы ты ни упирался, но каждый файловый формат рано или поздно рекурсивно скатывается до собственной фс внутри него. Поэтому нужно осознать, отбросить древние привычки и взять БД сразу, а фс выкинуть нахуй. И тогда я, наконец, смогу узнать GPS-координаты из обложки альбома внутри аудиозаписи. И мне не нужно будет городить парсер для каждого формата лишь потому, что внезапно обложка лежит не в .mp3, а в .ogg.

>>1025668
Мойкрософт знает толк в технологиях.
Ms Bob только чего стоит.
https://www.youtube.com/watch?v=DtaduB1qRjk
Увы, многое похоронил менеджмент, а многое пользователи уточки.

Идея у МС в целом неплохая, но полностью отказываться от каталогизации не стоит ящитаю.

Подробно описывать свои идеи ящитаю бессмысленно в формате анонимногокартинкофорума.

>>1025678
>И тогда наличие PRN: совершенно избыточно, и даже вредно.

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

И тебе нечего на это возразить. :)

> Поэтому нужно осознать, отбросить древние привычки и взять БД сразу, а фс выкинуть нахуй.

И вот ты обращаешься к файл не используя Full Path, а используя некий запрос, наподобие SQL. И вот, внимание, запрос выдал (условно) три файла. Допустим, ты открываешь документ - что делать сразу с тремя файлами? Но это ещё половина беды - можно представить ситуацию с тремя открытыми документами. А сохранять в какой из трёх будешь? Создавать третью четвёртую версию файла? А не боишься при этом погрязнуть в версиях, впоследствии тратя большую часть времени на формирование всёё более хитрых запросов?
При этом документ или фото это половина беды, их действительно можно открыть сразу несколько. А что если это какой-то скрипт, который работает без участия пользователя? Как ему быть когда под один запрос попадает несколько файлов? Какой из них открывать? Пользователя рядом нет, подсказать некому.

Вот когда ответишь на эти вопросы, тогда можно всерьёз обсуждать ОС с БД вместо файловой системы.

>>1025750
> обсуждать ОС с БД вместо файловой системы
Файловая система и есть БД.

>С помощью абстракции файловой системы можно безболезненно добавлять новы устройства и даже совершенно новые, которых доселе не было, при этом не меняя саму операционную систему.
Что ты несешь, болезный.

>Всё, что понадобится в таком случае это драйвер
Всего-то.

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

>>1025750
> С помощью абстракции файловой системы можно безболезненно добавлять новы устройства
У меня от тебя /dev/enp2s0. Либо у нас обычная нумерация устройств, начиная с первого воткнутого, и тогда вебка оказывается каждый раз названа по-новому, либо ты их обзываешь в зависимости от физического расположения, и... юзеру похуй на твои причуды, он хочет, чтобы руль продолжал рулить в гоночках вне зависимости от того, воткнут ли он в USB-порт ноута, или в хаб, воткнутый в хаб, воткнутый в монитор, воткнутый в USB-порт ноута.

> совершенно новые, которых доселе не было
Нахуй мне в ОС устройство "спиннер", если у меня нет ни софта, ни дров, чтобы его крутить? А если у меня есть софт и дрова, у меня уже есть либа с API, и никакие ioctl мне не нужны.

> что делать сразу с тремя файлами
Выберу нужный, используя метаданные. Например, свежеотредактированный. Если это какой-то не пользовательский файл (например, какие-то входные данные от какой-то программы), то у него, скорее всего, есть GUID, которым и пользуется программа, которой он принадлежит.

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

> скрипт
Зависит от того, что делает скрипт. Он обработает либо все, либо самый свежий, либо скрипт содержит ошибку. Встречный вопрос: что сделает скрипт, если указанный ему файл - на самом деле имя директории?

>>1025745

Как теперь развидеть ЭТО?!!!
Сорок минут жизни коту под хвост.
Спасибо, Майкрософт, что ты похоронила Боба, но нет тебе прощения, за то что создала это...

>>1025753
И придётся тебя ещё с собой таскать DLL для динамической линковки или .so/.lib для статичкской. Только потому, что тебе не нравится что устройства отображаются в /dev/

>>1025756
>Встречный вопрос: что сделает скрипт, если указанный ему файл - на самом деле имя директории?

Не сможет его открыть и завершится с ошибкой.
И это нормально.

> Я всегда могу удалить самые старые, могу откатиться на нужный.

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

> GUID, которым и пользуется программа

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


Кстати, такую файловую систему, о которой ты толкуешь, несложно реализовать поверх NTFS. Внутри неё всё для этого есть.

>>1025769
>А пользователи? Они начнут удалять старые версии только когда закончится место на диске. а случится это при таком подходе довольно быстро.
В windows такой подход включен по умолчанию.
Без всяких экзотических концепций, с обычной ФС.
И ничего, пользователи не жалуются.

>>1025769
> Они начнут удалять старые версии только когда закончится место на диске. И в винде, и в макос давно уже старые версии документов сохраняются. И ос преспокойно рулит всем этим самостоятельно, но пользователь, если он разбирается, может этот процесс контролировать.

> поверх NTFS
Там выше полтреда понаписано о вреде ненужных оберток.

Алсо, я скажу больше: о разделении на оперативную и долговременную память ни пользователю, ни прикладному софту в идеале знать не нужно. Как и "сохранять" документы в принципе нахуй не нужно, пока не потребуется их куда-либо передать. Для примера (уже работающего, причем годами) правильного поведения можно посмотреть на hot exit в Sublime Text, где можно создать документ, написать что-нибудь, закрыть редактор, запустить его в другой ОС (разумеется, профиль общий), и в документе даже курсор на том же месте останется. Переключиться на другой воркспейс, что-то сделать, вернуться обратно, а курсор будет по прежнему там, где его оставили (ну и undo, история поиска и т. п., конечно же, тоже сохраняются).

>>1025774
>В windows такой подход включен по умолчанию.
Корзина, что-ли? Я не уверен что это не сделано надстройкой сверху.

Что-то мне подсказывает что https://msdn.microsoft.com/en-us/library/windows/desktop/aa363915(v=vs.85).aspx не помещает файл в корзину, а таки удаляет его. Или ты что-то другое имеешь в виду?

>>1025778
Погугли macOS time machine.

>>1025773
>Ты поехавший и не лечишься.

Сынок, ты язык-то свой попридержи, малыш.

> Почему обязательно таскать длл?
Или DLL и статическую либу.
Иначе у тебя не будет способа обратиться к драйверу, если это нестандартное устройство.

>>1025779
>macOS time machine.
Надстройка над ОС. К ядру никакого отношения не имеет. С этим ты согласишься.
А вот то, что эта хрень сидит в памяти и засирает диск, тут ты, конечно, со мной не согласишься.

>>1025777

Дмитрий Завалишин? Собственной персоной в треде?

>>1025778
>Корзина, что-ли? Я не уверен что это не сделано надстройкой сверху.
Да какая в жопу разница в данном конкретном обсуждении чем оно там сделано.

Главное сделано, и пользователям нравится.
И это вообще логичный и правильный подход.

>>1025780
>Сынок, ты язык-то свой попридержи, малыш.
Ты там упоротый что ли?

>>1025784
Как это какая разница? Это как раз таки большая разница. Отказаться в от файловой системы в пользу базы данных, или городить надстройку над уже существующей файловой системой.

Кстати, чем GUID в таком случае лучше имени файла?

>>1025788
>Как это какая разница?
Речь шла о концепции сохранения удаленных файлов.
А не о какой-то конкретной технологии.
То что ты пишешь, никак несвязанно с постами на которые ты отвечаешь, и с твоими же предыдущими постами.

>Кстати, чем GUID в таком случае лучше имени файла?
Ты меня с кем-то путаешь вообще.

>>1025782
> Надстройка над ОС
Ну так там и фс традиционная, а не БД.

> засирает диск
Один терабайт стоит полста баксов. С размерами документов порядка 1 МБ можно засирать винт очень долго.

>>1025783
Кто такой? Чем знаменит?

>>1025788
> Кстати, чем GUID в таком случае лучше имени файла?
GUID - способ обратиться к конкретной, уникальной сущности (практически primary key). Вместо GUID может быть SHA-2 какой-нибудь. Или нет. Например, у моей программы есть логотип. Мне абсолютно похуй, где он лежит, я хочу один конкретный (мой) логотип. Что сделает система хранения ресурсов в ответ на запрос по GUID, мне в общем-то похуй: прочитает ли с винта, найдет ли в бэкапе, сольет с компа соседа или официального сайта программы - у меня есть GUID, я хочу картинку. Но в большинстве случаев я хочу, например, фоточку, которую я сделал в августе прошлого года. Мне опять же похуй, где она лежит, лишь бы ОС мне выдала что-то подобное, а я уж сам решу, которая из них мне нужна конкретно.

>>1025783
> Дмитрий Завалишин
Погуглил. Ой бляяя. Нет, я из другой секты.

>>1025793
>Один терабайт стоит полста баксов. С размерами документов порядка 1 МБ можно засирать винт очень долго.

Не знаю. Я люблю порядок. Ну и файлы разные бывают. Нередко встречаются сгенерированные docx или xlsx на 300 Мб.

Ладно. Тебе почти удалось меня убедить. Осталось ещё несколько вопросов и вот один из них - кто напишет эту файловую систему? Куда её приткнуть я найду, но кто реализовывать будет? Или ты описываешь то, чего бы хотелось тебе получить от файловой системы, но реализовывает её пусть кто-то другой?

>>1025798
> кто напишет эту файловую систему
У Microsoft уже было несколько попыток, но все они плохо сочетаются с привычками пользователей (даже поиском-то в винде далеко не каждый пользуется) на самом деле, даже итт разговор про ФС и БД начал не я, и хотя я понимаю, что в этом будущее, вряд ли перекатился бы на такую среду в числе первых. Возможно, поможет более широкое распространение Cortana/Siri/КогоТамЗабыл. Возможно, распространение начнется со смартфонов - там и так "настоящая" фс достаточно скрыта от простых глаз, и нужно сделать всего лишь шаг.

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

Хочу реализовать свою библиотеку потоков с диспетчером, атомарными операциями и шлюхами под STM32. Что почитать об этом?

>>1025799
>А что до меня, так, конечно же, я такой проект в одиночку не осилю ни реализовать, ни продвинуть.

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

Приблизительно так появился Bluetooth.

>>1025879

Не, неправильный подход. Нужно захотеть реализовать ПОСЛЕ того как почитаешь об этом. Тогда шанс есть. Обычно после прочтения приходит понимание что лучше взять готовое.

Небольшой бамп треду.

; --- Функция вывода строки
; Вход: R1 - адрес строки
; Выход: R0 - количество переданных символов

function _puts
mov R12, R15 ; Сохранение адреса возврата в R12
mov r0, r1 ; Копирование указателя на строку
load_word:
mov r2, (r0) ; Загрузка машинного слова (4-символа)
load r4, 4 ; Количество байт в машинном слове
check_byte:
rol r2, 8 ; Циклический сдвиг на 8 бит влево
load r3, 0xff ; Загрузка восьмибитной константы
and r3, r2 ; Проверка на конец строки
je done ; Вывод строки закончен
call _putchar ; Вызов подпрограммы вывода символа
inc r0, 1 ; Инкремент указателя
dec r4, 1 ; Декремент счётчика
jne check_byte ; Следующий символ
;debug
jmp load_word ; Повтор операции
done:
clc ; Сброс переноса
subc r0, r1 ; Подсчёт количества выведенных символов
mov R15, R12 ; Восстановление адреса возврата из R12
return ; Возврат из функции
end

; --- Функция вывод символа
; Вход: R3 - выводимый символ
; Выход: R3 - выводимый символ
function _putchar
load R6, 0xfffefff0 ; Адрес порта статуса UART
do_poll:
mov R5, (R6) ; Чтение статуса устройства
rcr R5, 1 ; Вытесняем бит BUSY в перенос
jc do_poll ; Опрос устройства в цикле
inc R6, 4 ; Указатель на регистр передачи данных
mov (R6), R3 ; Вывод байта
dec R6, 4 ; Указатель на регистр передачи данных
wait:
mov R5, (R6) ; Чтение статуса устройства
rcr R5, 1 ; Вытесняем бит BUSY в перенос
jc wait ; Опрос устройства в цикле
return ; Возврат из функции
end

; --- Функция возвращает состояние были ли нажата клавиша в терминале
; Выход: R0 - статус устройства (RCV_RDY & 0x02)
function _uart_status
load R6, 0xfffefff0 ; Адрес порта статуса UART
mov R0, (R6) ; Чтение статуса устройства
return
end

; --- Функция ожидания ожидания символа с терминала
; блокируется в цикле до принятия данных
; Выход: R0 - принятый символ
function _getchar
load R6, 0xfffefff0 ; Адрес порта статуса UART
do_poll:
mov R0, (R6) ; Чтение статуса устройства
rcr R0, 2 ; Бит RCV_RDY в перенос
jnc do_poll ; Опрос устройства в цикле
inc R6, 4 ; Указатель на регистр чтения данных
mov R0, (R6) ; Чтение
return ; Возврат из функции
end

; --- Функция печати шестнадцатеричного числа
; Вход: R0 - число для печати в шестнадцатеричном виде
function _print_hex
mov R12, R15 ; Сохранение адреса возврата в R12
load R3, 0x20
call _putchar
load R7, 0x9
fullnum:
dec R7
je finish
load r4, 0x9
load R1, 0xf
rol r0, 4
and r1, r0
cmp r4, r1
jc alphachar
load r3, 0x30
addc r3, r1
call _putchar
jmp fullnum
alphachar:
clc
load r3, 0x37 ; 'A' - 0xa
addc r3, r1
call _putchar
jmp fullnum
finish:
load R3, 0x20
call _putchar
mov R15, R12 ; Восстановление адреса возврата из R12
return
end

; --- Функция перевода строки
function _newline
mov R12, R15 ; Сохранение адреса возврата в R12
load R3, 0x0d
call _putchar
load R3, 0x0a
call _putchar
mov R15, R12 ; Восстановление адреса возврата из R12
return
end

>>1026476
А теперь то же самое, но с какой-нибудь конвенцией вызова. А то у тебя аргументы и возвращаемые значения каждый раз в новом регистре. Это допустимо для внутренних функций (которые генерит компилятор из твоего кода), но не для библиотечных.

Как так получилось что стандартом стала именно существующая сложная организация памяти? Почему не единое адресное пространство? В этом направлении вообще ведутся разработки? Ибо слишком сложно всё современное выглядит, будто костыли. Все эти MMU, вот это всё.

>>1026521
> Почему не единое адресное пространство
Потому что тогда написанные на ассемблере приложения смогут поднасрать другим. Чтобы они не смогли поднасрать другим, тебе придется либо запретить нативные приложения (т.е., писать на managed языке, который будет сам генерить машинный код, проверять указатели, тормозить), либо городить какие-нибудь сегментные регистры (спасибо, в 16-битном x86-коде накушались), в которые нельзя записать "чужой" сегмент из юзермода. Виртуальное адресное пространство гораздо проще для понимания, проще писать код, проще отлаживать.

> Ибо слишком сложно всё современное выглядит
Все там просто выглядит, пока не доходит до синхронизации кэшей, TLB и прочих предвыборок.

>>1026516

А конвенция вызова очень простая.
На выходе R0 это всегда значение функции.
Регистры R1-R7 могут использоваться как аргументы функций.
Вызываемая функция должна позаботиться чтобы регистры R8-R15 не изменились после выхода из функции.

В случае объектно-ориентированного кода при вызове функции в R0 указатель this.

Вот такая вот конвенция.

>>1027642
Ах да, вышеприведённый код не соответсвует конвнции. Функция вывода строки портит регистр R12.

>>1026521
Присоединяюсь к вопросу.
>>1026605
>Потому что тогда написанные на ассемблере приложения смогут поднасрать другим.
Это понятно. Понятно также почему тут помогает MMU.
Но почему для этого может не хватать простого MPU как в Cortex-M3? Если требуется, адреса (например в командах перехода) при этом можно пересчитывать при загрузке кода.

>>1026605
> либо запретить нативные приложения (т.е., писать на managed языке, который будет сам генерить машинный код, проверять указатели, тормозить)
Почему еще никто так не делает?
Одни профиты.
Да и есть же всякие технологии виртуализации. Ептв.


>Все там просто выглядит
Я не оче в курсе, но насколько я слышал, конвертация виртуального адреса в реальный происходит с помощью кода в ядре ОС.
О почему бы не делать это аппаратно?

>пока не доходит до синхронизации кэшей, TLB и прочих предвыборок.
Ага.

>>1030363
>Но почему для этого может не хватать простого MPU как в Cortex-M3?

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


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

Вот для этого и нужен MMU.

>>1030386
>Я не оче в курсе, но насколько я слышал, конвертация виртуального адреса в реальный происходит с помощью кода в ядре ОС.
>О почему бы не делать это аппаратно?

Это аппаратно и делается. Операционная система лишь управляет этим процессом.

>>1030400
>>1030399
Так, окей.
А раз оно так секурно, каким образом постоянно приложения ебут друг друга получая доступ к этой блядь защищенной памяти?

Ну то есть я не пони, если честно.

Каков конкретный юзеркейс то?


В конце концов, быть может секурность можно и по другому как-то реализовывать.

Что мешает делать блоки памяти без виртуальной адресации?

>>1030420
Приложения изолированы друг от друга адресными пространствами.
Например, виртуальный адрес 0x80000 (число взято на шару) может использоваться всеми программами (процессами) одновременно, операционная система каждому процессу в этот виртуальный адрес отобразит разные физические страницы. Чтобы приложения пересеклись в памяти, это невозможно. Наоборот, используется так называемая "разделяемая память" (shared memory), чтобы приложения могли использовать общую память. Но shared memory это достаточно сложно и держу пари что мало кто из прогаммистов ей пользовался или даже знает о её существовании :)

> Что мешает делать блоки памяти без виртуальной адресации?

Совместимость. Спрятать вот эту вот фргаменттацию от программиста можно с помощью managed (как это по-русски?) языков, типа Java или C#, которые прячут от программиста физическую реализацию памяти достаточно далеко. В случае же хотя бы простого Си, когда используются простые указатели, при интенсивном использовании malloc/free фрагментация наступит довольно быстро. При этом любая традиционная программа, написанная без учёта фрагментации памяти, довольны быстро ругнётся ошибкой "Out of memory", несмотря на то,что общий объём всех неиспользованных дырок в памяти будет достаточен.

>>1030386
Это делается аппаратно

>>1018310
Архитектура без железа ничто. Иван Годард считает что регистры нинужны - слишком дорого обходятся на железной стороне. Зацени его архитектуру mill

>>1030466
> The belt is the fast, CPU end of a hardware caching system called the spiller, which moves belt items between subroutines, the scratchpad, static random-access memory (SRAM) buffer, and the reserved spiller memory area (backed by L2 cache) associated with each functional iteration's data area.


В этом что-то есть, но пока что я ориентируюсь на embedded устройства. А для high perfomance computing у меня какая-то карта в рукаве.

> If the bandwidth of the spiller is exceeded, the mill stalls, waiting for the belt to become consistent.

Ага. Ага! Stalls! Не так уж ты и крут, Бэтмэн. :)

>>1030475
>> If the bandwidth of the spiller is exceeded, the mill stalls, waiting for the belt to become consistent.
>
>Ага. Ага! Stalls! Не так уж ты и крут, Бэтмэн. :)
>

Это типа протухания кэша же? то есть, редкое событие

>>1030462
А функциональные языки программирования не прячут? Ну, я не говорю о сборщике мусора, а о, например, линейных типах. https://en.wikipedia.org/wiki/Substructural_type_system ну тип вот это всё. Его нельзя реализовать аппаратно типа? А совместимость... ну епт, в прошлом столетии же было много проектов которые обрывали совместимость и делали полностью новые компьютеры.

>>1030599
>А функциональные языки программирования не прячут?
Прячут.

> Его нельзя реализовать аппаратно типа?

Есть вероятность что можно. Но не факт, что будет быстрее чем сейчас.

> в прошлом столетии же было много проектов которые обрывали совместимость и делали полностью новые компьютеры.

И где они теперь?

>>1030612
>И где они теперь?
IBM-PC например цветет и пахнет.
А что?

С чего ты вообще решил, что какие либо тех характеристики хоть как-то влияют на распространение и долговечность тех или иных тех решений?

>>1030512
>Крутой дед. Миядзаки от кодинга.
Как я понял, у них там анально проприетарная архитектура которую они уже жестко лицензировали и запатентовали(хотя еще нихуя не сделали рабочего)

Так что это не миядзаки, а Пидарашка от кодинга.
Которая бизнес понимает как - срубить бабло и постричь лохов.

Процессор еще не сделали, но уже придумали как его будут всем продавать.

>>1030710
>IBM-PC например цветет и пахнет.

Чой-та ты гонишь. Возьми MS-DOS и какой-нибудь Нортон Коммандер и он запустится на самом современном проце от Intel или AMD.

>>1030713
>Как я понял, у них там анально проприетарная архитектура которую они уже жестко лицензировали и запатентовали(хотя еще нихуя не сделали рабочего)
>

Они это сделали потому что в них влошились инвесторы, а в конечном счёте же нужно сделать прототипы в кремнии (и не проебать интелу или китайцам)

>>1030776
Что ты несёш?
1 незапустится.
2.ibm-pc ни с чем несовместимое говно, на момент выхода ничего кроме страной дос неумеющее.
С чем оно там было совместимо, а ебана?

>>1030890
> незапустится.
И шестой дос, и нортон вполне запускаются на ноуте 2017 года выпуска.

Ты не понимаешь сути. Любые кардинальные изменения обречены на провал, потому что существуют гигабайты исходников, которые хотят классическую архитектуру системы (в том числе и сырые указатели). Если ты делаешь систему, которая этого не умеет - у тебя nogaems тотальный no soft, а без софта ты никому не нужен. Времена, когда для раскрутки железки достаточно было написать под нее бэйсик и эксель давно прошли. Такие дела.

Именно поэтому IBM PC цветет и пахнет. Написана куча кода, который никто не будет переписывать, чтобы тебе стало заебись. А у самого тебя не хватит на это денег, даже если ты Microsoft. Плюс есть еще разработчики, которые в рот ебали переучиваться.

>>1030890
>1 незапустится.
Запустится. Все процессоры Intel серии x86 поддерживают эмуляцию 8088/8086. А BIOS скрывает детали реализации периферии INT13H, INT10H и так далее.

Проблема может возникнуть лишь если UEFI не поддерживает эмуляцию BIOS. Вроде как станд>>1030907
арт UEFI называет эмуляцию BIOS опциональной.

Вот тут https://www.betaarchive.com/forum/viewtopic.php?f=59&t=34023

некто хвалится что запустил MS-DOS на... Macbook Pro.

В остальном - двачую вот его -> >>1030907

>>1030907
>Ты не понимаешь сути. Любые кардинальные изменения обречены на провал, потому что существуют гигабайты исходников, которые хотят классическую архитектуру системы (в том числе и сырые указатели). Если ты делаешь систему, которая этого не умеет - у тебя nogaems тотальный no soft, а без софта ты никому не нужен. Времена, когда для раскрутки железки достаточно было написать под нее бэйсик и эксель давно прошли. Такие дела

Еще раз.
Для тупых.
Для совсем совсем тупых.

На момент выхода IBM-PC существовали гигабайты исходников, которые на этой самой IBM-PС не работали от слова никак.

И что?

А на момент выхода IOS, или андроидла, много приложений существовало под android?

А c ARM как быть?


Еще раз.
Для тупых.
Для совсем совсем тупых.

Никак не связанна совместимость и прочие технические нюансы с успехом и\или распространенностью той или иной аппаратной платформы.

Ты еще скажи что виндовс взлетела благодаря совместимости.
Может еще и 10тая виндовс благодаря совместимости взлетает?

Еще раз, для конченных идиотов.
Рынком управляют множество факторов, куда более весомых, нежели нюансы технической реализации всякой хуйни.

>>1030907
Говно те исходники. И до 2038 года о них все забудут, лишь ретрограды будут о них вспоминать.

>>1030910
> Еще раз.
> Для тупых.
> Для совсем совсем тупых.
> На момент выхода IBM-PC существовали гигабайты исходников
В IBM PC бейсик продолжил запускаться, как и на других машинах. Компилятор сишечки никуда не делся. Поменялась архитектура, но основные принципы остались теми же. И так как компьютеры использовались в основном для работы, можно было написать ОС + эксель + бейсик, чтобы у платформы появились юзеры.

> А c ARM как быть?
Точно так же. Ты берешь кросскомпилятор и конпелируешь. Большая часть кода не меняется, архитектурно-зависимые части переписываешь. Есть огромный шанс, что юзермодный код вообще не потребует модификаций.

Теперь представь, что ты заявляешь, мол unmanaged нинужен, у меня новая архитектура, managed код, нет MMU. Доводов не приводишь, просто "я так захотел". К тебе приходит кастомер, спрашивает: где мой линукс, где мой фаерфокс, где моя сишечка? И уходит.

> android
Гугл жопу порвал, чтобы обеспечить безболезненный переход. Чтобы была Java на десктопе, стала Java на Android. И я на сишечке через NDK пишу абсолютно так же, как пишу на десктопах. И линукс внутри. Ничего не поменялось.

> Может еще и 10тая виндовс благодаря совместимости взлетает?
Миллионы юзеров семерки и сотни тысяч юзеров XP сейчас существуют в том числе из-за проблем с совместимостью.

>>1030916
> И до 2038 года о них все забудут
Подумай, что делает язык кобол в списке TIOBE? Почему он популярнее, чем та же Scala? Обоснуй свой ответ.

>>1030920
Я получаю зарплату в биткойнах.

>>1030921
Сочувствую.

>>1030920
легаси?