Разве микроядро не тормоз?
>Разве микроядро не тормоз?
На этот счёт есть разные мнения. Чтобы ответить на этот вопрос нужно понять, откуда пошло.
Пожалуй, самым ярким сторонником микроядер считатается Эндрю Таненбаум и его Minix. Minix это микроядерная ОС для архитектуры x86 написанная для учебных целей.
Главный оппонент Таннебаума - Линус Товральдс. У них был эпический спор, в котором, отчасти благодаря темпераменту Линуса, он победил. С тех пор пошла молва, что микроядра это тормоз. Это предыстория.
Но почему же микроядра работают медленнее? Ответ на этот вопрос кроется в двух причинах.
Во первых - это организация очереди сообщений. Дело в том, что подсистемы ядра при микроядерной архитектуре обмениваются сообщениями. Чтобы сообщения было получено, приёмник сообщения должен быть готов к его приёму. В случае монолита модули взаимодействуют в едином кванте времении никакого переключения потоков или задач при взаимодействии подсистем не происходит. Задержки на такие операции сводятся к нулю и всвязи с этим монолит работает быстрее.
В микроядре же при таком взаимодействии происходят блокировки до готовности принимающей стороны, отсюда растёт латентность. Для синижения латентности применяются разные методы. Наиболее распространенный - выделять несколько потоково обработчиков входящих сообщений. Что в результате требует синхронизации этих потоков. В целом такой подход снижает латенность, но при этом деградирует общая скорость и увеличивается требование к памяти.
Существуют различные способы обхода этой проблемы - например, гибридное ядро, как у Applle. В этом случае часть драйверов переносится в микроядро, при этом взаимодействие с ними происходит так же, как монолите, но в целом взаимодействие между модулями остаётся на основе сообщений.
Ну и вторая причина мнения о тормознутости микроядер происходит когда драйвер или подсистема ядра запускается как пользовательская задача. В этом случае обращение к драйверу/иодулю произзводят переключение контекста со сбросом TLB, что занимает много тактов на его актуализацию.
Однако, есть и другие способы разгона микроядер, о которых мы поговорим несколько позже. Не сегодня.
Подпишусь на тред на всякий случай, как интересующийся FPGA. Это сложно вообще, если я веб-макака без вузовских знаний?
Что на счет использования аналоговых компонентов и, например, FPAA?
>Это сложно вообще, если я веб-макака без вузовских знаний?
Это не сложно, если есть интерес, то можно и самому. Однако, нужны базовые знания о булевой алгебре и электронике.
Самое сложное в FPGA это выжать максимум частоты из устройства. Тогда действительно нужно включать мозги на полную мощность. Но если устройство предлагает запас по частоте, то можно расслабиться.
>Что на счет использования аналоговых компонентов и, например, FPAA?
Я в аналоговой части не силён. Ну, что-то навроде Covox ЦАП могу соорудить и, вероятно, посчитать со справочником. А вот обратно из аналога в цифру, такого опыта не имею. Хотя во многих современных алтеровских и ксилинковских ПЛИСах есть АЦП и инструменты работы с ними. Например, Картусе можно найти подходящую мегафункцию.
Есть базовые знания по дискретке. Схемотехника нужна? А где кроме Танненбаума нормально про логические вентили можно прочитать?
>Картусе
Квартусе же.
Какой профит от всего этого? Какие проблемы решает? И чьи проблемы?
>Схемотехника нужна?
Базовых понятий для начала хватит. Когда будешь вытягивать частоту из своей схемы, придётся использовать множество инструментов из Картуса. Но чтобы начать это не нужно. Ставишь делитель частоты на основе PLL и сильно не паришься.
Возможно я тебя подбадриваю, но если пользоваться примерами и демками, то начать довольно не сложно.
Кстати, если всерьёз интересуешься, то вот хорошее место где обитают плисоводы - https://marsohod.org/
> А где кроме Танненбаума нормально про логические вентили можно прочитать?
Не, насколько я помню, Эндрю в электронику не лез. У него в общих чертах в объёме, достаточном для понимания базовых принципов.
Я надеюсь что хорошую литературу подскажет кто-нибудь из других анонимов.
Добра, анон! Рад очередному небыдлокодерскому треду.
>Какой профит от всего этого? Какие проблемы решает? И чьи проблемы?
Общепринятое мнение что микроядро повышает надёжность системы. Вероятно это мнение имеет под собой основу. Ну хотя бы тем, что кривой драйвер можно запустить как пользовательскую задачу и его падение не вызовет падение всей системы. Полезно для ответственных применений - например, в космосе или в атомной энергетике.
Есть мнение, что существует способ обогнать на микроядерной системе монолитную по скорости.
Пока оно не доказано, но некоторые разработчики работают в этом направлении.
Ну а в реальной жизни прямо сейчас, есть профиты интересоваться этим? Я понимаю интерес к машинному обучению, его можно применять сегодня же, и оно решает определенные задачи. Понимаю интерес к новым языкам вроде Rust, они решают свои задачи, и их можно использовать уже сегодня.
А какие задачи могут решать эти микроядра не понимаю. Вот сижу я на Линуксе, пишу код, что мне могут дать эти микроядра? Не понял для чего они нужны, с чем конкурируют. Для чего мне этим заниматься, пытаюсь найти интерес для себя?
Чем отличается microkernel от unikernel?
>Полезно для ответственных применений - например, в космосе или в атомной энергетике.
QNX и VxWorks активно используются в космосе и авионике.
>Ну а в реальной жизни прямо сейчас, есть профиты интересоваться этим?
Некоторые профиты есть. Легче найти работу - конкуренции меньше. Большой выбор стран, где востребованы такие специалисты.
>А какие задачи могут решать эти микроядра не понимаю.
Например, ровер Curiosity использует в качестве операционной системы VxWorks.
> Вот сижу я на Линуксе, пишу код, что мне могут дать эти микроядра?
Встречный вопрос - твоему коду важен именно Linux или POSIX совместимость? Будет ли работать твой код, например, на FreeBSD?
> Не понял для чего они нужны, с чем конкурируют.
С Real Time Operating System. Условно, в интеллектуальную кофеварку ты можешь воткнуть Embedded Linux, а можешь и QNX или VxWorks. Во втором случае ты, вероятно, сэкономишь на "железе", ибо требования к нему будут меньше.
> Для чего мне этим заниматься, пытаюсь найти интерес для себя?
А зачем? Если не интересно - не пытайся. Делай то, что тебе нравится. Но если хочешь поработать за границей, то эти знания пригодятся.
>Чем отличается microkernel от unikernel?
Простотой. Единое адресное пространство для всех задач у unikernel. В то время как современные микроядра предлагают изолированные адресные пространства.
>А какие задачи могут решать эти микроядра не понимаю
Обеспечение стабильности ядра и переносимости кода, который в монолитном ядре является аппаратно-ависимым.
18 сентября в Мюнхене будет конференция Minix, до 4 сентября для студентов билет будет стоить 30 евро.
>Некоторые профиты есть. Легче найти работу - конкуренции меньше. Большой выбор стран, где востребованы такие специалисты.
Вряд ли. Системщики сейчас никому не нужны. Если и нужны, то задачи там неинтересные.
>Встречный вопрос - твоему коду важен именно Linux или POSIX совместимость? Будет ли работать твой код, например, на FreeBSD?
Разницы нет. Я привел линукс как свою домашнюю ОС. То есть мои задачи решает полноценная ОС, а значит как пользователю профита от микроядра мне нет.
>Во втором случае ты, вероятно, сэкономишь на "железе", ибо требования к нему будут меньше.
Это экономия на спичках. Микроядро под каждую архитектуру писать не будешь. К тому же писать на ассемблере очень долго и неудобно. Проще взять высокоуровневый язык.
>А зачем? Если не интересно - не пытайся. Делай то, что тебе нравится. Но если хочешь поработать за границей, то эти знания пригодятся.
Вот именно, что эта не та сфера где есть задачи и спрос. Поэтому и спрашивал про задачи, дабы понять для чего это. Теперь ясно. Спроса на это нет. Проще найти работу на Haskell.
>Системщики сейчас никому не нужны. Если и нужны, то задачи там неинтересные.
Нужны нужны. Чем развитее IT в стране, тем выше ценятся системные программисты. Ну и интерес это как бы дело личного вкуса.
> как пользователю профита от микроядра мне нет.
Так это штука и не для пользователей. Во всяком случае пока. Но где-нибудь в недрах твоего автомобиля ему место есть.
> Это экономия на спичках.
Зависит от вала. Например, неоторые производители современных телевизоров ставят в свои изделия безумно дешевый специализированный процессор. При тех количествах продукции, которую они производят, цена имеет значение.
>Микроядро под каждую архитектуру писать не будешь.
Все популярные микроядра уже портированы на все популярные процессоры.
> К тому же писать на ассемблере очень долго и неудобно. Проще взять высокоуровневый язык.
Так и не пишут сейчас на ассемблере под микроядра. На Си и С++. В прикреплённой теме, в которой я начал повествование, речь шла о о конкретном процессоре с оригинальной системой команд, который реализован только в FPGA. Ну да, я хочу плавно подвести тему к этому устройству. Несколько позже. Когда народ втянется в обсуждение.
Кстати, вот эта вот модульность микроядер позволяет писать модули в том числе и на Паскале. Но при этом придётся отказаться от готовых библиотек и реализовывать их самому. И это не будет "костылями".
Ручное управление памятью ненужно.
Ещё скажи, что динамического управления памятью хватит всем.
Потомки, как там в 2030?
Память не нужна
Почти всегда хватает. Про расиянские контроллеры речи не идет. Например Erlang давно используют в телефонии. Его можно запускать без операционной системы.
Про какой объем памяти идет речь?
>Его можно запускать без операционной системы.
Ещё скажи что он сам на себе написан.
Насчет Эрланга не интересовался, а вот компиляторы Си, Go, Python, Ruby, Scheme, etc - написаны на самих себе. Почему язык не может исполнять самого себя, если он Тьюринг полный?
Раскрутка компилятора - метод написания транслятора для языка, при котором транслятор пишется на том же языке.
Список самотранслирующихся языков:
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)
>Нужны нужны
Но сейчас вакансий в России очень мало, да и те, в основном, либо НИИ, либо военная промышленность.
>Раскрутка компилятора - метод написан
Что было первым - курица или яйцо?
Когда уже есть стабильно работающая версия какого-то языка, то можно и реализовать его на самом себе. А самую первую версию?
Есть разные подходы, один из них такой:
Создание транслятора языка L методом раскрутки подразумевает выполнение некоторых шагов.
На первом шаге из языка L выделяется подмножество L0, которое не требует больших усилий для реализации, но является достаточным для написания транслятора самого себя. Затем, используя какой-либо существующий для этой платформы язык (например, C), составляется исходный код транслятора для L0.
Затем на языке L0 составляется транслятор для самого языка L0. Исполняемый файл транслятора создаётся с помощью транслятора, полученного на первом шаге. После этого у программиста имеется транслятор L0, способный обработать свой исходный код.
Далее начинается постепенное расширение L0 до L: добавляется какая-либо ранее не реализованная возможность языка L, после чего предыдущей версией транслятора создаётся новая, а вновь добавленную возможность можно использовать в трансляторе для последующего расширения языка.
Скопировано с википедии.
Как бы да. Я особо не с этим не спорю. Но надеюсь что со временем ситуация выправится. Да и заграницей перед системными программистами открыто больше дверей.
И всё же давайте обсуждать тут технические аспекты, а трудоустройство обсудим в других темах.
А что обсуждать. Писать надо. Ты в этом больше разбираешься, накинь какая платформа и функционал нужны.
Ты пишешь на ассемблере? Как на асм реализуют конкурентность и параллельность?
>накинь какая платформа и функционал нужны.
Мне нужно пару дней чтобы оформить мысли. Речь идёт о двух с половиной проектах, которые должны соединиться в единое целое. Извини, что приходится уклоняться от прямого ответа.
Сегодня предлагаю посмотреть на, пожалуй, лучшее из всех когда либо существовавших в истории микроядер - https://github.com/l4ka/pistachio
Чтобы ознакомиться с ним понадобятся Linux со средствами разработки (g++, gnu toolhain, etc) и виртуальная машина, любая на выбор - VmWare, VirtualBox, MS Virtual PC или любая другая. Она понадобится чтобы запускать в ней микроядро и если кто использует Windows на своём десктопе, то в виртуальной машине придётся поселить Linux.
Если делать всё по инструкции, можно собрать образ загрузочной дискет с тестовыми программами, этот образ можно подсунуть виртуальной машине и загрузиться с него. Разумеется, ни о какой графической оболочке речь не идёт. На демке микроядра даже не будет командной строки, файловой системы - вообще ничего, только микроядро, представляющее некоторый интерфейс. Это на порядок меньше чем предоставляет даже голое ядро Linux.
Не страшно ещё?
>Ты пишешь на ассемблере? Как на асм реализуют конкурентность и параллельность?
В прикладной программе реазовывать такие фичи бессмысленно и неэффективно. Тогда уж лучше суперцикл.
А если на уровне ядра, то обычно задачи переключаются двумя способами - при вызове systemcall ядра проверяется очередь задач в зависимости от приорите вызывающая задача ставится в очередь, а управление передаётся наиболее приоритетной задаче. Кроме того существуют так называемые объекты синхронизации - защелки, семафоры и критические секции, в момент использования которых может переключиться контекст.
Ну и крайний случай переключения задач плохой написанной программы или выполняющей тяжелые вычисления это переключение задачи по таймеру, когда ОС насильно прерывает задачу, которая длительное время не обращалась к функциям ядра.
176 712 строк кода. Чей это проект вообще и почему не развивается?
Писать столько кода на C/C++ это боль. Как вариант Ocaml.
>176 712 строк кода. Чей это проект вообще и почему не развивается?
Это проект университета Karlsruhe. Почему он не развивается - есть несколько причин. Где-то четыре - 1) сообщество не раскушало все прелести, 2) подковёрный конфликт между университетом Karlsruhe и университетом UNSW
3) лучших результатов на основе этого ядра достиг неправильный человек с проектоом с неправильной лицензией, 4) вероятно, ВПК Германии не очень приветствует распространение этой штуки.
Но я не утверждаю что вторая и четвёртая причины реальны. На уровне слухов и догадок.
Почему бы не экзоядро?
>Писать столько кода на C/C++ это боль. Как вариант Ocaml.
Эта штука работает напрямую поверх железа. Ниже уровня уже не бывает. Чтобы на этом запустить Ocaml, понадобится несколько программных слоёв между микроядром и Ocaml.
>Почему бы не экзоядро?
L4 Pistachio довольно близко по смыслу к тому, что называют экзоядром. API минимален - абстагированы процессы/нити и адресные пространства.
Зачем запускать окамл на ядре. Написать ядро на окамле. Он компилируется в машинные коды.
Еще есть конкатенативные языки программирования как интересная альтернатива.
https://stepik.org/course/Операционные-системы-1780/syllabus
Я ньюфагам (себе в том числе) покушать принес.
Вы что-то с обработкой сигналов (и в частности сигнальными процессорами) будете городить?
> Написать ядро на окамле. Он компилируется в машинные коды.
Он позволяет ассемблерные вставки? Если да, то вполне возможно. Дело в том, что языки высокого уровня не предоставляют некоторые возможности по работе с железом напрямую.
Но я бы в такой проект не подвязался.
Почему не на Rust?
>Вы что-то с обработкой сигналов (и в частности сигнальными процессорами) будете городить?
Не совсем. Задача поместить нечто навроде микроядра L4 непосредственно в железо. Ну а дальше как получится.
Что касается блоков обработки сигналов, то вероятно будет рассматривать их как отдельные функциональные блоки в составе процессора или в виде сопроцессоров.
В данном случае микроядро предлагает удобный и эффективный интерфейс для взаимодействия блоков управления сигналами и центральным процессором. Т.е. первоначальную обработку сигнала производит соотвествующий блок, а уде обработанный сигнал передаётся процессору в виде сообщения. В отличие от прерываний, сообщения предполагает лучшую масштабируемость.
А каков бамплимит у тем в /po/?
Да. Он позиционируется как замена C/C++, при чем в некоторых тестах он быстрее их.
Первый компилятор Раста был на Окамле, потом его переписали на Раст.
Ты смотрел forth-процессоры?
Хочу сразу раз и навсегда ответить на такие вопросы. Само по себе микроядро это нечто очень простое, выполняющие лишь функции по управлению задачами и адресными пространствами. Благодаря взаимодействию посредством сообщений, нет нет необходимости помещать все задачи в единый исполняемый модуль. Поэтому, например, сетевой стек TCP/IP при желании можно написать на любом языке, независимо от того, функциональный он или процедурный, в простейшем случае компилятор должен уметь генерировать объектные файлы в формате ELF. Или в каком-то другом - не суть важно.
Нельзя лишь использовать интерпретаторы или среды программирования, которые генерируют исполняемый код посредством линковки исходного текста программы и интерпретатора, оформляя это в виде исполняемого файла.
Конечно. Обратная польская запись - нашё всё.
Так суть не в этом и не обязательно она. Просто говорю, что вместо микроядра пожалуй в железо лучше впихнуть нечто другое. Присмотрись к конкатенативным языкам и к этому всему.
>Просто говорю, что вместо микроядра пожалуй в железо лучше впихнуть нечто другое.
А вот готов поспорить. Я рассчитываю ввести в железо абстракцию понятия "задача", а в систему команд несколько инструкций для обмена сообщениями между задачами. Плюс к этому аппаратный планировщик задач.
У тебя есть опыт написания ОС?
>Почему не на Rust?
Зачем кучу времени на изучение нового (сложного) языка?
>в некоторых тестах он быстрее их.
Синтетические тесты мало говорят о реальной производительности.
То-есть фитчи типо kernel-alloc тоже будут как модули и можно будет их заменять?
>>в некоторых тестах он быстрее их.
>Синтетические тесты мало говорят о реальной производительности.
На окамле скорость разработки минимум в 2 раза быстрее чем на крестах, и кода меньше будет раза в 4. Устраивает такой ответ?
Да, у меня есть такой опыт.
>То-есть фитчи типо kernel-alloc тоже будут как модули и можно будет их заменять?
В общем случае - да. Суть в том, что микроядре L4 работа с памятью реализована.... необычно и оригинально. Одновременно с микроядром стартует самый первый процесс - Sigma0, который владеет АБСОЛЮТНО ВСЕЙ оперативной памятью. В момент инициализации микроядро запрашивает несколько страниц под свои нужды.
Вся дальнейшая работа происходит через запрос маппинга физических страниц в адресное пространство задачи. Никаких аллокаторов микроядро L4 не предоставляет. Нужна эмуляция POSIX malloc? Пожалуйста - пиши свою реализацию аллокатора. Если нужно превратить микроядро в полноценное ядро, то придётся реализовывать системный вызов sbrk.
Другая фишка страничной памяти L4 это так называемые flexpages - фича, эмулирующая страницы с произвольым размером кратным размеру физической странице, поддерживаемой процессором, умноженным на 2 в степени N.
Где N, условно, произвольное число.
Что читать чтобы такие штуки писать? Подкинь литературы плиз.
Начать наверное лучше с Таненбаума.
Операционные системы: разработка и реализация 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
Пасиб
Есть хорошая книга - Ядро Linux. Описание процесса разработки.
>Синтетические тесты мало говорят о реальной производительности.
Собственно, там даже если обгоняет Си тот же, то ценой повышения потребления памяти.
>абстракцию понятия "задача", а в систему команд несколько инструкций для обмена сообщениями между задачами
Что-то знакомо, можно подробней? Это похоже на транзакционную память?
>аппаратный планировщик задач
Посмотрел немного это чудо. Говорят, что благодаря хитрой аппаратной схеме аппаратного планировщика задач получается сэкономить на переключении контекста. Но если брать стековые процессоры то там чудным образом переключение контекста уже и так стоит копейки (ибо используется в основном стек, конечно же, хех). Ты в общем посмотри на стековые процессоры и MISC, а так да, стремление к множеству ускорителей и гетерогенности вычислений весьма хорошо как по мне.
>схеме аппаратного планировщика задач получается сэкономить на переключении контекста
Странно, что интел/АМД не дают доступа к полному файлу регистров. Там же их сотни сейчас, и используются они только для переименования регистров. Почему бы не дать возможность скидывать/восстанавливать контекст? Гипертрединг же они туда привинтили, который по-сути именно это и делает - переключает исполнительный модуль на первый или второй набор регистров для эмуляции двух ядер.
>Но если брать стековые процессоры то там чудным образом переключение контекста уже и так стоит копейки
Ты и на регистровых так можешь сделать, если будешь точно знать, какие регистры используются процессом, и сохранять не все ебучие килобайты включая AVX-512, а только нужные. Им только нужно добавить инструкцию, которая позволит компилятору с некоторой периодичностью метить используемые/неисопльзуемые регистры.
>Почему бы не дать возможность скидывать/восстанавливать контекст?
СЛОЖНА
НЕПОНЯТНО НИЧЕГО
ЯДРА КАКИЕ-ТО
ПАРАЛЛЕЛЬНОСТЬ БЛЯДЬ!
Современные мейнстримные процы маскируют ядра чтобы современные менйстримные легаси он могли работать.
А ОС в свою очередь маскируют параллельность еще сильнее.
Говно говном погоняется.
Итаниумы вон похоронили даже.
Сложна, непонятно.
А ТУТ ВЗЯЛ И СРЕШЬ КОД КАК БУДТО У ТЕБЯ ОДИН ПОТОК ИСПОЛНЕНИЯ
А ОС САМА ВСЕ ПОПЕРЕКЛЮЧАЕТ НАХУЙ
СЕГФОЛТ ПРАВДА ВЫСКОЧИТ И ДЕДЛОК
ЗАТО ПРОСТО И ПОНЯТНО
>растёт латентность
Переводишь как дебил. Сам читаешь что пишешь?
>если будешь точно знать, какие регистры используются процессом, и сохранять не все ебучие килобайты включая 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 нм.
Полностью согласен. Такие монструозные абстракции плохи. А если бы компилятор имел полное представление о процессоре (с MISC это было бы не так и сложно) то всё было бы отлично.
Кажется, что идет несколько шаг в том чтобы сделать похоже на новую кору человека. Например, реактивное программирование хороший пример.
>Как компилятор это будет делать?
Во время аллокации регистров, например. Компилятор же все используемые регистры видит. Не обязательно к тому же метить каждый регистр. Достаточно говорить, что тут, например, включили использование SSE-AVX, тут выключили. И при переключении контекста можно будет сохранять только целочисленные регистры.
>Вообще стековые процессоры как можно видеть дают много преимуществ
У них основная проблема в том, что сложно делать суперконвейерность. Каждая инструкция мутирует стек, результат инструкции зависит от предыдущих, и поэтому сложно запускать в работу несколько инструкций сразу. Мур на GA144 все очень хитрожопо сделал - в машинное слово упаковываются сразу четыре инструкции, причем возможны "микроциклы" внутри этих четырех инструкций. Так он делает умножение, например: в одно слово упаковываются сложение, сдвиг и микроджамп. Только он пишет все это вручную, потому что на таком ограниченном железе как у него, ни один компилятор с оптимизацией не справится. То есть для форт-машин нужны в первую очередь форт-программисты. А обычный кодер как Мур вряд ли может работать. Тот же ОКАД, например, он десятки лет пишет и переписывает, постоянно упрощая и убирая ненужное. В таком режиме не один заказчик не даст работать.
Что за язык на ОП-пике?
>Полностью согласен. Такие монструозные абстракции плохи. А если бы компилятор имел полное представление о процессоре (с MISC это было бы не так и сложно) то всё было бы отлично.
Компиляторы должны быть проще.
Гепероптимизуриющие gcc - тупиковая ветвь, как мне кажется.
Программа должна быть ближе к аппаратной архитектуре(что не противоречит высокому уровню абстракций).
Ну или в случае со средой выполнения, сама среда должна быть близка к аппаратной платформе, и ЯП должен быть близок к среде.
Но в результате использование среды выполнения, ЯП может абстрагироваться от аппаратной платформы, при этом вся система в целом остается прозрачной.
>суперконвейерность
суперкостыльность
Проблемы с параллелизмом возникают, когда аппаратная платформа начинает маскировать свою параллельную природу.
Verilog
Посоны, как вкатиться в системное программирование?
Знаю только си на уровне хеловорлда.
Знаю только си на уровне хеловорлда.
Вот тут рассмотрены некоторые варианты переключения контекста, когда в работу вступает планировщик.
Природа микроядра такая, что программа или система строится как множество потоков, обменивающихся сообщениями. Поэтому к выше описанным точкам переключения контекста добавляется ещё одна - момент передачи сообщения. Поэтому планировщик в случае микроядерного решения особенно важен.
Если реализовать передачу программными средствами, например, в классической операционной системе, то придётся использовать стандартные средства синхронизации - защёлки, семафоры и критические секции, которые и будут точками переключения контекста при передаче сообщений.
Но если "железо" аппаратно поддерживает многозадачность и имеет средства передачи сообщений, то это именно то место, в котором в подавляющем большинстве случаев будет переключаться контекст.
При этом ранее описанные точки переключения контекста будут чрезвычайно редки или выродятся в сообщения.
Попытаюсь пояснить - почти не изменится переключение задач по таймеру - это так и останется редким случаем неправильно реализованного алгоритма или "тяжёлых" вычислений.
Системные вызовы от прикладной программы к ядру вырождаются в сообщения.
А средства синхронизации - защёлки, семафоры и критические секции теряют свою актуальность и становятся необходимыми только для обратной совместимости. Потому что на этапе проектирования программы взаимодействие задач проектируется таким образом, что сами сообщения являются синхронизаторами.
Увы. Я не могу выразить это более понятно или наглядно, может быть позже покажу примеры в коде.
Три дороги ведут в системное программирование:
1) программирование микроконтроллеров
2) программирование драйверов для Linux или патчи ядра
3)программирование драйверов для Windows
Ещё можно "на коленке" попытаться написать свою операционнку, но 99 из 100 программистов останавливались где-то на этапе написания начального загрузчика, вместо того чтобы использовать grub.
>Проблемы с параллелизмом возникают, когда аппаратная платформа начинает маскировать свою параллельную природу.
Ну так можно и сложение за 32 такта делать вместо одного. Зато блок АЛУ и параллелизм не маскируется.
>Увы. Я не могу выразить это более понятно или наглядно, может быть позже покажу примеры в коде.
Программные прерывания не можешь выразить это более понятно или наглядно а хотя аноним с двачей, понятно, понятно...
>но 99 из 100 программистов останавливались где-то на этапе написания начального загрузчика
Потому что надо сразу микроконтроллер брать, а не ебать себе мозг легаси-начинкой x86.
>Зато блок АЛУ
Блок АЛУ маленький. fix
Планирую вкатиться в микроконтроллеры.
С чего начать?
Сдилойти ОС, которая будет сидеть в кеше процессора и не будет занимать ОЗУ.
А как насчет реверс инжиниринга. К чему он ведет?
Если кому надо, курс - Разработка модулей ядра 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
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
Я думал вы тут будущее обсуждаете, а не всякую монолитную хрень, которую скоро заменят SystemDOS.
>которую скоро заменят
Уа-ха-ха, виндавс себе замени.
Ты не понял шютки? Операционная система на основе Systemd — SystemDOS. И полный отказ от юниксвея.
Ебало завали.
Ставь пробел перед выделеним ссылки.
https://stepik.org/course/Разработка-модулей-ядра-Linux-(08)-2051/syllabus
К саморазрушению. Выбирай жизнь
куда ставить?
Линух превратился в огромный костыль.
Какую ОС юзаешь?
>Сдилойти ОС, которая будет сидеть в кеше процессора и не будет занимать ОЗУ.
Есть такие. Тащить любой Dos.
Переде тем как скопировать ссылку , добавь к ней в конце пробел и выделяй вмечте с пробелом, и тогда не будет кракозябр.
Очередная ебля с порядком байтами в utf вроде.
Уже не помню.
Я хз что ты имеешь ввиду.
Производительность возрастет.
Haiku Нет. Просто дистрибутив без systemd.
Нашел интересную книгу, мож кому пригодится
Low-Level Programming: C, Assembly, and Program Execution on Intel 64 Architecture
Легко гуглится для скачивания
Low-Level Programming: C, Assembly, and Program Execution on Intel 64 Architecture
Легко гуглится для скачивания
фонатег штоле, че не так с systemd?
Вот, хочу кое-то вам показать - на картинке карта системы команд с громким названием "архитектура Эверест". Название родилось "случайно" - попытка потроллить МЦСТ с "Эльбрусом". Ну и как бы намёк, что более высокой горы уже не бывает (хе-хе, вопрос спорный).
Особенности системы команд "Эверест"
Максимальный потенциал расширяемости
Отсутствие аппаратного стека - стек "по соглашению"
Операции с плавающей запятой не определены
Приемлемая плотность кода, которая будет лишь увеличиваться с расширением системы команд
Спроектирована с учётом аппаратной поддержки многозадачности
Абсолютно все переходы относительные - используется знаковое смещение от адреса инструкции
В настоящий момент прототип устройства работает на девборле Марсоход-2 с алтеровской ПЛИС. С внешним миром общается по виртуальному UART, прокинутому поверх USB.
Несмотря на то, что устройство работает и его можно как-то использовать, на сегодняшний момент реализовано около половины от того, что должно получиться в итоге.
Задавайте ваши вопросы. Только сразу говорю, местами буду "темнить" и "юлить", дабы скрыть KnowHow. Но таких мест немного, поэтому на большинство вопросов отвечу честно.
Особенности системы команд "Эверест"
Максимальный потенциал расширяемости
Отсутствие аппаратного стека - стек "по соглашению"
Операции с плавающей запятой не определены
Приемлемая плотность кода, которая будет лишь увеличиваться с расширением системы команд
Спроектирована с учётом аппаратной поддержки многозадачности
Абсолютно все переходы относительные - используется знаковое смещение от адреса инструкции
В настоящий момент прототип устройства работает на девборле Марсоход-2 с алтеровской ПЛИС. С внешним миром общается по виртуальному UART, прокинутому поверх USB.
Несмотря на то, что устройство работает и его можно как-то использовать, на сегодняшний момент реализовано около половины от того, что должно получиться в итоге.
Задавайте ваши вопросы. Только сразу говорю, местами буду "темнить" и "юлить", дабы скрыть KnowHow. Но таких мест немного, поэтому на большинство вопросов отвечу честно.
Слушай, написание виртуальной машины типа JVM и написание операционной системы схожи по задачам?
> системы команд
К какой системе команд она преближена?
Честно говоря - не знаю. Но могу предположить что что-то общее есть.
> Отсутствие аппаратного стека - стек "по соглашению"
В смысле, регистр можно выбрать самому и нет явных push/pop? У половины RISC-архитектур так.
> Операции с плавающей запятой не определены
Инстант фэйл.
> Спроектирована с учётом аппаратной поддержки многозадачности
А интел дропнул аппаратное переключение. Ну дураки, что с них взять.
> Абсолютно все переходы относительные - используется знаковое смещение от адреса инструкции
Прямо абсолютно все? Indirect-то хоть есть?
>К какой системе команд она преближена?
Вдохновлялся различными архитектурами, старался заимствовать идеи от PDP-11, x86 и от RISC. Вот вот сказать что она похожа на кого-то - не могу.
Например, долго боролся с проектированием стека - вводить ли PUSH/POP или делать как у RISC. У каждого решения свои плюсы и минусы, в результате решение отказаться аппаратнного указателя стека от перевысило.
>прототип устройства работает
Какой-нибудь софт уже есть под него?
Совсем не схожи.
Я со своей рекламой стековых процессоров начал вызывать ненависть даже ко стеку?
Если не идет речи о виртуальной машине работающей под некоторой ОС то весьма схожи.
>В смысле, регистр можно выбрать самому и нет явных push/pop?
Да. Но по соглашению это регистр R14
> У половины RISC-архитектур так.
Угу. Я в курсе.
>> Операции с плавающей запятой не определены
>Инстант фэйл.
Система команд может расширяться неограниченно. Возможно в будущем такие инструкции будут определены. Пока же мне видится оптимальным использование сопроцессоров. Математического сопропроцессора. Но об этом чуть позже. Это должен быть не простой сопроцессор, а очень хитрый, кушающий целые выражения, а не простые операции.
>А интел дропнул аппаратное переключение.
Ты имеешь в виду переключение задач через TSS?
>Прямо абсолютно все? Indirect-то хоть есть?
Есть, но только один регистр позволяет это - регистр R15. Собственно, это команда RETURN.
RETURN это переход под адресу, который является содержимым регистра R15
> Какой-нибудь софт уже есть под него?
Транслятор ассемблера и несколько простых примеров на ассемблере.
Почему нельзя было сделать PUSH reg/POP reg? А вдобавок к ним еще операцию чтения со смещением чтобы сразу MOV [r0], r1; ADD 4 r0.
Только относительные джампы - тоже очень странное решение, даже таблицу виртуальных функций без геммороя не сделаешь.
Пилите квантовый процессор, епта.
>Я со своей рекламой стековых процессоров начал вызывать ненависть даже ко стеку?
Нет нет нет. Напротив, я стек очень люблю. Просто хитрая работа со стеком в другом проекте и есть часть "Know How", поэтому я стараюсь игнорировать эту тему и не привлекать к ней внимание, дабы ненароком не раскрыть секреты.
Какая цель всего этого? Сделать йобапроцессор и йобаПО?
Какая длина команды? Как иммидиаты задаются?
> Система команд может расширяться неограниченно
Нефиксированная длина команды (т.е., префиксы в том или ином виде) - это фуууу. Это необоснованные сложности при выборке и декодировании. Это было нормально в восьмидесятых, но не сейчас.
> TSS
Да.
> Есть, но только один регистр позволяет это - регистр R15
Т.е., вместо нормального вызова функций по указателю или оптимизации switch через табличку - пляски с сохранением R15, пляски с самостоятельной (как я понимаю), т.е., минимум 3 инструкции, считая сохранение адреса возврата (вручную!).
Ну как же так. Скрываешь самое интересное.
>Почему нельзя было сделать PUSH reg/POP reg?
Потому что планировал в будущем расширить систему команд автоинкрементом и автодекрементом, как у PDP-11.
> А вдобавок к ним еще операцию чтения со смещением чтобы сразу MOV [r0], r1; ADD 4 r0.
Это уже есть. И даже работает начиная с какой-то версии
http://everest.l4os.ru/0xd0_second_edition/
>Только относительные джампы - тоже очень странное решение, даже таблицу виртуальных функций без геммороя не сделаешь.
Изначально исходил из того, что весь код должен быть позиционно независим. Только позиционно независим.
Что касается таблицы виртуальных функций. Пока не появится соотвесттвущее расширение системы команд, придётся использовать ассемблерный макрос, который спрячет весь геморрой. Да, это будет не слишком эффективно в плане быстродействия, но увы.
>оптимизации switch через табличку
Свитч-то как раз лучше через смещение делать, там расстояния небольшие и известны заранее, поскольку компилируются в одном блоке.
Епт, сразу бы дал ссылку на сайт.
Гипервизоры имеешь ввиду? Вики говорит, что гипервизор представляет из себя микроядро.
Длина команды от 1 байта до пяти. Длина инструкции однозначно вычисляется по первым битам - все инструкции сгруппированы по их длиине.
Пространство системы команд начиная с 0xff не определено. Теоретически можно добавить инструкции, чья длина ограничена возможностями железа и здравым смыслом.
> Как иммидиаты задаются?
Три формы LOAD c 8, 16, 32 бита
В инструкциях с чтением/записью памяти со смещением, смещение это несколько бит в во следующих байтах инструкции.
Прибавить или удалить константу без использования промежуточного регистра нельзя.
Макроассемблер скрывает всю грязную работу и ассмемблерный код позволяет различные формы команд, с непосредственными константами.
> Свитч-то как раз лучше через смещение делать
Ну если jmp reg - это jmp ip+reg, то да. Но я не вижу на карте опкодов jmp reg. А значит, есть только вариант с return через жопу и абсолютной адресацией.
Уйдет ли это дальше студенческого проекта на fpga?
Нет, оно неюзабельно.
>Операции с плавающей запятой не определены
Можно вопрос, а тут такие прошаренные люди собрались, что пиздец.
Почему всюду пихают эту сраную плавающую запятую, почему не используют с фиксированной точностью?
Это ведь мега проще считать, да и вообще, для расчетов выглядит более разумным решением.
Википедия только говорит, что мол с фиксированной СЛОЖНА программистам.
Но мне непонятно вообще, в каком месте программистов это касаться должно.
Я вот очень хочу процессор чтобы считал с фиксированной точностью цыферы...
>Ну если jmp reg - это jmp ip+reg, то да. Но я не вижу на карте опкодов jmp reg
И правда. Я не посмотрел.
>Почему всюду пихают эту сраную плавающую запятую, почему не используют с фиксированной точностью?
Потому что в трехмерке, например, ты заебешься между масштабами конвертировать. Простая матричная трансформация становится достаточно нетривиальной задачей. Плюс делить флоаты быстрее, чем инты, хотя деления надо избегать любой ценой, конечно.
>Нефиксированная длина команды (т.е., префиксы в том или ином виде) - это фуууу. Это необоснованные сложности при выборке и декодировании.
Ну так я не только нарисовал табличку с инструкциями, но и реализовал это в Verliog. С иинструкциями вплоть до 5 байт особых проблем нет - пять байт никогда не могут занять три машинных слова, а два слова решаются довольно просто с точки зрения схематики.
>
>> TSS
>Да.
Я бы тоже отказался от этого решения. :)
Сообщение - вот лучший рычаг для переключения задач.
>Т.е., вместо нормального вызова функций по указателю или оптимизации switch через табличку - пляски с сохранением R15, пляски с самостоятельной (как я понимаю), т.е., минимум 3 инструкции, считая сохранение адреса возврата (вручную!).
Для всех этих вещей я использовал префикс - NOTCH. С его помощью на ходу относительные адреса транслируются в абсолютные. Этот префикс активно используется для всяких трюков, макроассмеблер во многих случаях использует его, при этом ассемблерный код выглядит более привычным для программиста.
А каков тут бамплимит? С такой скоростью тема быстро закончится.
Почитал немного о ваших этих хамелеонах.
>реализована на объектно-ориентированном языке программирования;
Я недоволен. Требовать функционального программирования! Тем более, где-то там завалялось формально верифицированное микроядро.
>реализована на объектно-ориентированном языке программирования;
Я недоволен. Требовать функционального программирования! Тем более, где-то там завалялось формально верифицированное микроядро.
А разве все эти пересылки сообщений по своей сути не суть абстракция над семафорами и тд? Ведь тоже надо блокировать дабы сообщение не перекрыло друг друга или делать память отдельную но то медленно... ну сумбурно выразился
>Потому что в трехмерке, например, ты заебешься между масштабами конвертировать. Простая матричная трансформация становится достаточно нетривиальной задачей.
Эт почему?
И зачем что-то там явно вообще конвертировать?
Как раз в случае фиксированной точки, очень легко конвертировать, множитель и инкрементировать, и все.
Я в общем все еще не пони.
Ну попробуй написать. Тебе придется везде конверсии масштабов и декомпозиции вставлять. На 64 битах можно особо не париться, конечно. Но на 32, и тем более на 16, как во времена MMX, геммороя просто туча. Та самая матричная трансформация из простого умножения матрицы на вектор превращается в три - повернуть по базису, заданному нормалями, скейл в нужном масштабе, смещение в нужном масштабе. Для разных масштабов, соответственно, нужны разные матрицы. Самая засада в том, что точных алгоритмов для 1/х, квадратного корня, обратного корня, у тебя не будет. Под каждый масштаб нужно выбирать свою аппроксимацию и выдрачивать алгоритмы на нужную точность.
Самый главный вопрос - зачем все это? Чем вас существующие решения не устроили? И еще, какая у вашего проца ниша? Для микроконтроллеров аппаратный шедулер и виртуальная память вроде не особо нужны, а для более тяжелых задач проще готовое решение взять.
> Почему всюду пихают эту сраную плавающую запятую, почему не используют с фиксированной точностью?
В общем-то тебе тут уже ответили, но дополню. Для реализации фикседпоинта тебе не нужны специальные инструкции, ты просто берешь и пользуешься существующими инструкциями сложения-вычитания и умножения-деления (которых у ОПа нет, кстати), и тебе в общем-то норм. А вот "программно" с плавающей запятой работать ты охуеешь, будет слишком медленно.
>Ну если jmp reg - это jmp ip+reg, то да. Но я не вижу на карте опкодов jmp reg. А значит, есть только вариант с return через жопу и абсолютной адресацией.
Хороший комментарий. Спасибо. Мне нужно подумать. Первое решение, которое пришло в голову... не рискну его тут воспроизвести, дабы не подняли на смех.
Но даже если при текущая система команд не позволит сделать красивый и быстрый переход по таблице, то вот этот желтый цвет в таблице это незайдествованные опкоды. Просто добавится ещё одна инструкция на такой случай.
Как говорят, - чтобы расти в шахматах нужно играть с более сильным противником. Также и программирование, если писать одни круды расти не будешь. Нужны сложные задачи.
Как говорят, - чтобы расти в шахматах нужно играть с более сильным противником. Также и программирование, если писать одни круды расти не будешь. Нужны сложные задачи.
> А разве все эти пересылки сообщений по своей сути не суть абстракция над семафорами и тд?
В некотором роде да, но тут стоит обратная задача - для совместимости с существующим кодом на основе сообщений реализовать объекты синхронизации.
> Ведь тоже надо блокировать дабы сообщение не перекрыло друг друга или делать память отдельную но то медленно..
Pistachio поддерживает только синхронные сообщения. Если одна из сторон не готова, то другая блокируется на время таймаута, который в частном случае может быть бесконечным.
Тут тоже обратная задача - чтобы всё не блокировалось и не подвисало постоянно нужно изворачиваться. Но вся эта кухня выносится в отдельный слой и прикладному программисту не придётся переучиваться.
Я тебе бы посоветовал взять дизасм движок какой-нибудь (capstone, например), какой-нибудь парсер PE и пройтись по секциям кода каждого исполняемого файла из C:\windows\system32. Кладешь результаты в базу, группируешь инструкции по типу, строишь гистограмму по частоте использования и видишь, чего "хотят" программы, думаешь, чего из этого у тебя нет, что имеет смысл делать несколькими инструкциями, а что вот прямо обязательно должно быть коротким и удобным. Для других архитектур аналогично.
>А вот "программно" с плавающей запятой работать ты охуеешь, будет слишком медленно.
Наоборот, если известный, годами разработанный алгоритм, то фиксированная точка быстрее. Почти все DSP работают с фиксированной точкой. Проблема в том, что для новой задачи каждая строчка арифметики превращается в заебывающий мозги квест с конверсией масштабов. Самая большая проблема с делением - с флоатами ты просто делишь не парясь, а с фиксированной точкой нужно очень четко понимать, что у тебя в знаменателе, и какая точность будет у результата.
Я не о том. Я про софтфлоат, т.е., эмуляцию FPU.
Чисто для развлечения, конечно, гораздо интереснее работать, особенно, если работу оплачивают.
>Самый главный вопрос - зачем все это?
По крайней мере это интересно.
>Чем вас существующие решения не устроили?
Много лет назад мне попало в руки Pistachio. Начал изучать, несколько раз на грабли наступил, а потом внезапно нашёл оригинальное решение по обработке сообщений. Отсюда всю пошло поехало. Короче, хобби такое.
> И еще, какая у вашего проца ниша?
Пока только микроконтроллер.
>Для микроконтроллеров аппаратный шедулер и виртуальная память вроде не особо нужны, а для более тяжелых задач проще готовое решение взять.
А пока о виртуально памяти речи и нет. Ну то есть в отдалённой перспективе есть планы сделать поддержку страниц flexpages - эта штука открывает очень интересные возможности по управлению памятью. Но сейчас этим заниматься смысла нет. Слишком сложно и нет таких ресурсов.
Что касается аппаратного планировщика, то как раз он имеет смысл. А вот таймеры, которые так любят разработчики на микроконтроллерах, становятся лишней сущностью. Таймеры легко и непринуждённо заменяются таймаутами сообщений. При этом код становится проще, читабельней и оптимальнее.
Господа, а микроконтроллеры/драйверы винды и линукса - можно начинать, если я являюсь веб-макакой мерзкой? И вообще, есть ли перспектива переката? Просто у C# индусов - есть варианты, а тут? Вопрос тупой, но интересны возможности переката за рубеж.
> А вот таймеры, которые так любят разработчики на микроконтроллерах, становятся лишней сущностью. Таймеры легко и непринуждённо заменяются таймаутами сообщений.
Приоритеты-то хоть будут? Возможность прервать обработку прерывания сообщения чем-то гораздо более необходимым в текущий момент?
Для микроконтроллеров нужны знания электроники и опыт. Мамкиного ардуинщика, мигающего светодиодами, никто не возьмет. Для драйверов - опять же опыт и многолетние мозоли на морде от грабель в различиях минорных версий ядра.
Странные вопросы. Если ты можешь решить любую задачу, ты будешь ценным везде. Но сначала же нужно этот опыт получить. Глупо делить шкуру неубитого медведя.
> Приоритеты-то хоть будут?
Иерархия приоритетов древовидная. В корне планировщик, которому принадлежит 100% процессорного времени. Поскольку планировщика как-бы аппаратный, то подразумеваем что сам он не потребляет (ну почти) машинное время. Ветви дерева используют машинное время узла. Если все дочерние ветви блокированы, то время, неиспользованное узлом, передаётся следующему узлу. И по аналогии наверх. Если в какой-то момент все процессы блокированы, то устойство переходит в режим низкого энергопотребления до ближайшего таймаута какого либо сообщения или до прерывания сообщения от внешнего устройства.
> Возможность прервать обработку прерывания сообщения чем-то гораздо более необходимым в текущий момент
В оригинальном L4 Pistachio эта возможность есть. Поскольку прервыания в L4 транслируются в сообщения, то текущий менее приоритетны процесс блокируется, а ожидающий прерывания процесс с более высоким приоритетом разблокируется.
Сразу оговорюсь - в текущей версии устройства, реализованном в виде прошивки для платы Марсоход-2, ничего этого ещё не реализовано. Пока что работа с внешними портами организована через циклический опрос. Это не более чем учебное устройство. Если что и делать на нём сейчас (шутки ради), то только с помощью суперцикла.
?
>Ветви дерева используют машинное время узла. Если все дочерние ветви блокированы, то время, неиспользованное узлом, передаётся следующему узлу. И по аналогии наверх.
Чуть поправлюсь. Задача в узле дерева тоже потребляет машинное время. Дочерним ветвям время отдаётся только если узел заблокирован в ожидании приёма иди передачи сообщения, или если блокируется не выработав свой квант времени.
При обычном функционировании большую часть времени все задачи заблокированы в фазе ожидания сообщения и процессор находится в состоянии низкого энергопотребления. Какое-то внешнее событие или таймаут выводит задачу из блокировки и начинается лавинообразный обмен сообщениями между задачами, которые выполняют свои действия и всё снова взаимоблокируется.
Для контроллеров это самое масло.
Я снова непони, а нельзя масштаб автоматически изменять?
Зачем это вручную делать?
Но Википедия говорит что флот в железе сложнее делать.
Со схемотехники.
И зачем это надо?
>а нельзя масштаб автоматически изменять?
Можно. Именно для этого и придумали числа с плавающей точкой.
Ключевое даже не микроядерность, а именно модульность.
Поэтому более старая BSD технически обходила linux — модульность там была чуть ли не с самого начала, в то время как в линухе это всё появилось относительно недавно.
Поэтому более старая BSD технически обходила linux — модульность там была чуть ли не с самого начала, в то время как в линухе это всё появилось относительно недавно.
щито?
Отдыхаете в шаббат значит.
Попалась книжка по разработке ОС. Книга правда закончена наполовину, но уже имеет 4000 звезд на гитхаб.
https://github.com/tuhdo/os01
https://github.com/tuhdo/os01
> уже имеет 4000 звезд
Это называется "потом посмотрю". У меня примерно столько же закладок на хабре.
Может быть. С другой стороны, не так много проектов имеют столько звезд. Если потом посмотреть, достаточно кинуть в закладки, ленивый не станет ставить звезду.
И чё там?
Да ничё.
Отчего-о мне кажется что скоро развитие остановится. у человечества нет стимулов создавать новое железо и новые операционные системы - существующие уже достаточно хороши, чтобы делать что-то новое и соответственно, в ходе "эволюции" исчезнут те, кто способны создать что-то новое.
В айти все неправильно. Везде оверинжинириг. Слои наслаиваются, производительность падает, сложность растет. Взять хотя бы сетевые стеки. Они никуда не годятся. Языков способных строить современные параллельные приложения почти нет. Базы данных тоже оверхед. Слишком много слоев. Зацикливание на старых теориях.
Всех поразило ООП головного мозга. Никто не может дать четкое определение ООП. Потому что его не существует. Если разобраться, под ООП нет никакого теоретического фундамента. Это просто выдумка, не подкрепленная никакой базой. Почему нельзя достичь ООП? Потому что нельзя достичь того, что нельзя четко определить. Была бы четкая спецификация, тогда можно было бы оценивать код ООП или нет. Спецификации такой нет и не будет. ООП стоит на мифах.
ФП имеет четкую теоретическую базу. Все концепции ФП ясны, описуемы, реализуемы. ФП основывается на математике. ООП же не основывается ни на чем, лишь на измышлениях фантазеров.
Фронтенд, это вообще нечто. Есть консорциум, есть документы, но никто их не исполняет. Кто в лес, кто по дрова. Каждый браузер делает, что хочет. Стандарты существуют ради лулзов. Всем на них плевать. Обезумевшие программисты дорвавшись до джаваскриптов, начали городить горы абстракций. За ними потянулись ноды.жс. Все это начало хайпиться. Естественно все пошли за этим, как и в случае с ООП. Вроде ослика тянущегося за морковкой, но не понимающего, что им управляет тот кто держит морковку.
Нынешняя аппаратная база довольна неплоха. Хорошо испытана. Вполне удобна и жизнеспособна. Чего не скажешь о программном слое над аппаратным обеспечением. Он изжил свое. Его время ушло. Этих концепций уже не хватает. Нельзя до бесконечности добавлять слои абстракций. Это приводит к хаосу. Нужно все переписать. Все что касается программных уровней, включая уровни процессора. Достаточно написать 2 слоя поверх аппаратуры, с учетом современных потребностей, и используя методы хорошо себя зарекомендовавшие. Этого будет достаточно для всех задач. Таким образом произойдет уплотнение всего стека программ. Объем кода уменьшится. Сложность уменьшится. Скорость и производительность увеличатся.
Как-то так все это вижу.
Айти создано, чтобы человекам проще жилось.
Хоть уровней абстракции много, но разработка становится проще и быстрее.
2 уровня абстракции - это какие?
1 уровень - ассемблер
2 уровень - любой компилируемый язык (т.е С или С++)?
Если так, то жс, джава, шарп, пеашпи, питоно находятся на третьем уровне абстракций
>включая уровни процессора
Собираешься копаться в микрокоде?
Зачем его переписывать?
Есть RISC ядро, а есть CISC инструкции, которые транслируются в RISC инструкции. Что ты хочешь там переписать?
За тебя все уже давно написали, просто скачай фреймворк и начинай работать
> Нынешняя аппаратная база довольна неплоха. Хорошо испытана. Вполне удобна и жизнеспособна
Наивный чукотский юноша. DRAM сломана, флеш сломан, DMA сломан, USB сломан дважды (на логическом и механическом уровнях), с SMP тоже не все гладко на большинстве платформ.
>Объем кода уменьшится. Сложность уменьшится.
С чего вдруг он уменьшится?
Или ты хочешь начать делать процессоры, которые будут напрямую исполнять си?
Такое будет стоить очень дорого, к сожалению.
Почитай таненбаума, там в первых главах все хорошо про это написано
>Айти создано, чтобы человекам проще жилось.
Я писал именно об этом. Айти вместо решения проблем, само превратилось в проблему.
Сейчас если не ошибаюсь, 5 программных уровней. 2-3 из них лишние. Они создают оверхед. Нужны только верхний уровень, и нижний уровень над аппаратурой. Верхний уровень сделать универсальным. Все скриптовые языки выбросить. Базы данных создающие файловую систему внутри другой файловой системы, которая внутри третьей файловой системы, - выбросить.
На нижнем программном слое сделать универсальное апи, позволяющее реализовать языки с любыми концепциями, с уклоном на параллельность и неизменяемость в том числе.
Сетевые протоколы все выбросить. Текстовые протоколы запретить. 7 слоев не нужны. Каждый слой добавляет свой оверхед и по объему данных и по скорости. Верхние слои протоколов сделать более компактными и универсальными. ХТТП это оскорбление программистов. В 21 веке использовать настолько нежизнеспособный протокол это преступление.
С учетом появления 12-18 ядерных домашних машин, новые программный стек уменьшил бы накладные расходы, размер кодовых баз, увеличил бы производительность и удобство. Если нижний программный слой сделать универсальным, с возможностью расширения, то легко будет его пересаживать на любую аппаратную архитектуру, на случай появления новых открытий.
И как тогда Майкрософт будет своё говно продавать?
>С чего вдруг он уменьшится?
Легаси скопилось очень много. И в процессорном уровне, и в вышележащих. Уровень приложений уже сам состоит из нескольких уровней. Если все это выпилить, то уже производительность увеличится, и объем кода уменьшится.
И что?
Будешь писать браузер на ассемблере?
Сайты тоже на ассемблере?
Легаси скопилось уже на высоких уровнях и ОС, больше его нигде нет.
>Если нижний программный слой сделать универсальным
Нельзя сделать.
>Айти вместо решения проблем, само превратилось в проблему.
Это тебе на дваче так сказали. В действительности все спокойно делают сайты для себя, утилиты, чтобы облегчить себе жизнь.
А вот если все это писать на ассемблере или на си, то можно действительно превратить всю разработку в инфернальный пиздец с утечками памяти и прочими низкоуровневыми прелестями.
>5 программных уровней
Ну и какие же это уровни?
Нет. Сократить прослойку между аппаратной частью и высокоуровневыми языками. Легаси есть везде, достаточно отрыть мануалы интела чтобы понять это. Половина функционала уже не используется, либо стоит костылем под другим функционалом. Более высокоуровневые апи опустить на более низкий уровень, то есть уплотнить.
Можно. Все что можно реализовать аппаратно, можно реализовать и программно.
Сайтики лежать на множестве уровней абстракций. Сплошной оверхед. Сетевые протоколы устарели. Из-за всего этого невозможно открыть тяжелый сайт в браузере, даже на мощных машинах подтормаживает. Си не нужен. Есть Раст, Хаскелл, Окамл, Го. Процедурное программирование не нужно. ООП не нужно.
2 уровня абстракций на процессоре, уровень ассемблера, уровень ОС, прикладной уровень (в котором появляются свои уровни) - вот и 5 уровней. Если учитывать виртуальные машины, то 6 уровней.
Получается компилятор в компиляторе в компиляторе, ос в ос в ос, файловая система в файловой системе в файловой системе, сетевой протокол в сетевом протоколе в сетевом протоколе. Рекурсия короче. Это все не нужно. Слишком много лишних слоев.
>Сократить прослойку между аппаратной частью и высокоуровневыми языками.
Это повысит стоимость процессоров в сотни и тысячи раз.
>Сайтики лежать на множестве уровней абстракций.
В целом так и есть, но ниже прикладного уровня их не опустишь.
>Сетевые протоколы устарели
С чего вдруг? Что существенно нового произошло за последние 20-30, что нужно срочно менять сетевые протоколы?
Начать нужно с верхнего уровня. Разработать протоколы передачи. Удостовериться что они хорошо решают задачи. Разработать концепции хранения данных. Снова удостовериться в их удобстве. Разработать концепции удобных высокоуровневых языков. После построения удобного для использования верхнего уровня. Можно постепенно переработать все нижние уровни.
Процессоры оставить как есть. Сократить, упростить, улучшить срединные апи. Между машиной и высокоуровневыми абстракциями.
>С чего вдруг? Что существенно нового произошло за последние 20-30, что нужно срочно менять сетевые протоколы?
Множественная перепаковка с добавлением лишней информации. Слишком много уровней. Текстовые протоколы не решают задач. Сократить до 3-4 слоев протоколов. Важно чтобы прикладные протоколы стали соответствовать современным задачам. Веб сейчас борется с проблемами передачи данных. Не было бы их, сайтики да и любые сложные веб-приложения, создавались бы легко. Не было бы такого потребления ресурсов. Основная работа в сетях, это постоянная перепаковка и увеличение данных. От этого веб делать сложно и муторно.
>Сократить, упростить, улучшить срединные апи. Между машиной и высокоуровневыми абстракциями.
Я так понимаю это CISC инструкции? Выше идут С/С++, на которых уже написаны различные VM. Что конкретно ты хочешь упрощать?
И опять начали думать о чем-то вроде FORTH, forth-процессоров и контакатенативных языков программирования вообще. Поздравляю.
>контакатенативных
Конкатенативных, конечно же. К слову, они в идеях весьма близки к функциональным, есть даже различные понемногу теории описывающие эти языки, но при этом всё-таки конкатенативные языки программирования ближе к реальности, что ли. Я, впрочем,
оообще больше люблю комбинаторную логику чем лямбда-исчисление, но то такое, ведь можно и конвертировать туда-сюда и я начал говорить о совсем странных вещах.
Объединить уровни микроархитектуры и набора команд. Лишнее все выбросить. Нет необходимости надстраивать низкоуровневое апи на другое низкоуровневое апи, это оверинжиниринг.
> 5 программных уровней
Ниразбирающийся школьник детектед.
> Все скриптовые языки выбросить
Хитрый план, чтобы убить айти нахуй?
> Базы данных
Проиграно.
> Сетевые протоколы все выбросить
Разбудил кошку.
> 7 слоев не нужны
Их нет. Сетевая модель OSI - абстрактная хуйня в вакууме, к реальности отношения не имеет. Если начать формализовывать, окажется, что слоев много больше.
> ХТТП это оскорбление программистов
Ты просто никогда не пытался отлаживать софт, использующий бинарные протоколы. А HTTP используется очень часто, и если избавиться от абстракций, отлаживать придется каждое использующее его приложение.
> Легаси есть везде
Конечно. Никому не нужна новая машина с красивой реализацией, если тебе придется выкладывать за нее деньги снова и снова. Только ради того, чтобы лично ты был счастлив из-за отсутствия легаси.
> Объединить уровни микроархитектуры и набора команд
Наслаждайся греющимся медленным говном (в разы более медленным, если мы подразумеваем x86) с кучей багов в реализации (в среднем несколько в год), которые никак не исправить - только выкидывать камень и покупать новый.
>ХТТП это оскорбление программистов. В 21 веке использовать настолько нежизнеспособный протокол это преступление.
Внезапно соглашусь.
>Базы данных создающие файловую систему внутри другой файловой системы, которая внутри третьей файловой системы, - выбросить.
Есть проблема такая.
Но это скорее проблема плохого дизайн, с одной тсороны.
И концептуальная сдругой.
Концептуальная проблема в том, что нельзя сделать универсальную базу данных.
У разных задач разные потребности.
Плохой дизайн, это когда некая база данных требует не блочного устройства, а обязательно файловой системы.
Да и вообще, файловая система - странная концепция.
Все как файл - за это нужно расстреливать.
>7 слоев не нужны. Каждый слой добавляет свой оверхед и по объему данных и по скорости.
Это абстракции же.
Они нужны.
Без них нет модульности.
Там же есть чисто аппаратные слои, а есть уже программные.
С другой стороны, кто-то где-то использует IP без TCP\UDP?
А ARP без IP?
Думаю тут есть некий простор для редизайна.
Но экономически\политически это практически невозможно.
>Сайтики лежать на множестве уровней абстракций. Сплошной оверхед.
То, во что сейчас превратился веб, и браузеры - это какой-то ПОЗОР.
Кому-то в голову пришла гениальная идея, писать приложения на языке верстки документов.
А потом под эту тему навыпускали новых апи и превратили бравзеры в аналог флешплеера.
И нужно заметить, флешплерр справлялся с задай гораздо лучше, он под это создавался.
А вот HTML\js\css\9999фреймворков - блядь, пидоры.
>Это повысит стоимость процессоров в сотни и тысячи раз.
Это что-то уровня
>человеческий глаз не видит больше 25fps и 16бит цветов.
>Выше идут С/С++, на которых уже написаны различные VM. Что конкретно ты хочешь упрощать?
Не знаю что хочет тот анон.
Но я предлагаю упразднять С/С++
С - как глупую шутку по созданию брейнфака переросшую в трагедию.
С++ как трагедию выросшую из слишком далеко зашедшей шутки.
Каким же надо быть ебанутым чтобы обсуждать эту помойку
>чтобы убить айти нахуй?
Давно пора.
В биореактор креаклов.
>Ты просто никогда не пытался отлаживать софт, использующий бинарные протоколы. А HTTP используется очень часто
Ты что, ебанутый.
Это HTTP то просто отлаживать?
С миллионом реализаций у каждого васяна\васяноязыка своя либа со своими заебками.
Куки блядь, гет сет пост, что несут, поехавшие блядь, URI КОДИРОВКА Windows1251
Да за это говно расстреливать нужно.
Особенно меня приводят в щенячий восторг вещи, которые в принципе никогда никому в голову не могло бы прийти реализовывать через http, но которые есть. Например WebDav.
>Конечно. Никому не нужна новая машина с красивой реализацией, если тебе придется выкладывать за нее деньги снова и снова. Только ради того, чтобы лично ты был счастлив из-за отсутствия легаси.
Как насчет новая машина с старой галимой реализацией и заюбагованным софтом за которую тебе приходится выкладывать деньги снова и снова.
I N T E L
N
T
E
L
А андроид смартфончика не хочешь?
Что, через полгода вздулась батарея и разорвало склеенный корпус?
Как насчет еще одного смартфончика?
Рекламу показывает? Вирус украл деньги со счета?
Камера закрывается?
Выключился и не включается?
Нет времени объяснять, срочно покупай новый свежий смартфон, который делает все то-же самое.
> Ты что, ебанутый.
> Это HTTP то просто отлаживать?
Да, HTTP очень просто отлаживать. Любой монитор трафика показывает весь обмен, любой TCP-клиент на любом языке программирования позволяет отправить запрос тремя строчками кода даже без либ.
> URI КОДИРОВКА Windows1251
Ну так сходи настрой сервер, чтобы была UTF-8, как у людей. Это не проблема протокола.
> WebDav
Так я с этим и не спорю. Использовать HTTP в качестве транспорта для более высокого уровня нужно более обдуманно. Алсо, для файлов существует текстовый же FTP, он норм.
> I N T E L
Ты что-то путаешь. Я выкладываю деньги за повышение быстродействия примерно раз в пять-десять лет. Могу не выкладывать, легаси как раз и обеспечивает мне как работоспособность привычного софта на новом железе, так и наоборот работоспособность нового софта на старом железе. Ну если, конечно, некоторые компании на букву M не принимают гениальное решение эту самую десятилетиями поддерживаемую обратную совместимость сломать. А потом недоумевают, чоэта люди остаются сидеть на XP и денег не плотют.
> заюбагованным софтом
Софт под новое железо по определению будет более забагованным, чем софт под старое, который вылизывают годами, где уже давно известны все проблемы и придуманы костыли для их решения.
> Рекламу показывает? Вирус украл деньги со счета?
Ты это к чему вообще? Что там виновато, слои абсракций или легаси? Или ты про
> Никому не нужна новая машина с красивой реализацией
так красивую реализацию никто не покупает. Покупают попугаев в камере, большую батарейку, память, новый дизайн и отсутствие царапин на корпусе. Похуй, какие там костыли внутри, лишь бы оно работало.
>так красивую реализацию никто не покупает. Покупают попугаев в камере, большую батарейку, память, новый дизайн и отсутствие царапин на корпусе. Похуй, какие там костыли внутри, лишь бы оно работало.
>Ты это к чему вообще?
Это я к тому, что утверждение о том, что потребитель стремится к оптимизации соотношения цены\качества - до страшного тупой и нелепый миф.
Будут выкладывать деньги за то, за что скажут по телевизору в свитере и фейсбуке.
А рассуждения о легаси, в нынешнем положении, когда на земле сраный миллиард программистов, вообще ниочем.
Особенно в ситуации, когда реально полезного софта единицы. Да еще и уровень совместимости можно напердолить.
Невозможно создать ничего хорошего постоянно оглядываясь назад и следуя за толпой.
>я предлагаю упразднять С
А что упрощать в сишке?
Она и так очень простая.
А вот насчет С++ соглашусь.
>Го
>Процедурное программирование не нужно
>Окамл
>ООП не нужно
Го дебил во всей красе, ничего у него не нужно.
>можно действительно превратить всю разработку в инфернальный пиздец с утечками памяти и прочими низкоуровневыми прелестями
Смотрите, скриптодевочка пугается байтиков. 80-е давно прошли, с современными тулзами, сишка простой в работе и безопасный язык. Хотя смузи-кодерки будут продолжать попытки запихнуть nodejs в микроконтроллер.
Предложи что-то лучше файловой концепции.
>язык со слабой типизацией
>простой в работе и безопасный
>А что упрощать в сишке?
>Она и так очень простая.
упразднять
не
упрощать
>сишка простой в работе
Никакими тулзами нельзя исправить весь этот позор.
>Предложи что-то лучше файловой концепции.
Для чего именно предложить?
Какую задачу то решаем?
>Почему всюду пихают эту сраную плавающую запятую, почему не используют с фиксированной точностью?
Во первых, потому что она уже в есть.
Во вторых, потому что заменить плавающую точку фиксированной сложно, а в некоторых случаях невозможно.
В третьих... таки во многих случаях можно отказать от вычислений с плавающей точкой, но не все об этом догадываются.
Ну и как бы спорить какой язык лучше, это в наше время потеряло смысл. Для системного программирования пойдёт любой компилятор, умеющий генерировать объектные файлы. Язык значения не имеет. Если компилятор не умееет генерировать обхектные файлы, то он не подходит для системного программирования.
А микроядро даёт вам возможность компоновать систему из модулей. Это не единственная возможность микроядра и не каждого микроядра, но это одна из самых вкусных возможностей.
А микроядро даёт вам возможность компоновать систему из модулей. Это не единственная возможность микроядра и не каждого микроядра, но это одна из самых вкусных возможностей.
Что за язык на пикче?
Язык описания аппаратуры - Верилог (Verilog).
Клёвая штука. Но программисту будет непривычная.
Что этой штукой можно делать? Кроме как засунуть себе в анус.
'Ну например вот тут посмотри - https://marsohod.org/projects
Лучше я объяснить не могу. Если совсем коротко, то из этого языка синтезируется электронная схема. На каких то задачах можно в клочь порвать программное решение даже при более низкой частоте. Но не на всех задачах.
Но ведь и из C можно синтезировать?
Можно. Но где ты такую ПЛИС найдёшь? В этом случае количество использованных логических элементов возрастает на порядки. Тогда тебе придётся покупать не любительскую девборду, а потратить несколько (возможно несколько десятков) тысяч долларов на старшую модель девборды. Причём, делая то же самое на HDL, ты поместишь свой проект в любительскую девборду.
Ну и конечно же некоторые вещи вообще не могут быть описаны на Си. Вот только примера такого у меня сейчас нет, а думать или искать лениво.
Для тех, что решает файловая концепция в том числе. Да и вообще предложи лучше.
На самом деле достаточно, смотрел вчера выборку по HH. Если, конечно, мы не с PHP сравниваем.
Это беспредметный разговор.
Я говорил о файловой системе, ты начал о какой-то файловой концепции.
Я тебе говорю - давай конкретные задачи, ты опять предлагаешь неопределенный беспредметный концепт "Для тех, что решает файловая концепция".
Хорош пургу нести.
Давай четкое определение "файловой концепции" и перечь проблем ею решаемых.
Тогда будет о чем говорить вообще.
>файловая система - странная концепция
Чой-та вы не то обсуждаете.
Файл вполне себе нормальная абстракция, которая покрываешь даже устройства.
C:> copy mytext.txt prn:
$ cp mylog.txt /dev/ttyS0
Что не так с файлами?
Древовидная структура весьма удобна.
> copy mytext.txt prn:
> Файл вполне себе нормальная абстракция
Это нормально работало, пока принтер был печатной машинкой, которая выбивала указанный символ и еще парсила полтора спецсимвола. А сейчас у моего принтера два лотка с бумагой и стопицот режимов. Покажи-ка мне, как выбрать нужный лоток, 4 отпечатка на одном A4, 40% экономию тонера и автоматическую печать на двух сторонах, и все это с помощью вот этой твоей "нормальной абсракции". Внезапно окажется, что нужен не один файл, а целая папка. Внезапно окажется, что нужно запоминать какой-нибудь синтаксис, разный для разных устройств. Внезапно окажется, что сигнализировать о заканчивающейся бумаге принтер программе не сможет.
Заодно расскажи, вот у меня есть mp3, в mp3 музончик и метаданные, а еще в метаданных обложка в жипеге, а в том жипеге картиночка, превьюшка и метаданные. Но ведь mp3 - это жи файл, а ты говоришь, что файлы весьма удобны? Так как мне вытащить GPS-координаты из того жипега?
>Файл вполне себе нормальная абстракция, которая покрываешь даже устройства.
Есть мнение, что обмазывать ей даже устройства небо и Аллаха - не стоит.
>Древовидная структура весьма удобна
Удобна.
Но часто недостаточна и оверюзанна(одновременно).
/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\
И попробуй в этом всем что-то найди.
И это далеко не худшие примеры.
Далеко не все данные хорошо хранить в древовидной БД.
Вот всякие конфиги - хорошо, но их зачем-то наоборот в фалы пихают в виде списков.
>Покажи-ка мне, как выбрать нужный лоток, 4 отпечатка на одном A4, 40% экономию тонера и автоматическую печать на двух сторонах, и все это с помощью вот этой твоей "нормальной абсракции".
Для это в стандарте POSIX есть системный вызов IOCTL с помощью которого можно управлять устройство. И, внезапно, в качестве одного из параметров используется дескриптор открытого устройства.
> Заодно расскажи, вот у меня есть mp3, в mp3 музончик и метаданные, а еще в метаданных обложка в жипеге, а в том жипеге картиночка, превьюшка и метаданные. Но ведь mp3 - это жи файл, а ты говоришь, что файлы весьма удобны?
А чем тебе не удобно что всё одном месте хранится? Вот то, что ты написал, это и есть удобство. А картиночку из внедрённого jpeg тебе покажет твоя любимая Desktop Environment
> Так как мне вытащить GPS-координаты из того жипега?
Подозреваю что нечто вроде клика правой клавишей мыши на иконке, Меню "Свойства" подменю "Подробно".
Или тебе программно нужно? Ну так ищи соответствующую либу, линкуй к своему проекту и вуаля - то, что тебе нужно.
>Далеко не все данные хорошо хранить в древовидной БД.
Я знал что будет такой аргумент. А что ты предлаешь взамен? Уж не вот это ли - https://en.wikipedia.org/wiki/WinFS ?
> Для это в стандарте POSIX есть системный вызов IOCTL с помощью которого можно управлять устройство.
Очевидно, что если у нас есть вызовы, то мы можем сделать и вызов, с помощью которого можно печатать. И тогда наличие PRN: совершенно избыточно, и даже вредно.
> Подозреваю что нечто вроде клика правой клавишей мыши
Ты не понял. Я говорю о том, что фс вредна, потому что, как бы ты ни упирался, но каждый файловый формат рано или поздно рекурсивно скатывается до собственной фс внутри него. Поэтому нужно осознать, отбросить древние привычки и взять БД сразу, а фс выкинуть нахуй. И тогда я, наконец, смогу узнать GPS-координаты из обложки альбома внутри аудиозаписи. И мне не нужно будет городить парсер для каждого формата лишь потому, что внезапно обложка лежит не в .mp3, а в .ogg.
Мойкрософт знает толк в технологиях.
Ms Bob только чего стоит.
https://www.youtube.com/watch?v=DtaduB1qRjk
Увы, многое похоронил менеджмент, а многое пользователи уточки.
Идея у МС в целом неплохая, но полностью отказываться от каталогизации не стоит ящитаю.
Подробно описывать свои идеи ящитаю бессмысленно в формате анонимногокартинкофорума.
>И тогда наличие PRN: совершенно избыточно, и даже вредно.
Я так не думаю. С помощью абстракции файловой системы можно безболезненно добавлять новы устройства и даже совершенно новые, которых доселе не было, при этом не меняя саму операционную систему. Тот же самый ioctl позволит управлять устройством. Всё, что понадобится в таком случае это драйвер и заголовочный файл с константами, определяющими операции над устройством.
И тебе нечего на это возразить. :)
> Поэтому нужно осознать, отбросить древние привычки и взять БД сразу, а фс выкинуть нахуй.
И вот ты обращаешься к файл не используя Full Path, а используя некий запрос, наподобие SQL. И вот, внимание, запрос выдал (условно) три файла. Допустим, ты открываешь документ - что делать сразу с тремя файлами? Но это ещё половина беды - можно представить ситуацию с тремя открытыми документами. А сохранять в какой из трёх будешь? Создавать третью четвёртую версию файла? А не боишься при этом погрязнуть в версиях, впоследствии тратя большую часть времени на формирование всёё более хитрых запросов?
При этом документ или фото это половина беды, их действительно можно открыть сразу несколько. А что если это какой-то скрипт, который работает без участия пользователя? Как ему быть когда под один запрос попадает несколько файлов? Какой из них открывать? Пользователя рядом нет, подсказать некому.
Вот когда ответишь на эти вопросы, тогда можно всерьёз обсуждать ОС с БД вместо файловой системы.
> обсуждать ОС с БД вместо файловой системы
Файловая система и есть БД.
>С помощью абстракции файловой системы можно безболезненно добавлять новы устройства и даже совершенно новые, которых доселе не было, при этом не меняя саму операционную систему.
Что ты несешь, болезный.
>Всё, что понадобится в таком случае это драйвер
Всего-то.
>заголовочный файл с константами, определяющими операции над устройством.
Да, на это действительно сложно возразить.
> С помощью абстракции файловой системы можно безболезненно добавлять новы устройства
У меня от тебя /dev/enp2s0. Либо у нас обычная нумерация устройств, начиная с первого воткнутого, и тогда вебка оказывается каждый раз названа по-новому, либо ты их обзываешь в зависимости от физического расположения, и... юзеру похуй на твои причуды, он хочет, чтобы руль продолжал рулить в гоночках вне зависимости от того, воткнут ли он в USB-порт ноута, или в хаб, воткнутый в хаб, воткнутый в монитор, воткнутый в USB-порт ноута.
> совершенно новые, которых доселе не было
Нахуй мне в ОС устройство "спиннер", если у меня нет ни софта, ни дров, чтобы его крутить? А если у меня есть софт и дрова, у меня уже есть либа с API, и никакие ioctl мне не нужны.
> что делать сразу с тремя файлами
Выберу нужный, используя метаданные. Например, свежеотредактированный. Если это какой-то не пользовательский файл (например, какие-то входные данные от какой-то программы), то у него, скорее всего, есть GUID, которым и пользуется программа, которой он принадлежит.
> А не боишься при этом погрязнуть в версиях
Я всегда могу удалить самые старые, могу откатиться на нужный.
> скрипт
Зависит от того, что делает скрипт. Он обработает либо все, либо самый свежий, либо скрипт содержит ошибку. Встречный вопрос: что сделает скрипт, если указанный ему файл - на самом деле имя директории?
Как теперь развидеть ЭТО?!!!
Сорок минут жизни коту под хвост.
Спасибо, Майкрософт, что ты похоронила Боба, но нет тебе прощения, за то что создала это...
И придётся тебя ещё с собой таскать DLL для динамической линковки или .so/.lib для статичкской. Только потому, что тебе не нравится что устройства отображаются в /dev/
>Встречный вопрос: что сделает скрипт, если указанный ему файл - на самом деле имя директории?
Не сможет его открыть и завершится с ошибкой.
И это нормально.
> Я всегда могу удалить самые старые, могу откатиться на нужный.
А пользователи? Они начнут удалять старые версии только когда закончится место на диске. а случится это при таком подходе довольно быстро.
> GUID, которым и пользуется программа
Ну да, GUID это решение. Только отлаживать программу с этой бедой будет совсем не масло. Придётся привыкать или как-то извращаться.
Кстати, такую файловую систему, о которой ты толкуешь, несложно реализовать поверх NTFS. Внутри неё всё для этого есть.
>но нет тебе прощения, за то что создала это...
Концепция очень годная на самом деле.
>И придётся тебя ещё с собой таскать DLL для динамической линковки или .so/.lib для статичкской. Только потому, что тебе не нравится что устройства отображаются в /dev/
Ты поехавший и не лечишься.
Или просто сисандмин может?
Ну с чего ты взял, что любой другой способ будет минимум не хуже?
Почему обязательно таскать длл? Что ты несешь?
Хватит уже фантазировать.
Даже полное отсутствие иерархической базы данных в системе никак несвязанно с наличием удобного способа централизованно управлять оборудованием.
Или как-то связанно, поехавший?
>А пользователи? Они начнут удалять старые версии только когда закончится место на диске. а случится это при таком подходе довольно быстро.
В windows такой подход включен по умолчанию.
Без всяких экзотических концепций, с обычной ФС.
И ничего, пользователи не жалуются.
> Они начнут удалять старые версии только когда закончится место на диске. И в винде, и в макос давно уже старые версии документов сохраняются. И ос преспокойно рулит всем этим самостоятельно, но пользователь, если он разбирается, может этот процесс контролировать.
> поверх NTFS
Там выше полтреда понаписано о вреде ненужных оберток.
Алсо, я скажу больше: о разделении на оперативную и долговременную память ни пользователю, ни прикладному софту в идеале знать не нужно. Как и "сохранять" документы в принципе нахуй не нужно, пока не потребуется их куда-либо передать. Для примера (уже работающего, причем годами) правильного поведения можно посмотреть на hot exit в Sublime Text, где можно создать документ, написать что-нибудь, закрыть редактор, запустить его в другой ОС (разумеется, профиль общий), и в документе даже курсор на том же месте останется. Переключиться на другой воркспейс, что-то сделать, вернуться обратно, а курсор будет по прежнему там, где его оставили (ну и undo, история поиска и т. п., конечно же, тоже сохраняются).
>В windows такой подход включен по умолчанию.
Корзина, что-ли? Я не уверен что это не сделано надстройкой сверху.
Что-то мне подсказывает что https://msdn.microsoft.com/en-us/library/windows/desktop/aa363915(v=vs.85).aspx не помещает файл в корзину, а таки удаляет его. Или ты что-то другое имеешь в виду?
Погугли macOS time machine.
>Ты поехавший и не лечишься.
Сынок, ты язык-то свой попридержи, малыш.
> Почему обязательно таскать длл?
Или DLL и статическую либу.
Иначе у тебя не будет способа обратиться к драйверу, если это нестандартное устройство.
>macOS time machine.
Надстройка над ОС. К ядру никакого отношения не имеет. С этим ты согласишься.
А вот то, что эта хрень сидит в памяти и засирает диск, тут ты, конечно, со мной не согласишься.
Дмитрий Завалишин? Собственной персоной в треде?
>Корзина, что-ли? Я не уверен что это не сделано надстройкой сверху.
Да какая в жопу разница в данном конкретном обсуждении чем оно там сделано.
Главное сделано, и пользователям нравится.
И это вообще логичный и правильный подход.
>Сынок, ты язык-то свой попридержи, малыш.
Ты там упоротый что ли?
Как это какая разница? Это как раз таки большая разница. Отказаться в от файловой системы в пользу базы данных, или городить надстройку над уже существующей файловой системой.
Кстати, чем GUID в таком случае лучше имени файла?
>Как это какая разница?
Речь шла о концепции сохранения удаленных файлов.
А не о какой-то конкретной технологии.
То что ты пишешь, никак несвязанно с постами на которые ты отвечаешь, и с твоими же предыдущими постами.
>Кстати, чем GUID в таком случае лучше имени файла?
Ты меня с кем-то путаешь вообще.
> Надстройка над ОС
Ну так там и фс традиционная, а не БД.
> засирает диск
Один терабайт стоит полста баксов. С размерами документов порядка 1 МБ можно засирать винт очень долго.
Кто такой? Чем знаменит?
> Кстати, чем GUID в таком случае лучше имени файла?
GUID - способ обратиться к конкретной, уникальной сущности (практически primary key). Вместо GUID может быть SHA-2 какой-нибудь. Или нет. Например, у моей программы есть логотип. Мне абсолютно похуй, где он лежит, я хочу один конкретный (мой) логотип. Что сделает система хранения ресурсов в ответ на запрос по GUID, мне в общем-то похуй: прочитает ли с винта, найдет ли в бэкапе, сольет с компа соседа или официального сайта программы - у меня есть GUID, я хочу картинку. Но в большинстве случаев я хочу, например, фоточку, которую я сделал в августе прошлого года. Мне опять же похуй, где она лежит, лишь бы ОС мне выдала что-то подобное, а я уж сам решу, которая из них мне нужна конкретно.
> Дмитрий Завалишин
Погуглил. Ой бляяя. Нет, я из другой секты.
>Один терабайт стоит полста баксов. С размерами документов порядка 1 МБ можно засирать винт очень долго.
Не знаю. Я люблю порядок. Ну и файлы разные бывают. Нередко встречаются сгенерированные docx или xlsx на 300 Мб.
Ладно. Тебе почти удалось меня убедить. Осталось ещё несколько вопросов и вот один из них - кто напишет эту файловую систему? Куда её приткнуть я найду, но кто реализовывать будет? Или ты описываешь то, чего бы хотелось тебе получить от файловой системы, но реализовывает её пусть кто-то другой?
> кто напишет эту файловую систему
У Microsoft уже было несколько попыток, но все они плохо сочетаются с привычками пользователей (даже поиском-то в винде далеко не каждый пользуется) на самом деле, даже итт разговор про ФС и БД начал не я, и хотя я понимаю, что в этом будущее, вряд ли перекатился бы на такую среду в числе первых. Возможно, поможет более широкое распространение Cortana/Siri/КогоТамЗабыл. Возможно, распространение начнется со смартфонов - там и так "настоящая" фс достаточно скрыта от простых глаз, и нужно сделать всего лишь шаг.
А что до меня, так, конечно же, я такой проект в одиночку не осилю ни реализовать, ни продвинуть. А писать "в стол" смысла нет - тут весь тред такой, только чтобы помечтать.
Хочу реализовать свою библиотеку потоков с диспетчером, атомарными операциями и шлюхами под STM32. Что почитать об этом?
>А что до меня, так, конечно же, я такой проект в одиночку не осилю ни реализовать, ни продвинуть.
Ну если горишь идеей, то можно попытаться организовать консорциум и спроектировать и релизнуть спецификацию на это дело.
Приблизительно так появился Bluetooth.
Не, неправильный подход. Нужно захотеть реализовать ПОСЛЕ того как почитаешь об этом. Тогда шанс есть. Обычно после прочтения приходит понимание что лучше взять готовое.
Небольшой бамп треду.
; --- Функция вывода строки
; Вход: 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
; --- Функция вывода строки
; Вход: 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
А теперь то же самое, но с какой-нибудь конвенцией вызова. А то у тебя аргументы и возвращаемые значения каждый раз в новом регистре. Это допустимо для внутренних функций (которые генерит компилятор из твоего кода), но не для библиотечных.
Как так получилось что стандартом стала именно существующая сложная организация памяти? Почему не единое адресное пространство? В этом направлении вообще ведутся разработки? Ибо слишком сложно всё современное выглядит, будто костыли. Все эти MMU, вот это всё.
> Почему не единое адресное пространство
Потому что тогда написанные на ассемблере приложения смогут поднасрать другим. Чтобы они не смогли поднасрать другим, тебе придется либо запретить нативные приложения (т.е., писать на managed языке, который будет сам генерить машинный код, проверять указатели, тормозить), либо городить какие-нибудь сегментные регистры (спасибо, в 16-битном x86-коде накушались), в которые нельзя записать "чужой" сегмент из юзермода. Виртуальное адресное пространство гораздо проще для понимания, проще писать код, проще отлаживать.
> Ибо слишком сложно всё современное выглядит
Все там просто выглядит, пока не доходит до синхронизации кэшей, TLB и прочих предвыборок.
- И неясно прохожим в этот день раз в год в стране происходят чудеса
Приходит домой и мужу говорит:
- Она у тебя рыбачит?
А конвенция вызова очень простая.
На выходе R0 это всегда значение функции.
Регистры R1-R7 могут использоваться как аргументы функций.
Вызываемая функция должна позаботиться чтобы регистры R8-R15 не изменились после выхода из функции.
В случае объектно-ориентированного кода при вызове функции в R0 указатель this.
Вот такая вот конвенция.
Ах да, вышеприведённый код не соответсвует конвнции. Функция вывода строки портит регистр R12.
Присоединяюсь к вопросу.
>Потому что тогда написанные на ассемблере приложения смогут поднасрать другим.
Это понятно. Понятно также почему тут помогает MMU.
Но почему для этого может не хватать простого MPU как в Cortex-M3? Если требуется, адреса (например в командах перехода) при этом можно пересчитывать при загрузке кода.
> либо запретить нативные приложения (т.е., писать на managed языке, который будет сам генерить машинный код, проверять указатели, тормозить)
Почему еще никто так не делает?
Одни профиты.
Да и есть же всякие технологии виртуализации. Ептв.
>Все там просто выглядит
Я не оче в курсе, но насколько я слышал, конвертация виртуального адреса в реальный происходит с помощью кода в ядре ОС.
О почему бы не делать это аппаратно?
>пока не доходит до синхронизации кэшей, TLB и прочих предвыборок.
Ага.
>Но почему для этого может не хватать простого MPU как в Cortex-M3?
Потому что придёт фрагментация и будет нехоршо. Может понадобиться длинный кусок непрерывной памяти, а в наличии будут лишь "кусочки". Страничная память решает эту проблему - операционная система мапит свободные страницы в непрерывую область виртуальной памяти, а прикладная программа при этом "не задумывается" о таких "мелочах".
Вторая причина это своп. Неиспользуемую но выделеную память удобно выгружать на диск постранично.
Вот для этого и нужен MMU.
>Я не оче в курсе, но насколько я слышал, конвертация виртуального адреса в реальный происходит с помощью кода в ядре ОС.
>О почему бы не делать это аппаратно?
Это аппаратно и делается. Операционная система лишь управляет этим процессом.
Так, окей.
А раз оно так секурно, каким образом постоянно приложения ебут друг друга получая доступ к этой блядь защищенной памяти?
Ну то есть я не пони, если честно.
Каков конкретный юзеркейс то?
В конце концов, быть может секурность можно и по другому как-то реализовывать.
Что мешает делать блоки памяти без виртуальной адресации?
Приложения изолированы друг от друга адресными пространствами.
Например, виртуальный адрес 0x80000 (число взято на шару) может использоваться всеми программами (процессами) одновременно, операционная система каждому процессу в этот виртуальный адрес отобразит разные физические страницы. Чтобы приложения пересеклись в памяти, это невозможно. Наоборот, используется так называемая "разделяемая память" (shared memory), чтобы приложения могли использовать общую память. Но shared memory это достаточно сложно и держу пари что мало кто из прогаммистов ей пользовался или даже знает о её существовании :)
> Что мешает делать блоки памяти без виртуальной адресации?
Совместимость. Спрятать вот эту вот фргаменттацию от программиста можно с помощью managed (как это по-русски?) языков, типа Java или C#, которые прячут от программиста физическую реализацию памяти достаточно далеко. В случае же хотя бы простого Си, когда используются простые указатели, при интенсивном использовании malloc/free фрагментация наступит довольно быстро. При этом любая традиционная программа, написанная без учёта фрагментации памяти, довольны быстро ругнётся ошибкой "Out of memory", несмотря на то,что общий объём всех неиспользованных дырок в памяти будет достаточен.
Это делается аппаратно
Архитектура без железа ничто. Иван Годард считает что регистры нинужны - слишком дорого обходятся на железной стороне. Зацени его архитектуру mill
> 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! Не так уж ты и крут, Бэтмэн. :)
>Ага. Ага! Stalls! Не так уж ты и крут, Бэтмэн. :)
Ты че ТЫ ЧЕ!?
>> If the bandwidth of the spiller is exceeded, the mill stalls, waiting for the belt to become consistent.
>
>Ага. Ага! Stalls! Не так уж ты и крут, Бэтмэн. :)
>
Это типа протухания кэша же? то есть, редкое событие
Крутой дед. Миядзаки от кодинга.
А функциональные языки программирования не прячут? Ну, я не говорю о сборщике мусора, а о, например, линейных типах. https://en.wikipedia.org/wiki/Substructural_type_system ну тип вот это всё. Его нельзя реализовать аппаратно типа? А совместимость... ну епт, в прошлом столетии же было много проектов которые обрывали совместимость и делали полностью новые компьютеры.
>А функциональные языки программирования не прячут?
Прячут.
> Его нельзя реализовать аппаратно типа?
Есть вероятность что можно. Но не факт, что будет быстрее чем сейчас.
> в прошлом столетии же было много проектов которые обрывали совместимость и делали полностью новые компьютеры.
И где они теперь?
>И где они теперь?
IBM-PC например цветет и пахнет.
А что?
С чего ты вообще решил, что какие либо тех характеристики хоть как-то влияют на распространение и долговечность тех или иных тех решений?
>Крутой дед. Миядзаки от кодинга.
Как я понял, у них там анально проприетарная архитектура которую они уже жестко лицензировали и запатентовали(хотя еще нихуя не сделали рабочего)
Так что это не миядзаки, а Пидарашка от кодинга.
Которая бизнес понимает как - срубить бабло и постричь лохов.
Процессор еще не сделали, но уже придумали как его будут всем продавать.
>IBM-PC например цветет и пахнет.
Чой-та ты гонишь. Возьми MS-DOS и какой-нибудь Нортон Коммандер и он запустится на самом современном проце от Intel или AMD.
>Как я понял, у них там анально проприетарная архитектура которую они уже жестко лицензировали и запатентовали(хотя еще нихуя не сделали рабочего)
>
Они это сделали потому что в них влошились инвесторы, а в конечном счёте же нужно сделать прототипы в кремнии (и не проебать интелу или китайцам)
Что ты несёш?
1 незапустится.
2.ibm-pc ни с чем несовместимое говно, на момент выхода ничего кроме страной дос неумеющее.
С чем оно там было совместимо, а ебана?
> незапустится.
И шестой дос, и нортон вполне запускаются на ноуте 2017 года выпуска.
Ты не понимаешь сути. Любые кардинальные изменения обречены на провал, потому что существуют гигабайты исходников, которые хотят классическую архитектуру системы (в том числе и сырые указатели). Если ты делаешь систему, которая этого не умеет - у тебя nogaems тотальный no soft, а без софта ты никому не нужен. Времена, когда для раскрутки железки достаточно было написать под нее бэйсик и эксель давно прошли. Такие дела.
Именно поэтому IBM PC цветет и пахнет. Написана куча кода, который никто не будет переписывать, чтобы тебе стало заебись. А у самого тебя не хватит на это денег, даже если ты Microsoft. Плюс есть еще разработчики, которые в рот ебали переучиваться.
>1 незапустится.
Запустится. Все процессоры Intel серии x86 поддерживают эмуляцию 8088/8086. А BIOS скрывает детали реализации периферии INT13H, INT10H и так далее.
Проблема может возникнуть лишь если UEFI не поддерживает эмуляцию BIOS. Вроде как станд
арт UEFI называет эмуляцию BIOS опциональной.
Вот тут https://www.betaarchive.com/forum/viewtopic.php?f=59&t=34023
некто хвалится что запустил MS-DOS на... Macbook Pro.
В остальном - двачую вот его ->
>Ты не понимаешь сути. Любые кардинальные изменения обречены на провал, потому что существуют гигабайты исходников, которые хотят классическую архитектуру системы (в том числе и сырые указатели). Если ты делаешь систему, которая этого не умеет - у тебя nogaems тотальный no soft, а без софта ты никому не нужен. Времена, когда для раскрутки железки достаточно было написать под нее бэйсик и эксель давно прошли. Такие дела
Еще раз.
Для тупых.
Для совсем совсем тупых.
На момент выхода IBM-PC существовали гигабайты исходников, которые на этой самой IBM-PС не работали от слова никак.
И что?
А на момент выхода IOS, или андроидла, много приложений существовало под android?
А c ARM как быть?
Еще раз.
Для тупых.
Для совсем совсем тупых.
Никак не связанна совместимость и прочие технические нюансы с успехом и\или распространенностью той или иной аппаратной платформы.
Ты еще скажи что виндовс взлетела благодаря совместимости.
Может еще и 10тая виндовс благодаря совместимости взлетает?
Еще раз, для конченных идиотов.
Рынком управляют множество факторов, куда более весомых, нежели нюансы технической реализации всякой хуйни.
>Проблема может возникнуть лишь если UEFI не поддерживает эмуляцию BIOS
Я думаю могут быть и другие проблемы.
>Запустится
Ну запустится так запустится.
Говно те исходники. И до 2038 года о них все забудут, лишь ретрограды будут о них вспоминать.
> Еще раз.
> Для тупых.
> Для совсем совсем тупых.
> На момент выхода IBM-PC существовали гигабайты исходников
В IBM PC бейсик продолжил запускаться, как и на других машинах. Компилятор сишечки никуда не делся. Поменялась архитектура, но основные принципы остались теми же. И так как компьютеры использовались в основном для работы, можно было написать ОС + эксель + бейсик, чтобы у платформы появились юзеры.
> А c ARM как быть?
Точно так же. Ты берешь кросскомпилятор и конпелируешь. Большая часть кода не меняется, архитектурно-зависимые части переписываешь. Есть огромный шанс, что юзермодный код вообще не потребует модификаций.
Теперь представь, что ты заявляешь, мол unmanaged нинужен, у меня новая архитектура, managed код, нет MMU. Доводов не приводишь, просто "я так захотел". К тебе приходит кастомер, спрашивает: где мой линукс, где мой фаерфокс, где моя сишечка? И уходит.
> android
Гугл жопу порвал, чтобы обеспечить безболезненный переход. Чтобы была Java на десктопе, стала Java на Android. И я на сишечке через NDK пишу абсолютно так же, как пишу на десктопах. И линукс внутри. Ничего не поменялось.
> Может еще и 10тая виндовс благодаря совместимости взлетает?
Миллионы юзеров семерки и сотни тысяч юзеров XP сейчас существуют в том числе из-за проблем с совместимостью.
> И до 2038 года о них все забудут
Подумай, что делает язык кобол в списке TIOBE? Почему он популярнее, чем та же Scala? Обоснуй свой ответ.
Я получаю зарплату в биткойнах.
Сочувствую.
легаси?
>Миллионы юзеров семерки и сотни тысяч юзеров XP сейчас существуют в том числе из-за проблем с совместимостью.
Когда единственная причина твоего существования - проблемы с совместимостью.
Конечно. И в 2038 легаси никуда не денется, его станет только больше. Алсо,
Забавный факт природы: клавиатурный драйвер 10 винды транслирует няшные с любовью подобранные коды клавиш на USB-клавиатуре в make-коды клавиатуры IBM PC/XT, выпущенной в 1986. Он также эмулирует и break-коды, равно как и особенности некоторых клавиш типа Pause/Break или PrintScreen. Мало того, единственный способ гарантированно отличить левый шифт от правого - проверка сканкода. Это делает каждая крупная программа, например, все веб-браузеры. Теперь ты знаешь. Живи с этим.
>Теперь ты знаешь. Живи с этим.
Я и без тебя знал, покровосрыватель мамин.
Это вообще вопрос не обратной аппаратной ололо совместимости, а унификации программных интерфейсов.
Альзо, если няшные коды не позволяют отличить один шифт от другого, то они не няшные, а дерьмо собачье.
>Доводов не приводишь
Доводов дохулион.
>архитектурно-зависимые части переписываешь.
Прикинь.
>где мой линукс, где мой фаерфокс, где моя сишечка?
На свалке истории.
>И уходит.
На свалку.
===3
> Это вообще вопрос не обратной аппаратной ололо совместимости
Я отвечал на пост про легаси код - а этот любопытный факт как раз пример, как кусок кода, траслировавший сканкоды в виртуальные коды клавиш Windows, жив и здравствует несколько десятилетий. Его уже наверняка много раз переписали и костылей вокруг понатыкали (как тот, что c USB), но, я думаю, до 2038 он вполне доживет.
> На свалке истории.
На свалке истории оказалась каждая первая инновационная отличающаяся от традиционной архитектура - много было всяких начинаний за последние 30 лет. Но они оказались никому не нужны в том числе и по причинам, которые я привел выше.
> Доводов дохулион.
Где они, твои доводы? Ты лучше скажи, вот ты выкинул MMU, нет виртуальной памяти, надеешься на свой managed-код, который обеспечивает изоляцию приложений? Какова цена ошибки в VM, которая этим кодом рулит?
Ну что, поговорим ещё немного о том, ради чего был создан тред? Раз уж речь пошла о MMU и legacy, я вам кое-что принёс.
Новое слово в MMU это устройство с "универсальными страницами" - Flexpage. Суть этого новшества - размерность страниц виртуальной памяти. MMU следующего поколения будут поддерживать страницы размерностью 1024, 2048,4096, 8192, 16392, 32768, 65536, 131072 и т.д. Эта идея, если не ошибаюсь, впервые была реализована в микроядре L4 Pistachio. Такой подход открывает новые возможности по работе с памятью, например, даёт выигрыш по скорости по сравнению со стандартными страницами фиксированного размера.
Что касается legacy и новых архитектур. Старый добрый стандарт POSIX это именно то, что позволит уйти от legacy кода и алгоритмов. Любая система, сколько бы революционной она не была, обязана и будет поддерживать этот стандарт. Иначе она не выживет. Те же Apache, Mysql, PostgreSQL, Midnight commander и всё, что только придёт в голову должно без проблем собираться на новой аппаратной/программной платформе. И такая цель вполне достижима.
Что же касается ухода от legacy, то многим разработчикам давно известно куда идти - на смену POSIX придёт субъектно-ориентированное программирование. Это дальнейшие развитие идей Corba и COM-технологии.
Новое слово в MMU это устройство с "универсальными страницами" - Flexpage. Суть этого новшества - размерность страниц виртуальной памяти. MMU следующего поколения будут поддерживать страницы размерностью 1024, 2048,4096, 8192, 16392, 32768, 65536, 131072 и т.д. Эта идея, если не ошибаюсь, впервые была реализована в микроядре L4 Pistachio. Такой подход открывает новые возможности по работе с памятью, например, даёт выигрыш по скорости по сравнению со стандартными страницами фиксированного размера.
Что касается legacy и новых архитектур. Старый добрый стандарт POSIX это именно то, что позволит уйти от legacy кода и алгоритмов. Любая система, сколько бы революционной она не была, обязана и будет поддерживать этот стандарт. Иначе она не выживет. Те же Apache, Mysql, PostgreSQL, Midnight commander и всё, что только придёт в голову должно без проблем собираться на новой аппаратной/программной платформе. И такая цель вполне достижима.
Что же касается ухода от legacy, то многим разработчикам давно известно куда идти - на смену POSIX придёт субъектно-ориентированное программирование. Это дальнейшие развитие идей Corba и COM-технологии.
> традиционная архитектура
ТРАДИЦИИ
СТАБИЛЬНОСТЬ
ПРЕЕМСТВЕННОСТЬ ВЛАСТИ АРХИТЕКТУР
>Где они, твои доводы? Ты лучше скажи, вот ты выкинул MMU, нет виртуальной памяти, надеешься на свой managed-код, который обеспечивает изоляцию приложений? Какова цена ошибки в VM, которая этим кодом рулит?
Предлагаю для начала привести доводы того, что виртуальная память реально что-то там защищает.
Покамест что, из того что мне известно, приложения свободно ебут друг друга в хвост и гриву, и срать хотели на какую-то там виртуальную память.
Единственное что спасает, так то гипервизоры, и то не всегда.
>Предлагаю для начала привести доводы того, что виртуальная память реально что-то там защищает.
Впрочем у интола такое есть.
Позволяет запускать на пека ничем не убиваемые и не отслеживаемые вирусы.
Вставлять хтонические анальные зонды.
И верифицировать лицензионный контент.
Пиздец как люблю защищенную память.
>Предлагаю для начала привести доводы того, что виртуальная память реально что-то там защищает.
Защищает. Любая попытка выйти за пределы адресного пространства вызывает исключение Access Violation, что приводит к "Программа выполнила недопустимую операцию и будет закрыта" или "Accesss violation. Core dumped".
> мне известно, приложения свободно ебут друг друга в хвост и гриву
Обычно заражение происходит через файловую систему или через баги или backdoors в операционной системе. Если вирус вышел на уровень ядра, то, разумеется, он имеет доступ ко всем процессам. В обычной же жизни у приложения нет шансов навредить другому, кроме как попытаться сожрать всю память и/или время процессора.
Кстати, за другими темами не слежу, может быть в соседней уже пробегало. Свежая информация о самых популярных и востребованных языках программирования по версии IEEE - http://spectrum.ieee.org/ns/IEEE_TPL_2017/index/2017/1/1/1/1/1/50/1/50/1/50/1/30/1/30/1/30/1/20/1/20/1/5/1/5/1/20/1/100/
>
>Защищает. Любая попытка выйти за пределы адресного пространства вызывает исключение Access Violation, что приводит к "Программа выполнила недопустимую операцию и будет закрыта" или "Accesss violation. Core dumped".
Лол, по такой логике дебаг приложений должен быть невозможен в принципе.
Как и любой обмен данными, кстати.
>В обычной же жизни
В абстрактной идеальной системе в которой все работает как надо и приложение даже не пытается войти в чужую страницу памяти.
Вот и говорю, а стоит ли овчинка выделки?
>Защищает. Любая попытка выйти за пределы адресного пространства вызывает исключение Access Violation, что приводит к "Программа выполнила недопустимую операцию и будет закрыта" или "Accesss violation. Core dumped".
Интересно, как же работает читенжен для игор, который в памяти игоры ищет значения всякие?
> по версии IEEE - http://spectrum.ieee.org/ns/IEEE_TPL_2017/index/2017/1/1/1/1/1/50/1/50/1/50/1/30/1/30/1/30/1/20/1/20/1/5/1/5/1/20/1/100/
Какой-то мусорный сайт.
С битыми ссылками цыганщиной и рекламой на все окно.
Скрин что-ли сделай.
Блять, ты точно школьник, как я и предполагал в начале треда. Апи есть у винды. И у линукса есть. Апи! Если у тебя достаточно прав, ты можешь блять открыть процесс и сказать рид идли врайт, блять, процесс мемори. И ядро уже возьмет код и твоего адресного пространства и запишет в чужое. Или возьмет из чужого и запишет в твое. ЕСЛИ у тебя есть права. Если прав нет, ты идешь нахуй, решительно. Если апи нет, ты тоже идешь нахуй (или пишешь драйвер, который апи предоставит).
> Любая попытка выйти за пределы адресного пространства вызывает исключение Access Violation, что приводит к "Программа выполнила недопустимую операцию и будет закрыта" или "Accesss violation. Core dumped".
Кстати, неверное утверждение. Адресное пространство (у 32-битного кода, для простоты) - 4 гига. Оно все твое. Но так как у нас виртуальная память, то не каждая страница памяти существует в адресном пространстве. То есть, по какому-то адресу может быть абсолютно нихуя (пусто, дырка, адреса есть, а памяти нет). Если попробовать туда читать/писать - будет этот самый access violation. По другому адресу память может быть выделена, но только для чтения (флажок такой у страницы, аппаратно обрабатывается) - если попробовать туда писать, опять же будет access violation. А вот выход за пределы адресного пространства с виртуальной памятью невозможен по определению, потому что для выполняющегося кода просто нет каких-то других адресов, кроме своих.
Сейчас меня тот ниразбирающийся спросит, как же тогда работает ядро. А ядро маппит в свое адресное пространство страницы физической памяти, содержащие нужные ему данные, поэтому оно в своем адресном пространстве может работать с памятью других приложений. Под контролем ядра примерно то же делается и для юзермода - можно поиметь страницу, которая доступна из разных адресных пространств. Самый простой пример - file mapping, оно как раз так и работает.
>Какой-то мусорный сайт.
ничосссе
IEEE - Institute of Electrical and Electronics Engineers
Чисто для справки:
IEEE-1394 (называемый также FireWire) представляет собой высокоскоростной цифровой последовательный интерфейс.
IEEE 802.11 — набор стандартов связи для коммуникации в беспроводной локальной сетевой зоне частотных диапазонов 0,9; 2,4; 3,6 и 5 ГГц. Пользователям более известен по названию Wi-Fi
EEE 754 (IEC 60559) — широко используемый стандарт IEEE, описывающий формат представления чисел с плавающей точкой. Используется в программных (компиляторы с разных языков программирования) и аппаратных (CPU и FPU).
И так далее.
Без прав и апи это rtos без разделяемой памяти.
>школьник
Ну все, приехали.
>Вот и говорю, а стоит ли овчинка выделки?
Хочешь обсудить это? :)
Напомню, тут выше я упоминал Flexpages. Классное изобретение на самом деле. Живи долго, и ты увидишь что в будущем они вытеснят традиционные страницы виртуальной памяти фиксированного размера.
Что касается всяких управляемых языков и функциональных языков, которое действительно могут обеспечить защиту без виртуальной памяти и с помощью которых можно прозрачно решить проблему фрагментации, то... будь реалистом - все эти языки, несмотря на ни на что, работают в традиционных ОС. Вот эти все операционки, реализованные на функциональных языках, они ни разу не вышли за стены лаборатории или любительского проекта. Но в теории они, конечно, позволяют обойтись без виртуальной памяти.
Во-первых, традиционные страницы не фиксированного размера. У нас даже на x86 два размера есть (на x86-64 три). И на 32-битных мипсах три. И на 32-битных ARM четыре. Во-вторых, это абсолютно нихуя не дает нормальным пользователям. Да, получается экономия памяти на системные таблицы страниц и экономия времени при выделении больших объемов памяти разом, причем заметная разница начинается с нескольких гигабайт, что как бы намекает. А менеджеру кучи строго похуй, просить ли у ОС одну большую аппаратно поддерживаемую страничку или несколько маленьких - он уровнем выше.
>Во-вторых, это абсолютно нихуя не дает нормальным пользователям. Да, получается экономия памяти на системные таблицы страниц и экономия времени
Абсолютно "нихуя" кроме экономии памяти и экономии времени. Вообще ничего, кроме памяти и времени. А кроме памяти и времени - никакого выигрыша. Вообще никакого, кроме экономии памяти и времени.
> причем заметная разница начинается с нескольких гигабайт, что как бы намекает.
Ты так сказал. Надеюсь, ещё и мерил чем-то или на глазок?
> А менеджеру кучи строго похуй, просить ли у ОС одну большую аппаратно поддерживаемую страничку или несколько маленьких - он уровнем выше.
Расскажи, расскажи как работает системный вызов sbrk. Может быть заодно и разберёшься как это работает.
> кроме экономии памяти и времени
Экономия - десяток килобайт на процесс. Охуенная экономия, когда 16 гигов стоят меньше сотни баксов. Насчет экономии времени все не так просто. С одной стороны, меньше TLB-промахов (в абстрактном сферическом коде), с другой - например, флаг dirty становится менее информативен, со всеми вытекающими. Простой (надуманный) пример: процесс попросил 4 мегабайта памяти, изменил где-то один байтик и вернул страницы. С 4 КБ страницами: ОС посмотрела, что 1023 страницы не тронуты, и положила их обратно в пул пустых страниц, а одну обнулила. С 4 МБ страницами: ОС посмотрела - ну ебана, страница поменялась, и пошла обнулять все 4 МБ.
> Ты так сказал. Надеюсь, ещё и мерил чем-то
Когда я был молод и играл в осдев, в числе прочего экспериментировал с PAE. Конечно же, мерял - деталей за давностью лет не вспомню, но помню, что разницы не почувствовал.
> sbrk
А ты про другие ОС кроме линукса слышал? А про кастомные менеджеры памяти в приложениях, сделанные поверх маллока? Да и вообще упоминание sbrk тут скорее аргумент в мою пользу - менеджеру кучи строго похуй, sbrk у него внутри или VirtualAlloc, и где, как конкретно и в каком месте ему там ядро что-то (до)выделяет.
>Хочешь обсудить это? :)
>Что касается всяких управляемых языков и функциональных языков, которое действительно могут обеспечить защиту без виртуальной памяти и с помощью которых можно прозрачно решить проблему фрагментации, то... будь реалистом - все эти языки, несмотря на ни на что, работают в традиционных ОС. Вот эти все операционки, реализованные на функциональных языках, они ни разу не вышли за стены лаборатории или любительского проекта. Но в теории они, конечно, позволяют обойтись без виртуальной памяти.
Вопрос процентов на 20 технический, и на 80 концептуальный.
Да, на данный момент существует определенная устоявшаяся практика.
Говнокод не является практикой, на самом деле.
С другой стороны, кроме x86 и ARM ничего в персональном компьютинге нету. И не в результате неебатся какого технического совершенства сиих архинетур.
То есть, мы не знаем, что может взлететь, а что нет, прецедентов в современной истории человечества не было еще, x86 это первый и единственный персональный компьютинг. И было бы опрометчиво полагать, что технические решения в этом первом поколении самые лучшие и верные. Как программные, так и аппаратные.
Думаю, что, за управляемыми языками все-же будущее.
У такой системы есть ощутимые преимущества, вытекающие в основном из возможности контроля выполняемого кода.
С ходу, могу предложить такую концепцию.
Большая часть кода на управляемом языке, а какие-то специальные вещи, в виде подгружаемых ядром модулей.
А если говорить о серверном применении, так там защита памяти может оказаться совсем ненужна.
В привычном понимании.
Все равно предполагается, что твой сервис доверяет ОС.
>Напомню, тут выше я упоминал Flexpages. Классное изобретение на самом деле. Живи долго, и ты увидишь что в будущем они вытеснят традиционные страницы виртуальной памяти фиксированного размера.
Все хорошо что есть прогресс.
>Экономия - десяток килобайт на процесс.
>Охуенная экономия
На самом деле DА.
Можно 2 стека поместить.
>Охуенная экономия
Джава программист штоле?
Решать проблемы плохого кода покупкой памяти это конечно заебись.
> А микроядро даёт вам возможность компоновать систему из модулей.
Какое отношение модульность имеет к микроядерной архитектуре?
Подкину литературки:
Петцольд, вводная книга на доступном языке, берем вентили хуяк, хуяк и получаем процессор. Прочитал ее на одном дыхании, единственный недостаток нет упражнений. Практиковаться можно в воркбенче, мультисиме, но там слишком много всего и это отвлекает. Я делал в logisim.
Харрис "Цифровая схемотехника и архитектура компьютера". Задача книги та же, что у Петцольда из вентилей собрать процессор, но она более детальней и глубже, материал подан более академично. Сейчас читаю ее.
Петцольд, вводная книга на доступном языке, берем вентили хуяк, хуяк и получаем процессор. Прочитал ее на одном дыхании, единственный недостаток нет упражнений. Практиковаться можно в воркбенче, мультисиме, но там слишком много всего и это отвлекает. Я делал в logisim.
Харрис "Цифровая схемотехника и архитектура компьютера". Задача книги та же, что у Петцольда из вентилей собрать процессор, но она более детальней и глубже, материал подан более академично. Сейчас читаю ее.
То, что ты в молодости занимался OsDev - видно за версту. Но ты не один этим занимался.
Во первых TLB может быть сброшен при переключении задач и понадобится время на его актуализацию.
Во вторых, регион памяти в 48 килобайт ты опишешь или двенадцатью 4-х килобайтными страницами, или двумя страницами - 32 и 16 килобайт. Уже на 48 (!!!) килобайтах разница в количестве страниц - 6 раз. И дальше этот разрыв растёт. Подумай эту мысль.
Через сообщения. Когда компоненты системы общаются через сообщения и только через сообщения, то иного варианта кроме модульности быть не может. Даже если ты все модули поместить в один исполняемый файл, то логическая структура всё равно останется модульной. Ну и само микроядро это уже готовый базовый модуль.
>Петцольд, вводная книга на доступном языке
Название, плёс
> регион памяти в 48 килобайт ты опишешь или двенадцатью 4-х килобайтными страницами
Да, я затупил. Ок, и правда, при 4 мегабайтных страницах и заполнении большей части 32-битного адресного пространства, экономия может достигать единиц мегабайтов.
Код. Тайный язык информатики.
>Код. Тайный язык информатики.
Ну это уж совсем для молодых студентов, кто только-только знакомится со всей этой кухней.
Коллеги, а вы бы прикупили акций компании, которая пообещала бы создать новую архитектуру железа и софта?
UNITY FREE HARDWARE
FREE AS FREEDOM
>Коллеги, а вы бы прикупили акций компании, которая пообещала бы создать новую архитектуру железа и софта?
1. Задача слишком непосильная.
Стоит начинать только с чего-то одного.
Причем абсолютно новую ТМ возможно не стоит делать. Или иметь механизм совместимости, для начала опять таки.
Логично вначале сделать железо. чтобы на него можно было линукс какой накатывать.
2. Купил бы, если бы речь шла об опенсорс.
Любые деньги за аппаратную платформу без зондов закладок и анальных ограждений.
> 1. Задача слишком непосильная.
Я бы поспорил с этим утверждением.
> Или иметь механизм совместимости,
POSIX же.
> 2. Купил бы, если бы речь шла об опенсорс.
Но на открытых исходниках не заработать. Если уж очень нужен исходный код, то на условиях Non Disclosure Agreement и только с компаниями, которые способны возместить убытки в случае утечки.
> Любые деньги за аппаратную платформу без зондов закладок и анальных ограждений.
Любые деньги в размере своего бюджета?
>POSIX же.
POSIX процессор?
Если ты об ОС, то POSIX это некрогериентофилия.
И в чем же суть твоей ос в таком случае?
>Но на открытых исходниках не заработать.
Хаха, воу, классик.
>Если уж очень нужен исходный код, то на условиях Non Disclosure Agreement и только с компаниями, которые способны возместить убытки в случае утечки.
Прямо сейчас пиляться опенсорс SoC.
А ОСы так давно есть.
Какова целевая аудитория твоего гипотетического еще даже не начавшегося дерьма?
>POSIX процессор?
??? POSIX интерфейс поверх чего-бы-то-ни-было.
Насчёт "POSIX процессора" это уже петросянство какое-то.
> Если ты об ОС, то POSIX это некрогериентофилия.
Я знаю, но сверху POSIX работают десятки миллионов строчек кода. Готового кода. Тут вариантов нет - или POSIX или WindowsAPI.
Никто и никогда в здравом уме не будет начинать с пустого места.
> И в чем же суть твоей ос в таком случае?
Постепенный уход от POSIX в сторону субъектно-ориентированного программирования.
> Хаха, воу, классик.
Конечно. Знаешь, наблюдая за многими проектаами и чой-то славянских фамилий в коммитах вижу ничтожно мало.
> рямо сейчас пиляться опенсорс SoC.
Я видел их десятки на opencores.org, начиная от студнеческих поделок и заканчивая нелохими в общем-то проектами. Каждый дрочит как он хочет. Но ничего такого вот чтобы сказать что это прорыв - такого там нет.
> Какова целевая аудитория твоего гипотетического еще даже не начавшегося дерьма?
У тебя есть свободное время? Если да, то перечитай тему, ты кое чего найдёшь.
>аблюдая за многими проектаами и чой-то славянских фамилий в коммитах вижу ничтожно мало
И каким образом это связанно с коммерциализацией?
Кроме того, что ватники никому ненужны и выкинуты с мирового рынка.
>И каким образом это связанно с коммерциализацией?
Очень просто - не брать во внимание Ричарда Столлмана, то у нас тут логово поборников свободного софта. Концентрация зашкаливает, а вот в коммитах чой-та не видать. Отсюда вывод - самые ярые сторонники Open Source и есть большие любители "чужими руками жар загребать". Если кто-то всей душой ратует за свободный софт, то было бы правильно и этично чтобы он этот софт и писал. Это логично, не находишь ли?
А на деле, спроси у большинства показать его творения где-то на гитхабе и увидишь либо тыренный чужой проект, либо никому не интересный "шедевр" уровня helloworld. А кто реально выкладывает что-то интересное и полезное, тот уже шумит в интернете про свободное ПО, а внимательно читает Copeleft лицензию и форкает коммерческую версию.
И скажи что я не прав - посмеёмся вместе.
Кстати, как там с исходниками ОС "Эльбрус"? Нет ли там нарушения GPL? А то ведь какой-нибудь фанатичный юноша может и "потоптать малину", попади ему в руки исходники. Но я думаю до этого не довдёт, - МЦСТ просто зажмёт исходники, наплевав на GPL. Ну и производители китайфонов тоже не шибко делятся своими патчами - попробуй найди MTKшные исходники ядра и попробуй собрать из них ядро для своего китайфона. Для некоторых моделей ты даже модуль не сможешь собрать. Тончее, собрать-то ты сможешь, но вот использовать его вряд-ли. Есть такой негативный опыт.
>тот уже шумит
тот уже НЕ шумит
>Очень просто - не брать во внимание Ричарда Столлмана, то у нас тут логово поборников свободного софта. Концентрация зашкаливает, а вот в коммитах чой-та не видать. Отсюда вывод - самые ярые сторонники Open Source и есть большие любители "чужими руками жар загребать". Если кто-то всей душой ратует за свободный софт, то было бы правильно и этично чтобы он этот софт и писал. Это логично, не находишь ли?
>
>А на деле, спроси у большинства показать его творения где-то на гитхабе и увидишь либо тыренный чужой проект, либо никому не интересный "шедевр" уровня helloworld. А кто реально выкладывает что-то интересное и полезное, тот уже шумит в интернете про свободное ПО, а внимательно читает Copeleft лицензию и форкает коммерческую версию.
>
>И скажи что я не прав - посмеёмся вместе.
У тебя какой-то поток больной фантазии. Шумит кто-то, гитхаб какой-то. Местный обитатель сказал бы, что у тебя манямирок.
Опенсорс - это сириус бизнес.
И главные комиттеры в опенсорс на васяны с харкача, а корпорации вроде оракла, внезапно майкрософта, гугла, и тысяч других поменьше. И сотен тысяч совсем микроскопаических.
Опенсорс это java android MySql .NET продолжить до бесконечности. Докер, гитхаб, внезапно, и гит, хром и фаерфокс.
Бизнес, это в первую очередь решение проблем, взятие на себя чужих рисков. И только в самую последнюю, получения бабла. Одно ведет неизбежно к другому.
Именно так видит бизнес западный культурный человек.
И только грязные азиаты представляют себе бизнес в лучшем случае как торговлю на базаре - всучить лоху дерьмо.
> А то ведь какой-нибудь фанатичный юноша
Да кому какое нахуй дело.
Я тебя спрашиваю, какие проблемы решает твоя архитектура CPU и твоя ОС?
Почему кто-то должен ее выбрать вместо RISC-V например? Или на худ конец ARM?
А ос? Что там за субъекты, какие проблемы они решают?
>Опенсорс - это сириус бизнес.
В параллельной вселенной. Особенно в области GPL.
> И главные комиттеры в опенсорс на васяны с харкача, а корпорации вроде оракла,
Вот когда СУБД Oracle станет Open Source, тогда и приходи.
> внезапно майкрософта,
Вот когда Widows, MS Office, MS Visual Studio, MS SQL станут Open Source, тогда и приходи.
> гугла,
Android часть инфрастуктуры Гугла, они с него косвенно профит имеют.
И самое главное - SaaS. Эти твои "меценаты" медленно но верно продвигают SaaS и очень может быть что вскоре ты будешь не покупать ПО, а платить арендную плату. Добро пожаловать в новый "дивный" мир.
> Опенсорс это java android MySql .NET
Да да да. Особенно показательна Java. Покойся с миром, Sun Microsystems - ты так много сделала для Open Source что надорвалась и подохла. Светлая память и другим урок.
> гитхаб,
Ну попробуй бесплатно зарегистрируй на github коммерческий проект.
> хром
Уж не с этого ли говна пошла мода на хранение истории на гугловских серверах? Троянский конь тоже был подарен.
> фаерфокс.
"Netscape приняла решение разрабатывать браузер в рамках проекта с открытым исходным кодом. Была создана неформальная группа Mozilla Organization, которая в основном финансировалась Netscape, оплачивавшей труд основной части программистов, работавших над проектом. "
Netscape - RIP.
>Бизнес, это в первую очередь решение проблем, взятие на себя чужих рисков. И только в самую последнюю, получения бабла. Одно ведет неизбежно к другому.
Какой клинический бред. Территория заблуждений. Может быть назовёшь мне своих знакомых западных бизнесменов?
Любой бизнесмен тебе ответит: "Главная цель бизнеса — получение прибыли". Всё остальное это разговоры для бедных.
> Именно так видит бизнес западный культурный человек.
Tripple facepalm.
Решение проблем это СРЕДСТВО для получения прибыли, но никак не самоцель.
> И только грязные азиаты представляют себе бизнес в лучшем случае как торговлю на базаре
Ты границу РФ хоть раз пересекал?
> какие проблемы решает твоя архитектура CPU и твоя ОС?
Приобщившись к моей религии ты получишь следующие бонусы:
1. Изохронный рилтайм с малым временем отклика.
2. Низкое энергопотребление
3. Высокую плотность кода.
4. Неограниченные возможности расширяемости системы команд.
5. Ускорение в разы работы с виртуальной памятью.
> А ос? Что там за субъекты, какие проблемы они решают?
Субъект это нечто вроде цикла в выделенном процессе или программном потоке (thread), блокированного в ожидании сообщения от другого субъекта. Это с точки зрения реализации. Логически же субъект можно представить и как объект, интерфейс общения с другими объектами реализован через синхронные сообщения. Иными словами это некоторый объект, взаимодействующий с другими объектами посредством сообщений.
> какие проблемы они решают?
1. Масштабирования системы.
2. Упрощают реализацию некоторых алгоритмов. В частности, отпадает необходимость в таймерах.
3. Появляется возможность изоляции субъектов по разным адресным пространствам. При этом ошибочный субъект при исключительной ситуации не обрушит всю программу, а лишь ограничит её функциональность.
Сорян, но я эту несусветную глупость не буду комментировать.
Может ты и неплохой технический специалист, но это не делает тебя автоматически компетентных во всех остальных областях. Скорее наоборот.
>Приобщившись к моей религии
В чем заключается религия, ты так ничего об этом и не сказал.
>1. Изохронный рилтайм с малым временем отклика.
>2. Низкое энергопотребление
>3. Высокую плотность кода.
>4. Неограниченные возможности расширяемости системы команд.
>5. Ускорение в разы работы с виртуальной памятью.
Не вижу как это все способно решить хоть какие-то проблемы. Это просто набор технических терминов. Где и как применять все эти "бонусы"?
И кому именно?
Ну хорошо, будет технически хороший процессор, будет он производительнее и эффективнейшее Zen а от AMD?
А виндовс на нем запустится при этом?
>Ну хорошо, будет технически хороший процессор, будет он производительнее и эффективнейшее Zen а от AMD?
Нет, не будет. Он будет очень хорош в задачах управления оборудованием. В этой области он будет чрезвычайно эффективен. А для повышения производительности на расчётных задачах к нему придётся кое-что добавить. Но об
том рано говорить.
> А виндовс на нем запустится при этом?
Нет. Никогда. И ядро Linux тоже не запустится. С "напильником" можно будет Linux запустить, но при этом никакого выигрыша не будет.
Однако у Линукса можно "позаимствовать" драйвера и при этом не нарушить GPL - статической линковки не будет, каждый заимствованный драйвер переделывается в "субъект" и может быть дальше распространяться на условиях GPL. Бедного Торвальдса сердечный приступ хватит, а Столлман напишет новую версию GNU GPL, в которой очередной раз запретит такой сценарий использования.
Утянуть драйвера с Линукса по вышеописанному сценарию, не нарушая при это GPL - это хитрый план. Пущай Линус вспомнит тонны помоев, которые он вылил на Minix. Эндрю, мы отомстим за тебя :)
Нескучный микроконтроллер получается.
>Он будет очень хорош в задачах управления оборудованием
Чем он будет лучше существующий решений, и каких именно?
Будет ли он чем-то хуже с существующих решений?
> Чем он будет лучше существующий решений,
Изохронность низкой ценой. Предсказуемой состояние устройства в любой момент времени - всегда всё можно посчитать с точностью до такта.
Таймеры и уходят в прошлое - их заменяют таймауты сообщений. Прерывания уходят в прошлое - их заменяют сообщения.
> и каких именно?
Задачи управления, которые сводятся к внешнему событию, его обработке и реакции на это событие. Управление технологическими процессами и оборудованием, бортовая электроника и так далее.
> Будет ли он чем-то хуже с существующих решений?
В чём-то будет. Самое очевидное - разработчикам придётся посмотреть другим взглядом на принципы разработки устройств. Придётся переучиваться от асинхронного подхода построению таких устройств к синхронному. Поначалу это будет сильно раздражать и вызывать неприязнь. Вот тут кроется главная проблема.
Другая проблема это отсутствие в данный момент периферийных устройств, спроектированных для такого подхода. Вначале придётся делать обвязку, транслирующую прерывания в сообщения. Но со временем эта проблема сойдёт на нет - последние годы идёт тенденция на усложнение периферийных устройств, чтобы разгрузить центральный процессор. Например, сетевые карты, умеющие сами заполнять поля контрольных сумм пакетов. Т.е. периферия становится всё более и более интеллектуальна и это позволяет разгрузить процессор от рутинной работы, а сообщения в этом случае позволят более эффективно взаимодействовать с внешними устройствами.
Ну вот как-то так.
>В чём-то будет.
>разработчикам придётся переучиваться
>будет сильно раздражать
>вызывать неприязнь.
>проблема
>эта проблема
>Дайте мне денег, я могу создавать проблемы.
Это все замечательно, но абсолютно неинтересно.
Приходи когда научишься проблемы решать.
А всех, кого интересует открытое железо, предлагаю проследовать сюда - https://www.crowdsupply.com/onchip/open-v
И помочь заработать хорошим годным разработчикам.
И помочь заработать хорошим годным разработчикам.
>Приходи когда научишься проблемы решать.
Извини, исправить проблему в твоём ДНК мне не по силам.
Лучше подумай на досуге вот на этим:
https://ru.wikipedia.org/wiki/Скиапарелли_(спускаемый_аппарат)
Предварительные выводы основаны на результатах технического расследования. Причиной крушения спускаемого модуля стал сбой в инерциальной измерительной системе аппарата. В течение 1 секунды система выдавала отрицательное значение высоты, как если бы аппарат уже достиг поверхности. Этого оказалось достаточно для того, чтобы на высоте 3,7 километра посадочный компьютер отстрелил парашют, на короткое время включил тормозные двигатели модуля, а также включил ряд «наземных» приборов. Согласно оценке ЕКА, аппарат совершил свободное падение с высоты от двух до четырёх километров и набрал значительную скорость, которая в момент столкновения составила более 300 км/ч[20].
По данным от мая 2017 года причиной отказа спускаемого аппарата «Скиапарелли» является ошибка бортового компьютера. Это вызвало преждевременное прекращение выполнения программ спуска. К такому выводу пришли специалисты Европейского космического агентства (ЕКА), проводившие независимое расследование[
>Извини, исправить проблему в твоём ДНК мне не по силам.
Ты меня прям затралел.
>Лучше подумай на досуге вот на этим:
Лучше прими таблетки. Ибо ты бредишь.
Немного не заходил. Посмотрел субъективно-ориентированное программирование, точнее уровня обзорных статеек. Да это же подобно на исковерканное конкатенативное программирование! Ну, во первых конечно же сильное использование композиции, и уже, наверное, вытекающее из этого намеки на идею стека и прочее. Но опять же сильно усложнено как-то.
Ну, нравится мне конкатенативное программирование, тем более оно открыто для различных экспериментов. Смесь векторных и конкатенативных языков, компиляция в нейросети и последующая тренировка программы (вот это ведь модно же нынче, разве нет?), чудо ассемблер могущий использовать один стек для возвратов и данных и прочее. Я думаю, что это интересно и тут стоит большой потенциал.
Ну, нравится мне конкатенативное программирование, тем более оно открыто для различных экспериментов. Смесь векторных и конкатенативных языков, компиляция в нейросети и последующая тренировка программы (вот это ведь модно же нынче, разве нет?), чудо ассемблер могущий использовать один стек для возвратов и данных и прочее. Я думаю, что это интересно и тут стоит большой потенциал.
так, падажи ёбана, и так в ARM и X86 страницы могут быть разного размера, и аллокатор в линуксе умеет использовать их (HugePages)
можно в дополнение к IPC на уровне ядра сделать между двумя процессами на общей памяти (сделать в таблице страниц обоих процессов записи, указывающие на одни физические адреса).
Флашить TLB на современных процессорах не так страшно, если запилить поддержку ASIDов
Вообще, для тех же сетевых контроллеров, или аудио, gpu - всё, где важна latency - можно было бы сделать N областей MMIO регистров, и каждому процессу отдать свою. Но тогда все проблемы разделения доступа и планирования придётся решать в железе.
Короче, надо брать конкретную железку, и под неё делать прототип ПО на линуксе, потом на микроядре, профилировать и думать. Зачем делать General-Purpose решение в общем случае непонятно.
Ну или можно сказать, что все вокруг дебилы, обосрались сделать безопасность в линуксе и винде, а вот если сделать очень маленький TCB и микроядро - то в это раз-то точно не обосрёмся. Давайте запихаем наше говно в EL2 или TZ, и ему будем доверять.
Это не совсем то, что требуется. Желателен непрервный и полны набор страниц, чтобы их комбинацией можно было описать любой регион.
Но кое в чём ты прав - даже на существующих размерностях можно кое-то оптимизировать.
Если интересно - завтра эту тему перетрём, сегодня уже глаза слипаются ото сна.
Насчёт субъектов - вот эти общепринятые понятия на их счёт это очень близко, но не совсем в точности определяет то, что я подразумеваю под ними. Но в целом идея верна.
>Вообще, для тех же сетевых контроллеров, или аудио, gpu - всё, где важна latency - можно было бы сделать N областей MMIO регистров, и каждому процессу отдать свою. Но тогда все проблемы разделения доступа и планирования придётся решать в железе.
Ура! Возврат к архитектуре Amiga!
Не совсем понял. Можно поподробней?
Иногда у людей появляется такая привычка. Сам частенько пишу на рузке, но могу изредка вписать иностранный термин на транслите.
Ну и побуду КО: латентность = latency = задержка
другой_анон
Самопознание через боль. И пики, лол.
запоздание
> Не совсем понял. Можно поподробней?
Попробую. Субъект можно рассматривать как некий "чёрный ящик" к документированным интерфейсом. С точки зрения "пользователя", мы можем послать ему сообщение и получить на него ответ. В то же время сам субъект тоже может являться "пользователем" (и наверняка будет им) другого субъекта.
Что может быть субъектом? В зависимости от дизайна системы, субъекты можно реализовать на разных уровнях абстракции. Например, при одном дизайне субъектом может быть TCP/IP стек, при другом дизайне, субъектом может быть сокет. В первом случае вся работа с сетью выполняется посредством обмена сообщениями с TCP/IP стеком, во втором случае TCP/IP стек порождает новый субъект "сокет".
Ограничение синхронного дизайна - иерархия, при которой абсолютно всегда присутствует взаимоотношение requestor-responder. Таким образом, чтобы получить сообщение, его необходимо слушать, иначе передающая сторона заблокируется. Если же нарушить иерархию, то в какой-то момент наступить взаимоблокировка и система перестанет функционировать.
нууу нет, можно же абсолютно синхронно вернуть код ошибки (если не удалось найти адресата для сообщения) и протащить по всей цепочке вызовов наверх.
вообще, такой проблемы не должно возникать, если использовать явные хендлы/capabilities/какие угодно ссылки.
хотя надо уточнить, что имеется в виду под "нарушить иерархию". если, допустим, есть операция "опустить семафор и ждать", и оба процесса её выполнят, и никто не разбудит - то ой.
но как-то есть ощущение, что это не проблема микроядра, а более высокоуровневая проблема - некоторые решения проще реализовать (асинхронность, треды), но сложно доказывать корректность. а в ограниченных моделях (например, без общей памяти) сложно программировать что-то производительное.
короче, в этот момент надо захуярить хак и назвать его "политикой". например, детектор дедлоков, и конфигурируемый таймаут - и назвать "политика планировщика реального времени". и перенести ответственность с разработчиков системы на разработчиков конечного решения
В большинстве своем это все таки Javascript.
>нууу нет, можно же абсолютно синхронно вернуть код ошибки
С двумя задачами это работает. Ты прав. Вот пример. Одна задача пытается послать сообщение задаче, которая в это же время пытается послать сообщение в обратную сторону. Такая ситуация отлавливается очень просто. Верно и наоборот, если задачи пытаются принять сообщение друг от друга.
А вот дальше начинается засада. Пример - три задачи - Первая посылает сообщение второй, вторая третьей, третья первой. Взаимоблокировка, которую нельзя отловить автоматически.
Спасает таймаут передачи сообщения. Спасает, но не решает проблемы. Если положиться на таймауты, то всё будет жутко тормозить, хотя бы периодически. Но зависнет намертво. Некоторые так и поступают.
Я лишь хочу сказать, что существуют красивый способ решения этой проблемы и он сводится к проектированию программы/системы таким образом, чтобы не было взаимоблокировок.
> Если положиться на таймауты, то всё будет жутко тормозить, хотя бы периодически. Но зависнет намертво.
Чёртова дизлексия! Вот правильный вариант абзаца:
Если положиться на таймауты, то всё будет жутко тормозить, хотя бы изредка, но будет тормозить. Но не зависнет намертво.
Ты говоришь о системах разделения времени?
> Ты говоришь о системах разделения времени?
Как бы микроядра основаны на разделении времени - многозадачность, многоядерность, вот это вот всё.
Таймауты тут при том, что можно указать время ожидания от нуля до бесконечности. Задача при попытке передать сообщение будет ожидать готовности приёмника не дольше, чем указанный таймаут. В случае таймаута статус передачи сообщения будет "превышено время ожидания".
Для приёма сообщения тоже используется таймаут. И работает точно так же.
Кстати, вот эти таймауты это средство, которое позволяет избавиться от таймеров. Например, нужно через пол секунды выполнить какое-то действие - ждём сообщение пол секунды. Если оно пришло, реагируем на него и перед ожиданием следующего сообщения пересчитываем значение таймуата с учётом прошедшего времени.
Кому-то не хватает таймеров? Да они вовсе НЕНУЖНЫ!
> нужно через пол секунды выполнить какое-то действие
А через четверть секунды другое. А тут еще по сети данные пришли. В итоге реализация каждого первого приложения начинается с реализации таймеров.
Подкину маленько грязи. Она хоть не имеет отношения к теме, но всё-таки имеет.
Linux все еще не торт - https://habrahabr.ru/company/virtuozzo/blog/332740/
24-ядерный CPU, а я не могу сдвинуть курсор -
https://habrahabr.ru/post/332816/ (Windows sux)
Linux все еще не торт - https://habrahabr.ru/company/virtuozzo/blog/332740/
24-ядерный CPU, а я не могу сдвинуть курсор -
https://habrahabr.ru/post/332816/ (Windows sux)
Тухло как-то.
>Тухло как-то.
Да я сам в шоке - F5, F5, F5, F5. А всем пофиг.
Или ты что-то другое имел в виду?
Да, что-то типа того. Хотя в целом, я видел много различных проектов и людей, которые хотят изменить Айти, образование, математику и во многое другое.
К слову, разделение времени может быть применено к распределенным системам? Хотя тут надо синхронизировать время как-то (нагуглил какие-то векторные часы), а я вот вообщем и книги по распределенным системам не прочитал.
Ну я это понимаю следующим образом. Вот есть у нас некий процесс, который общается с другими посредством сообщений. И вот тут начинается интересная картина. Давай посмотрим с кем он может обмениваться сообщениями:
1. С другим процессом в пределах одного ядра.
2. С другим процессом, работающим на соседнем ядре, но в пределах одной микросхемы.
3. С процессом, работающим на соседнем микропроцессоре в многопроцессорной системе.
4. С удалённым узлом, через "прокси процесс".
В целом, система разделения времени будет работать в каждом случае несколько иначе, но она всё равно будет использоваться.
Что касается синхронизации времени, то тут задача начальной синхроизации, если мы говорим об абсолютном времени. А дальше используется счётчик тактов, который однозначно определяет время между какими-то событиями.
Я эrсперементировал со счётчиком 100 МГц размерностью 64 бита. Во первых, его переполнение при непрерывной работе произоййдёт через ~5 тыс лет, во вторых, 100 МГЦ более чем достаточно для управления практически любым механизмом.
Если брать всякие радары, где нужна большая частота, то всю радиочастотную работу выполняют специализированные DSP блоки, а процессору скармливаются уже обработанные данные.
Если я правильно понял твой посыл, то суть синхронизации времени сводится к первоначальной синхронизации счётчиков. То есть узлы должны обменяться значениями своих счётчиков тактов, учесть при этом задержку прохождения информации между узлами, а уже затем, зная значение удалённого счётчика и своего, можно синхронизировать любое событие с точностью до такта.
Ну вот как-то так я это представляю.
Какой-то разжиж мозга. Зачем процессору вообще иметь подобные клнцепты? Нахрена разным узлами что-то там синхронизировать? Если у каждого узла свой таймер, единственное что важно, чтобы они тикали с одинаковой скоростью. Так это никогда небыло проблемой.
Что ты несёш вообще.
И так то в системе нужно ставить один таймер на все.
Причём тут сетевое взаимодействие, я вообще непони, это параллельно железу.
Похоже, чтобы не возникало вопросов, нужно было сразу оговорить ситуацию, что такое "синхронизировать событие на разных узлах" и что такое "узел".
> Причём тут сетевое взаимодействие, я вообще непони, это параллельно железу.
НЕ причем, не причём. Но есть возможность абстрагировать железо. Т.е. программа может даже не знать, с кем она взаимодействует - с программной или аппаратной реализацией какого-то протокола. Давай на примере?
Вот у тебя есть внешний накопитель. Точнее. два накопителя. Пусть это будут SSD для красоты. Один из них классический, а второй с аппаратной поддержкой синхронных сообщений.
Для простоты рассмотрим ситуацию "Чтение первого сектора" с таблицей разделов.
Для классического диска нам потребуется драйвер, обслуживающий диск. В момент инициализации драйвер классического диска и диск с аппаратной поддержкой регистрируются в системе и получают имена. Например, HDD1 и HDD2 (условно).
Программа, желающая работать с дисками напрямую, Посылает два сообщение сервису имён, с запросом идентификатора для HDD1 и HDD2 соответственно. В ответах мы получаем соответственно идентификаторы устройств.
А вот тут начинается самое интересное. Обладая таким идентификатором, мы можем посылать ему сообщения, фактически не зная что находится с другой стороны - задача-драйвер, обслуживающая классическое устройство, или физическое устройство, нативно поддерживающее сообщения.
Иными словами - парадигма сообщений позволяет софту "прикидываться" железом, а железу "прикидываться" софтом. Граница между ними как бы стирается.
В случае же, когда по какой-то причине нужно точно знать, что находится с другой стороны, программа должна об этом явно спросить у удалённой стороны, послав соответствующее сообщение.
Ах да, речь же шла о чтении сектора. Так посылаем сообщения, адресуемые ранее запрошенными идентификаторами, и в ответах на эти сообщения получаем данные с этих секторов.
Краткость - сестра таланта. Ну не могу я кратко. Это только маленькая часть от того, что хотел сказать.
При вышеописанном подходе ничего не меняется для прикладного программиста - библиотеки скрывают от него всю эту кухню. Несколько меняется жизнь системных программистов и программистов встраиваемых устройств - придётся чуточку переучиться. А для электроников, разрабатывающих такие вещи, всё значительно усложняется. Вот кому будет действительно нелегко это разработчикам железа.
падажжи ёбана, ты только что описал концепцию файлового дескриптора, и блочные устройства сейчас в линуксе и винде ровно так и видны прикладному программисту
>для электроников, разрабатывающих такие вещи, всё значительно усложняется
Тогда надо придумать что-то другое.
Угу. Это просто дальнейшее развитие идей полувековой давности.
Современная электроника и так чрезвычайно сложна. Небольшое переосмысливание некоторых приёмов и подходов пойдёт ей только на пользу. Рассматривай это как новую ступеньку эволюции.
Среди инвесторов принята фраза: "Какие проблемы решает твоя разработка?"
Навскидку вот проблемы -
Но чтобы обосновать это утверждение, понадобиться написать бооооооооооольшую огромную статью, больше чем уже написано во всей этой теме. И это не единственные проблемы, которые можно решить за счёт использования аппаратных синхронных сообщений.
>синхронизировать событие на разных узлах
НАХУЯ?
>Иными словами - парадигма сообщений позволяет софту "прикидываться" железом, а железу "прикидываться" софтом. Граница между ними как бы стирается.
Это все заебись, но НАХУЯ СИНХРОНИЗИРОВАТЬ событие на разных узлах?
Ты прочитал "От 0 до 1", но в голове то - пусто.
Что толку тужить свой подкорковый анус, если дерьма нет?
Иди лучше двор подмети.
>Ты прочитал "От 0 до 1", но в голове то - пусто.
Хотя нет, даже этого не прочитал.
Чо это ты так перевозбудился на пустом месте?
Заказчик сказал - "хочу синхронизировать события на удалённых узлах". Этого достаточно. А зачем ему это нужно - не твоё дело.
>Чо это ты так перевозбудился на пустом месте?
>Заказчик сказал - "хочу синхронизировать события на удалённых узлах". Этого достаточно. А зачем ему это нужно - не твоё дело.
Заебись, у меня заказчик есть оказывается?
>Ну и побуду КО: латентность = latency = задержка
Хуёвый ты КО
Латентность (от лат. latentis – скрытый, невидимый)
На читай https://ru.wikipedia.org/wiki/Ложные_друзья_переводчика и больше не делай таких ошибок.
Latency is a time interval between the stimulation and response, or, from a more general point of view, a time delay between the cause and the effect of some physical change in the system being observed.
На, читай - https://en.wikipedia.org/wiki/Latency_(engineering)
Он про латентность. Ему невдомек, что с развитием языка слова получают новые, зачастую неправильные значения. И профессиональный сленг - один из источников таких слов.
Это не сленг, а хуета, которая может прижиться только у необразованных даунов. У слова латентность есть четкое значение, а если не хочется говорить слово задержка, просто говорят латенси и не выёбываются псевдопереводами и созданием говносленга.
>не выёбываются псевдопереводами и созданием говносленга.
Борцун? Борцун.
Ты о ком?
-кун
О тебе, вторгшемся в хакерский заповедник со своим уставом. Ты сейчас как та учительница русской словесности, которая возмущалась словом "отлаживать" и утверждала что нет такого слова. И она заткнулась, когда ей возразили: "Хорошо, мы не будем отлаживать программы - мы будем их откладывать!" Так и ты заткнёшься. А мы будем "дебажить", "компилять", "кодить", "форкать", "свопить", "поллить" и делать ещё тысячу вещей, которым в русском языке нет адекватной замены или они требуют контекста для понимания сути.
Вот тебе пример - core и kernel. В с лёгкой руки технических переводчиков это всё описывается одним словом - ядро. "Многоядерный процессор" и "ядро операционной системы". И таких примеров масса - найди адекватную замену thread. Многотопоточное приложение, программный поток, нить исполнения. Предложишь что-нибудь лучше? А может быть ты из тех, кто считает что процесс отладки нужно называть по-русски - обезжучивание?
Короче, не учи отца ебаться.
Thread - это нить, и в 90% случаев все эти псевдожаргонизмы от бедности словарного запаса и от плохого знания языка, а не от отсутствия адекватного перевода.
Я думаю что английский знаю не хуже тебя. Но если ты скажешь в приличном обществе "многонитевое приложение", то на тебя посмотрят как на странного, очень странного, человека.
Если же используешь слово "нить" для описания программного потока, то чтобы это звучало понятно и естественно, то придётся добавить слово "выполнения".
Наконец, ты не учитываешь факт что некоторый жаргон начал зарождаться ещё когда не было Интернета - многие программисты не имели возможности общаться с носителями языка и обзывали кто-во-что-горазд. И даже были казусы, когда самоучки попадали в коллектив программистов и использовали свой жаргон.
Т.ч. придраться к слову "латентность" это я не знаю кем надо быть. Наверное преподом или журналистом, пишущим на околокомпьютерные темы. Но явно не гиком, проводящим большую часть жизни с железками.
Я скажу многопоточной приложение. И речь идеттне о плохом знании английского, а о плохом знании русского. Тытвидишь английские термины, а их русского перевода не знаешь, даже общепринятого. Как вот с тредом, например - это нить процесса или поток, а ты не знаешь, как это сказать по-русски.
И латентность - так вообще никто не говорит, это ни жаргонизм, ни термин, а просто ошибочное, неправильное использование слова. И да, я другой онан
вы программировать тут будете вообще, или только пиздеть?
> 2017
> программировать
Всё уже напрограммировано до нас.
>вы программировать тут будете вообще, или только пиздеть?
http://everest.l4os.ru/download/MacroAssembler.zip
Поиграйся. Если чего-нить родишь, я опубликую это. Или ссылку в статье размещу или статью твою выложу. Как угодно. И авторство твоё укажу.
Деньги-то будут?
Во-первых, я постоянно использую кальки с английского, особенно они точнее позволят передать смысл. Могу сказать что такие случаи довольно редки, в основном кальки использутся для того чтобы не переключать контекст с англоязычного кода, доки или статьи в русскоязычную дискуссию или из-за банальной неграмотности.
Во-вторых, жаргон имеет место быть и в нем нет ничего плохого. Баг - отличный пример, который к тому же вышел за пределы программистского жаргона. Но использование слова латентность - маркер полуграмотной макаки.
В-третьих, /зк это нихуя не хакерский заповедник, а сборище шимпанзе, обученных нажимать на кнопки, вкатывальщиков в IT и студентов. Ради последних я это и пишу, а не для обычного наследственного дебила, который высирает
>процесс отладки нужно называть по-русски - обезжучивание
и считает это остроумным.
Надо развивать unikernel.
>Во-первых, я постоянно
Держи нас в курсе.
вы тёлок ебёте ваще?)
>Всё уже напрограммировано до нас.
Нет.
> Надо развивать unikernel.
Единое адресное пространство? Ну, идея имеет право на жизнь, но она не универсальна.
А почему ты спрашиваешь? Я дядька 44 лет. Второй раз женат. Дети есть в обоих браках. Все жёны ревнуют к компьютерам. Ты с такими вопросами в /b/ - тут им не место.
>Второй раз женат
Никогда не понимал такой хуйни. Про первую ты думал, что она та самая и единственная, потом передумал, встретил вторую и всё по новой?
>Все жёны ревнуют к компьютерам
Не думал, что надо не отказываться от компьютеров, а притормозить?
Почему не универсальна?
Ибо
memset((void*) 0, 0, INT_MAX);
гарантированно порушит систему.
Ну и тут выше уже говорили о фрагментации памяти, с которой худо-бедно но борется страничная память.
Вот тут вот про галеры пишут:
Галеры любят паразитировать на вузах, встраиваясь в процесс обучения за взятки деканам и заманивая студентов к себе. Менеджеры и тимлиды с галер тщательно скрывают от студентов свою паразитическую сущность, гордо именуя себя ведущими мировыми IT-компаниями и рассказывая, что основной офис у них находится в США. Галерное руководство скрывает от студентов тот факт, что галера их будет десятилетиями продавать иностранным клиентам с наценкой в 3 - 3,5 раза, навариваясь на них. Работа на галере преподносится для студентов как безальтернативный путь, потому что второй вариант - это работать на российских заказчиков за копейки. Про третий путь (самостоятельный поиск постоянной удаленной работы в США на long-term-проектах и удаленный консалтинг по контрактам) тимлид и менеджер никогда не расскажут студентам. Деканов факультетов эта ситуация устраивает по понятным причинам. Вузы вообще не учат тому, как студенту-программисту можно начать работать самостоятельно, как общаться с клиентами, находить их в США удаленно, вести переговоры посредством email или Google Hangouts, подписывать NDA, подписывать контракты. Вузы не учат юридическим аспектам самостоятельной работы на иностранных заказчиков, не учат тому, какими бывают контракты (time and materials, fixed-price, cost-plus). Вузы не учат тому, что, например, три друга-студента, ударившиеся в различные смежные специализации, могут втроем начать вместе работать на американского клиента, минуя всякие галеры, либо же могут втроем устроиться на галеру, затем увести клиента (что ТК РФ не запрещает), затем сразу уволиться с галеры и продолжить втроем работать из своих квартир на того же самого клиента или его бизнес-партнеров.
http://labor-union.wikia.com/wiki/Main
Аноны, скажите, а у системных программистов есть галеры?
Галеры любят паразитировать на вузах, встраиваясь в процесс обучения за взятки деканам и заманивая студентов к себе. Менеджеры и тимлиды с галер тщательно скрывают от студентов свою паразитическую сущность, гордо именуя себя ведущими мировыми IT-компаниями и рассказывая, что основной офис у них находится в США. Галерное руководство скрывает от студентов тот факт, что галера их будет десятилетиями продавать иностранным клиентам с наценкой в 3 - 3,5 раза, навариваясь на них. Работа на галере преподносится для студентов как безальтернативный путь, потому что второй вариант - это работать на российских заказчиков за копейки. Про третий путь (самостоятельный поиск постоянной удаленной работы в США на long-term-проектах и удаленный консалтинг по контрактам) тимлид и менеджер никогда не расскажут студентам. Деканов факультетов эта ситуация устраивает по понятным причинам. Вузы вообще не учат тому, как студенту-программисту можно начать работать самостоятельно, как общаться с клиентами, находить их в США удаленно, вести переговоры посредством email или Google Hangouts, подписывать NDA, подписывать контракты. Вузы не учат юридическим аспектам самостоятельной работы на иностранных заказчиков, не учат тому, какими бывают контракты (time and materials, fixed-price, cost-plus). Вузы не учат тому, что, например, три друга-студента, ударившиеся в различные смежные специализации, могут втроем начать вместе работать на американского клиента, минуя всякие галеры, либо же могут втроем устроиться на галеру, затем увести клиента (что ТК РФ не запрещает), затем сразу уволиться с галеры и продолжить втроем работать из своих квартир на того же самого клиента или его бизнес-партнеров.
http://labor-union.wikia.com/wiki/Main
Аноны, скажите, а у системных программистов есть галеры?
Вряд ли. Слишком специфическая область.
А сейчас такое разве не убивается планировщиком?
Да и unikernel оно же вроде уже почти что подобранное окружение
Так с одним адресный пространством такая ерунда может только ядром быть вызванна. А у апликух менеджет память и защита на уровне объектов.
Да вроде нет сборщика мусора.
> А у апликух менеджет память и защита на уровне объектов.
Если управляемый код (надеюсь, терминология правильная?), то проблем нет. Но "обычный" код без защиты адресными пространствами может натворить дел. Ошибка программиста или злоумышленник легко поставят систему "раком". Я ж говорю - идея неплохая, но не универсальная.
Помогите, люди добрые!
Вот кусок тестового кода, в нём нет смысла, это просто тест.
Прошу вас сгенерировать из него компилятором ассемблерный листинг. Что должно получиться смотрите ниже.
Мне нужен сгенерированный листинг от двух компиляторов, которых у меня нет. Ителовский icc и Embarcader RAD Studio (или как там сейчас называется борладновский С)
Простите, форматирование кода слетит, но это не должно помешать компиляции.
// ------------------------ Cut here -------------------
static int b = 4;
extern int printf(const char * format, ...);
int main()
{
int a=1,c=3;
printf("a= %d a ++ + a ++ + a ++ = %d, a= %d \n", a, a++ + a++ + a++, a);
printf("a= %d \n", a);
while( a++ < 5 + c-- )
{
if(a % 7 == 0)
{
b=0;
continue;
}
if(!b)
return c;
}
return -1;
}
// ------------------------ Cut here -------------------
Ассемблерный код вышеприведённого фрагмента, сгенерированый MS Visual C под катом.
; Listing generated by Microsoft (R) Optimizing Compiler Version 19.00.23506.0
TITLE C:\altera\alman\compiler\testcases\test_6.c
.686P
.XMM
include listing.inc
.model flat
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES
_DATA SEGMENT
_b DD 04H
$SG1378 DB 'a= %d a ++ + a ++ + a ++ = %d, a= %d ', 0aH, 00H
ORG $+1
$SG1379 DB 'a= %d ', 0aH, 00H
_DATA ENDS
PUBLIC _main
EXTRN _printf:PROC
; Function compile flags: /Odtp
_TEXT SEGMENT
tv81 = -20 ; size = 4
tv80 = -16 ; size = 4
tv71 = -12 ; size = 4
_c$ = -8 ; size = 4
_a$ = -4 ; size = 4
_main PROC
; File c:\altera\alman\compiler\testcases\test_6.c
; Line 7
push ebp
mov ebp, esp
sub esp, 20 ; 00000014H
; Line 8
mov DWORD PTR _a$[ebp], 1
mov DWORD PTR _c$[ebp], 3
; Line 10
mov eax, DWORD PTR _a$[ebp]
add eax, DWORD PTR _a$[ebp]
add eax, DWORD PTR _a$[ebp]
mov DWORD PTR tv71[ebp], eax
mov ecx, DWORD PTR _a$[ebp]
push ecx
mov edx, DWORD PTR tv71[ebp]
push edx
mov eax, DWORD PTR _a$[ebp]
push eax
push OFFSET $SG1378
call _printf
add esp, 16 ; 00000010H
mov ecx, DWORD PTR _a$[ebp]
add ecx, 1
mov DWORD PTR _a$[ebp], ecx
mov edx, DWORD PTR _a$[ebp]
add edx, 1
mov DWORD PTR _a$[ebp], edx
mov eax, DWORD PTR _a$[ebp]
add eax, 1
mov DWORD PTR _a$[ebp], eax
; Line 11
mov ecx, DWORD PTR _a$[ebp]
push ecx
push OFFSET $SG1379
call _printf
add esp, 8
$LN2@main:
; Line 12
mov edx, DWORD PTR _a$[ebp]
mov DWORD PTR tv80[ebp], edx
mov eax, DWORD PTR _c$[ebp]
add eax, 5
mov DWORD PTR tv81[ebp], eax
mov ecx, DWORD PTR _c$[ebp]
sub ecx, 1
mov DWORD PTR _c$[ebp], ecx
mov edx, DWORD PTR _a$[ebp]
add edx, 1
mov DWORD PTR _a$[ebp], edx
mov eax, DWORD PTR tv80[ebp]
cmp eax, DWORD PTR tv81[ebp]
jge SHORT $LN3@main
; Line 14
mov eax, DWORD PTR _a$[ebp]
cdq
mov ecx, 7
idiv ecx
test edx, edx
jne SHORT $LN4@main
; Line 16
mov DWORD PTR _b, 0
; Line 17
jmp SHORT $LN2@main
$LN4@main:
; Line 19
cmp DWORD PTR _b, 0
jne SHORT $LN5@main
; Line 20
mov eax, DWORD PTR _c$[ebp]
jmp SHORT $LN1@main
$LN5@main:
; Line 21
jmp SHORT $LN2@main
$LN3@main:
; Line 22
or eax, -1
$LN1@main:
; Line 23
mov esp, ebp
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END
Желательно два варианта от каждого компилятора - с полной оптимизацией и с отключенной оптимизацией. Спасибо.
Вот кусок тестового кода, в нём нет смысла, это просто тест.
Прошу вас сгенерировать из него компилятором ассемблерный листинг. Что должно получиться смотрите ниже.
Мне нужен сгенерированный листинг от двух компиляторов, которых у меня нет. Ителовский icc и Embarcader RAD Studio (или как там сейчас называется борладновский С)
Простите, форматирование кода слетит, но это не должно помешать компиляции.
// ------------------------ Cut here -------------------
static int b = 4;
extern int printf(const char * format, ...);
int main()
{
int a=1,c=3;
printf("a= %d a ++ + a ++ + a ++ = %d, a= %d \n", a, a++ + a++ + a++, a);
printf("a= %d \n", a);
while( a++ < 5 + c-- )
{
if(a % 7 == 0)
{
b=0;
continue;
}
if(!b)
return c;
}
return -1;
}
// ------------------------ Cut here -------------------
Ассемблерный код вышеприведённого фрагмента, сгенерированый MS Visual C под катом.
; Listing generated by Microsoft (R) Optimizing Compiler Version 19.00.23506.0
TITLE C:\altera\alman\compiler\testcases\test_6.c
.686P
.XMM
include listing.inc
.model flat
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES
_DATA SEGMENT
_b DD 04H
$SG1378 DB 'a= %d a ++ + a ++ + a ++ = %d, a= %d ', 0aH, 00H
ORG $+1
$SG1379 DB 'a= %d ', 0aH, 00H
_DATA ENDS
PUBLIC _main
EXTRN _printf:PROC
; Function compile flags: /Odtp
_TEXT SEGMENT
tv81 = -20 ; size = 4
tv80 = -16 ; size = 4
tv71 = -12 ; size = 4
_c$ = -8 ; size = 4
_a$ = -4 ; size = 4
_main PROC
; File c:\altera\alman\compiler\testcases\test_6.c
; Line 7
push ebp
mov ebp, esp
sub esp, 20 ; 00000014H
; Line 8
mov DWORD PTR _a$[ebp], 1
mov DWORD PTR _c$[ebp], 3
; Line 10
mov eax, DWORD PTR _a$[ebp]
add eax, DWORD PTR _a$[ebp]
add eax, DWORD PTR _a$[ebp]
mov DWORD PTR tv71[ebp], eax
mov ecx, DWORD PTR _a$[ebp]
push ecx
mov edx, DWORD PTR tv71[ebp]
push edx
mov eax, DWORD PTR _a$[ebp]
push eax
push OFFSET $SG1378
call _printf
add esp, 16 ; 00000010H
mov ecx, DWORD PTR _a$[ebp]
add ecx, 1
mov DWORD PTR _a$[ebp], ecx
mov edx, DWORD PTR _a$[ebp]
add edx, 1
mov DWORD PTR _a$[ebp], edx
mov eax, DWORD PTR _a$[ebp]
add eax, 1
mov DWORD PTR _a$[ebp], eax
; Line 11
mov ecx, DWORD PTR _a$[ebp]
push ecx
push OFFSET $SG1379
call _printf
add esp, 8
$LN2@main:
; Line 12
mov edx, DWORD PTR _a$[ebp]
mov DWORD PTR tv80[ebp], edx
mov eax, DWORD PTR _c$[ebp]
add eax, 5
mov DWORD PTR tv81[ebp], eax
mov ecx, DWORD PTR _c$[ebp]
sub ecx, 1
mov DWORD PTR _c$[ebp], ecx
mov edx, DWORD PTR _a$[ebp]
add edx, 1
mov DWORD PTR _a$[ebp], edx
mov eax, DWORD PTR tv80[ebp]
cmp eax, DWORD PTR tv81[ebp]
jge SHORT $LN3@main
; Line 14
mov eax, DWORD PTR _a$[ebp]
cdq
mov ecx, 7
idiv ecx
test edx, edx
jne SHORT $LN4@main
; Line 16
mov DWORD PTR _b, 0
; Line 17
jmp SHORT $LN2@main
$LN4@main:
; Line 19
cmp DWORD PTR _b, 0
jne SHORT $LN5@main
; Line 20
mov eax, DWORD PTR _c$[ebp]
jmp SHORT $LN1@main
$LN5@main:
; Line 21
jmp SHORT $LN2@main
$LN3@main:
; Line 22
or eax, -1
$LN1@main:
; Line 23
mov esp, ebp
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END
Желательно два варианта от каждого компилятора - с полной оптимизацией и с отключенной оптимизацией. Спасибо.
на лоре попроси
Лор мочепараша.
Шли годы, а ньюфаги все так же пытались выяснить, чему равно i++ + ++i. https://godbolt.org/
Ну как сказать, неуниверсальная. "обычный" код должен быть только в ядре и его модулях.
Ну или распространятся в виде сорцов, дабы проверяться на валидность.
Это единственный способ обеспечения безопасности.
В принципе.
А на всяких rtos, проблемы как таковой нестоит.
Относительно современной помойной ямы си-гнилокода, да, неуниверсально.
Да ладно, скоро managed-код захватит всю человеческую деятельность и мы все будем жить в лагающем ботнете.
Спасибо за ссылку, но это не совсем то, что нужно. Во первых, gcc у меня таки живёт в виртуальных машинах. Во вторых, мне нужно 32 бита. В третьих, штука неудобная - не позволяет пастить исходники. В четвёртых, icc и BCC32C на сайте по твоей ссылке нету.
>Шли годы, а ньюфаги все так же пытались выяснить
Вот ещё Undefined Behaviour
int one() { printf("One "); return 1; }
int two() { printf("Two "); return 2; }
int three() { printf("Three "); return 3; }
int four() { printf("Four "); return 4; }
fprintf(stderr, "%d %d %d %d\n", one(), two(), three(), four());
Что выдаст программа, собранная твоим любимым компилятором?
> icc и BCC32C на сайте по твоей ссылке нету
icc есть, в борланде шланг.
> мне нужно 32 бита
-m32?
> не позволяет пастить исходники
Лолшто? Смени браузер на современный, может быть?
> Что выдаст программа, собранная твоим любимым компилятором?
А где тут UB? Ты с implementation defined путаешь. Выдаст слова в каком-либо порядке, потом цифры последовательно.
Разобрался. Это именно то, что нужно. Спасибо!
>Да ладно, скоро managed-код захватит всю человеческую деятельность и мы все будем жить в лагающем ботнете.
Я же говорю, менеджед код не единственный выход.
Хороший годный правильный подход - rust.
Достаточно распространять По в виде сорцов.
Если хочется безопасности.
А виртуальная память - безопасность не обеспечивает.
Не обеспечивает. Не обеспечивает безопасность виртуальная память.
Программы хакают крякают хукают раком анал анус сверху с низу с боку.\
Блядь, КАК В ФИЛЬМАХ ИЗ 80Х ПОЛУЧАЮТ ПОЛНЫЙ ДОСТУП ЧЕРЕЗ СЕТЬ, через сеть, Карл. Отмычка от любой виндовс без смс мокрые потные кисоньки!
Так это еще не все. ВЗЛАМЫВАЮТ ИЗ ВИРТУАЛЬНОЙ МАШИНЫ ДАЖЕ.
Ну и вот вопрос, к чему вся эта еботня с виртуальной памятью, которая отжирает добрую терть транзисторного бюджета?
Чего добились то?
Один ебнутый дерьмокод не вешает своими багами всю систему?
Так rust позволяет достигать того-же без виртуальной памяти.
А менеджет код есть благо, но абсолютное благо только в составе с ручным управлением.
Не еблей с указателями как в няшной сишке, и чтобы была возможность выбирать, какие структуры кому отдавать на управление.
То есть, с более гибким управлением сборщиком(которых в сложной программе нужно несколько)
Вот придут flexpages, тогда поговорим.
>Вот придут flexpages, тогда поговорим.
Те же яйца только в профиль.
Все равно не поняно. Я мимохуй, но тоже всегда интересовал вопрос нахуя флоаты. Разверни ответ по подробнее, пжл.
Как ни крути в n бит можно закодировать только определенно количество дискретных значений. Числа с фиксированной точкой кодируют какой-то интервал набором равномерно распределенных точек. А флоаты - нет. На "полюсах" +-2^0 точки расположены очень плотоно, а потом в сторону нуля и +- бесконечности плотность уменьшается после каждой степени двойки.
В итоге, если у тебя число с фиксированной точкой, ты всегда точно знаешь какой интервал между точками, а в флоатах все зависит от числа. Ну и какой в этом профит? Мне, например, видятся только минусы, вангую что в матвычислениях или физических симуляциях это вообще нетривиальная задача т.к. накапливание погрешностей зависит от размера чисел в операциях.
Про масштабы не понял что ты имеешь ввиду. Ту же нормализацию и с флоатами тоже нужно делать и постоянно контролировать размер чисел.
>Про масштабы не понял что ты имеешь ввиду.
Я то-же не пони, но тот анон так и не ответил.
Как бы нет проблемы в операциях с числами с фиксированной точкой и разными масштабами.(разным положением точки, об этом же речь?)
Зато есть профит, ты можешь выбрать способ определения масштаба, ну или хотя бы точно знать, каким именно способом это произойдет.
Вот я и не могу понять, в чем же профит этого сраного флоата.
Разве что, можно наверное сказать, что он компактнее, и можно большие интервалы упаковать в те-же биты.
Но зачем?
Я в общем абсолютно непони.
Фиксированная точка видится более естественным представлением.
Железу считать ее проще.
Работа с вычислениями - прозрачнее.
Сколько я с этим сраным флоатом намучился в свое время.
> в флоатах все зависит от числа
Именно. Если у тебя расстояние в тысячи километров, миллиметры тебя не интересуют вообще, у тебя погрешность инструментов измерения выше. Если у тебя наоборот доли миллиметров, float обеспечит тебе соответствующую точность. При этом думать о диапазонах, о погрешности, о пердолинге десятичной точки в общем случае не нужно, некоторые проблемы есть только при сравнении чисел, но подходы давно выработаны. А погрешность накапливается при любых вычислениях с приближенными числами, никакой фикседпоинт не спасет, надо просто думать, что делаешь.
> float обеспечит тебе
А фиксед поинт не обеспечит?
>не надо думать
>не нужно
Ну еб твою мать.
>некоторые проблемы есть только при сравнении чисел, но подходы давно выработаны
Создали себе проблему и героически ее преодолели?
>Вычисления с приближёнными числами
15000 GigaWhat?
> А фиксед поинт не обеспечит?
Обеспечит, только когда доли миллиметров на по каким-то причинам превратятся в единицы миллиметров, фикседпоинт переполнится и сломает мне все, а float таки предоставит мне результат вычислений, пусть и с погрешностью. Но опять же, раз число большое, то такая погрешность меня очень даже устроит.
> Создали себе проблему и героически ее преодолели?
Окей, у тебя есть два числа в фикседпоинте, все то же расстояние в миллиметрах. Сравни их. А что меряем, я тебе не скажу. А если скажу, то проблемы нет и в float.
> 15000 GigaWhat?
Очевидно, что фикседпоинты точно так же округляются при вычислениях.
Алсо, поясни мне вот такую вещь. Вне программирования ты пользуешься плавающей точкой десятки раз в день без каких-либо проблем, но вот в компьютерах тебе внезапно от нее почему-то пригорает. Как ты вообще живешь с такими внутренними противоречиями?
>надо просто думать, что делаешь.
Т.е. в обоих случаях надо таки хорошо понимать что происходит, но в случае флоатов, если ты не понимаешь у тебя все не пойдет по пиздет, а просто исказиться результат из-за непредсказуемых погрешностей?
На мой взгяд это хуевый, порочный подход. Ладно еще в графике, это доставляет проблем в виде непредсказуемых пересечений, сдвигов и проваливаний объектов, но это сразу видно визуально и можно отладить. Другой момент когда у тебя какая-то математическая обработка, где в случае фиксед поинтов тебе сразу нужно думать что и как у тебя может вылезти или переполниться, а в случае флоатов можно понадеятся что все будет заебись и потенциально получить сильно неверный результат, охуеть чо.
И не надо мне задвигать что такого обычно не бывает. Я помню как нам в шараге преподавали численные методы. И хотя некоторые трюки для учета особенностей флоатов все же были, я всегда мог на глаз подобрать такие значения матриц\интегралов\диффуров что все решение шло по пизде. А ведь это можно сказать детский сад, что говорить о потенциальных проблемах в гораздо более сложных симуляциях. И будет твоя нейронка советовать любителям котиков - говяжьи анусы в рекоммендациях. Зато нигде не переполнилось, че.
Тут нет противоречия.
> но вот в компьютерах тебе внезапно от нее почему-то пригорает.
Ну вот в современных процессорах она блок вычислений с плавающей запятой уже есть и ничто не мешает им воспользоваться.
Но если floating point арифметики железо не поддерживает, то и нет особых причин реализовывать его программно, значительная часть задач, где используется плавающая запятая, решаются не хуже целочисленными методами.
Вот с этим почти не спорю. Софтфлоат не нужен, если у тебя конкретная железка, решающая конкретную задачу.
>Обеспечит, только когда доли миллиметров на по каким-то причинам превратятся в единицы миллиметров, фикседпоинт переполнится и сломает мне все, а float таки предоставит мне результат вычислений,
Неумение отлавливать переполнение это теперь преимущество?
>а float таки предоставит мне результат вычислений,
Неверный.
Причем с ошибкой на порядки. Нихуевый себе "результат", ракета вместо Марса промахнется на солнце, а ядерные электростанции будут то взрываться, то работать как холодильники.
Автопилот автомобиля, вместо слабой корректировки курса, развернет машину на 180 градусов при скорости в 120км\ч
>пусть и с погрешностью
Да посрать на погрешность, когда у тебя ошибка на порядки.
>Окей, у тебя есть два числа в фикседпоинте, все то же расстояние в миллиметрах. Сравни их.
Это тип проблема?
Приводим их к одной степени, и сравниваем как обычные инты.
>Очевидно, что фикседпоинты точно так же округляются при вычислениях.
Я не понимаю о чем ты говоришь.
>Алсо, поясни мне вот такую вещь. Вне программирования ты пользуешься плавающей точкой десятки раз в день без каких-либо проблем
ЛОЛНЕТ!
В жизни, в 99.9999% это фиксед поинт(почти), причем с десятичной точкой, то есть, все что с лева от точки - целые числа.
А все остальные случаи, это фиксед поинт с бесконечным возможным размером степени, и основы.
Зачем флоаты в калькуляторах, мне то-же непонятно.
>Как ты вообще живешь с такими внутренними противоречиями?
Никаких противоречий.
Алсо, ты похоже, под флоатом, подразумеваешь перенос точки на разные позиции.
Флоат - это нечто совсем другое. Это стандарт представления чисел в бинарном виде.
Флоат он потому, что количество бит для представления степени, и основания - варьируется.
Я понятия не имею, чем рукожобствовались сумрачные гении изобретая его, видимо, экономили биты, во времена, когда 16бит было огого как много для одного числа.
Прежде чем высирать критику вроде
>Я понятия не имею, чем рукожобствовались сумрачные гении изобретая его, видимо, экономили биты, во времена, когда 16бит было огого как много для одного числа.
неплохо было бы понять что
>перенос точки на разные позиции
и
>количество бит для представления степени, и основания - варьируется
это одно и то же. А после попытаться понять почему именно изобрели числа с плавающей запятой.
Хотя не думаю что ты будешь с этим заморачиваться, ведь
>А все остальные случаи, это фиксед поинт с бесконечным возможным размером степени, и основы.
>фиксед поинт
>c бесконечным размером
>фиксед поинт
>c бесконечным размером
>фиксед поинт
>c бесконечным размером
означает что ты из долбоёбов которые думают что умнее всех и пиздят о том в чем вообще не разбираются.
>это одно и то же.
Нет.
Вот у меня есть 64 битное число.
32 бита - отведены под основание.
Вторые 32 биты - десятичная степень.
Это норм, бро.
Вот есть 32 битное число, в котором количество бит под степень и основание может варьироваться.
Может 24 бита под основание, и 8 под степень. А может 7 под степень, и 25 под основание.
Это не норм, не бро. Представление данных курильщика.
> Неумение отлавливать переполнение это теперь преимущество?
Отлавливать переполнение можно, только c флоатами чаще всего это делать нет смысла. Фиксированную точку без проверок пидорасит, а плавающая точка деградирует красиво - расстояние между представимыми числами растет с ростом экспоненты, уменьшается с уменьшением экспоненты, и это как раз то, что ты ожидаешь получить при вычислениях.
> ЛОЛНЕТ!
Ну давай посмотрим. Расстояния ты меряешь в метрах с плавающей точкой (а также в сантиметрах, миллиметрах, километрах): n × 10приставка Си, массу в граммах, сопротивление в омах. В числах с плавающей точкой кодируется абсолютно та же самая нотация, только основание 2, а не 10, а вместо ограниченного количества приставок используется две с лишним сотни экспонент (для 32-битного float).
> Флоат он потому, что количество бит для представления степени, и основания - варьируется.
Лолшто? Флоат он как раз потому, что экспонента двигает десятичную точку, а вот количество бит на мантиссу и экспоненту в пределах одного типа флоата, конечно же, фиксированное.
> Приводим их к одной степени, и сравниваем как обычные инты.
Так ты и флоаты можешь сравнивать как инты, вот только может оказаться, что 100000 и 100000.1 должны быть равны.
> округляются при вычислениях
> Я не понимаю о чем ты говоришь.
Фикседпоинт, 4 десятичных знака: 99.01 / 02.00 × 02.00 = ?
>означает что ты из долбоёбов которые думают что умнее всех и пиздят о том в чем вообще не разбираются.
Ок.
На листике битов в которые нужно помещать числа нет вообще, так что там и то и то не применимо.
>фиксед поинт
>c бесконечным размером
Флоат может быть бесконечным?
>экспонента двигает десятичную точку
Ага, вот это самое говно.
> Флоат может быть бесконечным?
Флоат может быть таким, чтобы у тебя не нашлось величин, которые будут больше или меньше представимых с заданной точностью.
> Ага, вот это самое говно.
Экспоненциальная форма записи числа по-другому называется scientific notation. Вот им в этом их сайенсе норм почему-то. Удобно сравнивать, удобно оценивать точность, да и при вычислениях особых проблем не возникает. И в большинстве задач такое представление - выбор по умолчанию.
Да, есть области, где точность по-определению фиксированная, и поэтому тебе флоаты нахуй не сдались (хороший признак того, что тебе нужен фикседпоинт, а не флоат - это когда ты можешь считать что-то в целых штуках - например, считать деньги в копейках). Но ты просто ниразобрался (в том числе и в бинарном представлении), и бездумно пытаешься доказать превосходство технологии, применимой в узких областях над технологией, сделанной для общих случаев.
>перенос точки на разные позиции
Вангую что он имеет ввиду масштабирование фикседов т.е перенос точки в том смысле что ты меняешь дельту и ранг представления чисел. Во флоате это делается САМО, но и дельта меняется САМА.
>означает что ты из долбоёбов которые думают что умнее всех и пиздят о том в чем вообще не разбираются.
Но ты и сам так себя ведешь. У тебя какие-то очень странные представления о погрешностях и применимости. Конечно в типовых программистстких задачах флоат никак себя не проявляет и замени его фикседом ничего не измениться. (ну и нахуя тогда он?)
Но в задачах численного моделирования, физических симуляциях, машинном обучении, компьютерном зрении и т.д. нет такого ШО РАС ТУТ У НАС БОЛЬШИЕ ЧИСЛА ЗНАЧИТ НИ СТРАШНО ЧТО ПОГРЕШНОСТЬ БАЛЬШАЯ. Числа в процессе могут быть какие угодно и хорошо если в алгоритм заложены какие-то механизмы нормализации и борьбы с большими\маленькими числами, тогда флоаты никак не вредят, но и по сути получается что работают с ними как с фикседами. (ну и нахуя тогда они?)
> да и при вычислениях особых проблем не возникает.
Ага, именно поэтому нужен отдельный сопроцессор для этого говно.
Фиксед с масштабированием - это флоат
%КО%
Начнем с того что я () - пиздоглазый сонный мудак. Думал что говорил про целую и дробную части. Сейчас перечитал тот пост + и понял он вообще не представляет что такое floating point numbers и как они представлены в памяти.
>Вот есть 32 битное число, в котором количество бит под степень и основание может варьироваться.
>Может 24 бита под основание, и 8 под степень. А может 7 под степень, и 25 под основание.
Не может нихуя варьироваться. У тебя есть 1 бит знака, 8 порядка и 23 мантиссы. Уёбывай читать доки.
Не может. В этом вся проблема представления чисел в памяти.
Во-первых, я не рассуждаю о >погрешностях и применимости.
Во-вторых,
> в задачах численного моделирования, физических симуляциях, машинном обучении, компьютерном зрении и т.д. нет такого ШО РАС ТУТ У НАС БОЛЬШИЕ ЧИСЛА ЗНАЧИТ НИ СТРАШНО ЧТО ПОГРЕШНОСТЬ БАЛЬШАЯ.
может быть правдой, а может и нет. Флоаты придумали именно как средство представления большого диапазона чисел с определенной относительной точностью.
>Вот есть 32 битное число, в котором количество бит под степень и основание может варьироваться.
>Может 24 бита под основание, и 8 под степень. А может 7 под степень, и 25 под основание.
Не может нихуя варьироваться. У тебя есть 1 бит знака, 8 порядка и 23 мантиссы. Уёбывай читать доки.
Не может. В этом вся проблема представления чисел в памяти.
Во-первых, я не рассуждаю о >погрешностях и применимости.
Во-вторых,
> в задачах численного моделирования, физических симуляциях, машинном обучении, компьютерном зрении и т.д. нет такого ШО РАС ТУТ У НАС БОЛЬШИЕ ЧИСЛА ЗНАЧИТ НИ СТРАШНО ЧТО ПОГРЕШНОСТЬ БАЛЬШАЯ.
может быть правдой, а может и нет. Флоаты придумали именно как средство представления большого диапазона чисел с определенной относительной точностью.
Нет.
>Экспоненциальная форма записи числа по-другому называется scientific notation.
Речь НЕ О ФОРМЕ ЗАПИСИ, а о IEEE 754
>Расстояния ты меряешь в метрах с плавающей точкой
И схули она плавающая, если в метрах?
Ты там под накуркой?
>Ну давай посмотрим. Расстояния ты меряешь в метрах с плавающей точкой (а также в сантиметрах, миллиметрах, километрах): n × 10приставка Си, массу в граммах, сопротивление в омах. В числах с плавающей точкой кодируется абсолютно та же самая нотация, только основание 2, а не 10, а вместо ограниченного количества приставок используется две с лишним сотни экспонент (для 32-битного float).
>Ну давай посмотрим. Расстояния ты меряешь в метрах с плавающей точкой (а также в сантиметрах, миллиметрах, километрах): n × 10приставка Си, массу в граммах, сопротивление в омах. В числах с плавающей точкой кодируется абсолютно та же самая нотация, только основание 2, а не 10, а вместо ограниченного количества приставок используется две с лишним сотни экспонент (для 32-битного float).
Причины стоящие за флоат представлением те-же, по которым он и ненужен нахуй.
32 битный инт может быть максимум 4,294,967,295 единиц.
Допустим речь идет об Омах.
Допустим, мы выделяем десятые доли Ома(деления меньше в практике не используются)
429 496 729.5
И так, мы можем представлять величины от 0, до 429МегаОм, с точностью 0.1Ом
Или до 29МегаОм с точность 0.01 Ом.
При этом, когда речь идет о МЕГАОмах, то точности в сотые доли Ома недостижимы и абсурдны.
Резисторы с допуском 1% считаются точными.
То-же касается измерения расстояний, веса, массы.
В практическом применении(да и в теоретических расчетах) мы не встречаем диапазона больше нескольких порядков.
Поэтому флоат такой как он есть.
И по этому же. Все это говно ложится в 32битный инт.
Преимущество флоата только в том, что тебе НЕ НАДО ДУМАТЬ прежде чем записать в него метры, омы, граммы, или МЕГАОмы, или Килограммы, он схавает все, и ты радостно можешь умножать ГигаОмы на Омы и делить это все на МиллиМетры, не опасаясь само собой ПЕРЕПОЛНЕНИЯ.
Заебись вообще.
Это хорошо работает, когда ты башляешь лабы в универе.
И за такое нужно расстреливать, когда от твоих вычислений зависят миллионы долларов, и жизни людей.
Это примерно как rust и няшная сишечка.
Сишечку придумали раньше, и все побежали умножать поинтеры на рандомные числа. И приводить инты к войдам.
>Так ты и флоаты можешь сравнивать как инты, вот только может оказаться, что 100000 и 100000.1 должны быть равны.
Ты вапще непонимае6шь как там единицы и нолики живут?
Еще раз, если у фиксед пойнтов одинаковая степень, то, их сравнение(с абсолютной точностью) это сравнение двух интов, с точки зрения железа.
Если у них степень разная, то это приведение к одной степени, а затем сравнение двух интов.
>Фикседпоинт, 4 десятичных знака: 99.01 / 02.00 × 02.00 = ?
Нужно использовать промежуточное представление с большей точностью.
> cопроцессор
Вы к нам из прошлого? Перфокарт не отсыплете?
> Речь НЕ О ФОРМЕ ЗАПИСИ, а о IEEE 754
Вот только IEEE 754 в числе прочего - это способ представлять число в экспоненциальной форме в виде битов. По сути оно почти ничем не отличается ну кроме того, что еще кодируются NaN и denormals, а также существуют неявная единица у мантиссы и bias у экспоненты.
> И схули она плавающая, если в метрах?
1 километр = 1 метр × 103 (кило) (по определению) = 1000.0, 1 миллиметр = 1 метр × 10-3 (милли) (по определению) = 0.001. Точка плавает, а расстояние ты во всех случаях считаешь в метрах, а рядом указываешь необходимую экспоненту.
> Еще раз, если у фиксед пойнтов одинаковая степень, то, их сравнение(с абсолютной точностью) это сравнение двух интов, с точки зрения железа.
Вот сюрприз, но ты можешь сравнивать и флоаты, как инты (например, при сортировке), и все будет нормально, при этом все будет нормально даже для разных экспонент (для этого в флоаты притащили bias для экспоненты). Другое дело, что в большинстве случаев тебе нужно округление, и ты его делаешь. И делать ты его можешь делать в долях от текущего порядка числа или в абсолютных единицах. Собственно, проблема при сравнении float - не само сравнени и округление, а выбор, как именно сравнивать и округлять, и это завязано на сущности, которые этими float-ами представлены. С фикседпоинтом ровно такая же проблема, только геморроя больше.
> Нужно использовать промежуточное представление с большей точностью.
Чо, правда что ли? Насколько большей? Сколько вешать в битахзнаках? π / 2 влезет без округдения?
>Вы к нам из прошлого? Перфокарт не отсыплете?
Прикинь, FPU никуда не исчез из процессоров.
>Вот только IEEE 754 в числе прочего - это способ представлять число в экспоненциальной форме в виде битов. По сути оно почти ничем не отличается ну кроме того, что еще кодируются NaN и denormals, а также существуют неявная единица у мантиссы и bias у экспоненты.
Флоат ПОХОЖ на "саентифик нотатион" но не является оным.
>Вот сюрприз, но ты можешь сравнивать и флоаты, как инты (например, при сортировке)
Я, пожалуй, не могу.
Может и могу, но не хочу.
>Чо, правда что ли? Насколько большей? Сколько вешать в битахзнаках? π / 2 влезет без округдения?
Дальнейшая консультация платная.
>Один ебнутый дерьмокод не вешает своими багами всю систему?
>Так rust позволяет достигать того-же без виртуальной памяти.
Ты троллишь или реально такой даун?
> Прикинь, FPU никуда не исчез из процессоров.
А тебя аббревиатура MMX не насторожила в обведенных тобой кусках? В любом случае, сопроцессор - это отдельный процессор (в отдельном корпусе или на том же кристалле - не важно).
> Флоат ПОХОЖ на "саентифик нотатион" но не является оным.
Конечно не является, потому что есть детали реализации, упрощающие и ускоряющие расчеты и есть аппаратные ограничения (то самое количество бит в мантиссе и экспоненте, тогда как на бумаге ты не ограничен по сути ничем). Но проводить параллели можно и нужно.
Как не особо шарящий в
>погрешностях и применимости
решил немного погуглить (что, собственно, в первую очередь должен сделать любой адекватный человек). Нашел примеры когда fixed point недостаточно:
https://softwareengineering.stackexchange.com/questions/87457/why-do-you-need-float-double
https://softwareengineering.stackexchange.com/questions/224434/why-do-we-still-use-floats
>В любом случае, сопроцессор - это отдельный процессор (в отдельном корпусе или на том же кристалле - не важно).
Так он и отдельный.
Прикинь, внутри x86 процессора есть свои процессоры, поменьше, и все это говно склеивается софтовой прошивкой, при выполнении которой x86 и получается.
У тебя крайне странные представления о процессорах. Да, внутри RISC-ядро, да, некоторая часть набора инструкций выполняется не напрямую, а транслируется в микрокоманды, но это не повод говорить о том, что все "склеивается софтовой прошивкой". Еще более странно называть функциональные блоки "отдельными процессорами".
Ну раз тыскозал, то ладно тогда.
> И за такое нужно расстреливать, когда от твоих вычислений зависят миллионы долларов, и жизни людей.
Катастрофы из-за ошибок в использовании fixed point ariphmetics тоже были. Не панацея.
>Вы к нам из прошлого? Перфокарт не отсыплете?
Вот только не надо. За сопроцессорами будущее. Их можно масштабировать, если что. Но это уже нетрадиционная архитектура.
А каков бамлимит в /pr/? А то ведь можно долго разговаривать на эти темы.
500
Экзоядро пам пам пам
>Длинно рассказывают о недостатках фикседов и вся куча пунктов сводятся к вариациям аргумента ЩО ВОТ В ФИКСЕДЕ У ТЕБЯ МОЖЕТ ПЕРЕПОЛНИТЬСЯ, А У ФЛОАТА РАНГ НАМНОГО БОЛЬШЕ И НЕ ПЕРЕПОЛНИТЬСЯ
>Ни одного недостатка или намека на объяснение проблем от округления флоатов
Вот примерно такую аргументацию я всегда и получаю, когда на серьезных щах пытаюсь поднять этот вопрос.
Вы так говорите, как будто фикседпоинт не нужно округлять.
Я уже объяснял выше, в фикседпоинте ты всегда знаешь сколько теряешь на округлении, с флоатами - как звезды числы сложатся.
https://www.raptorcs.com/TALOSII/
Вот бы на таком железе было бы хорошо.
Вот бы на таком железе было бы хорошо.
>https://www.raptorcs.com/TALOSII/
>Вот бы на таком железе было бы хорошо.
Дороха.
И мне сейлинг пойн не очень понятен.
PCIE4 - это заебись, но я хз вообще к чему это.
Еще и за интегрированный сас контроллер предлагают доплачивать 300$.
И за пределами США ты хуй это купишь.
А так прикольно конечно.
Задам вопрос здесь, так как другие треды и близко не подходят по тематике, а свой плодить не очень то и хочется.
Почему 64-битные приложения требуют в 2 как правило раза больше ОЗУ? Дело в том что в 32-битных приложениях по одному адресу хранится только 32-разрядное двоичное числое, а в 64-разрядных приложениях только 64-разрядное двоичное число? Не сагайте, я только вкатываюсь в системщину.
Почему 64-битные приложения требуют в 2 как правило раза больше ОЗУ? Дело в том что в 32-битных приложениях по одному адресу хранится только 32-разрядное двоичное числое, а в 64-разрядных приложениях только 64-разрядное двоичное число? Не сагайте, я только вкатываюсь в системщину.
Ну, во-первых, не обязательно в 2 раза больше. Зависит от кода, можно написать так, что разница будет практически незаметна. Дело в том, что в 64-битном коде у нас:
- Адреса длиной (сюрприз) 64 бита, поэтому и размер указателя 64 бита, и чем больше указателей, тем больше памяти тратится "впустую". Единственный способ сэкономить на указателях - использовать индексы и смещения меньшей размерности вместо указателей. Но это глупая экономия, она обоснована только на огромных наборах данных.
- Регистры 64-битные. Если использовать целочисленнные типы, занимающие регистр целиком, то при сохранении значений в памяти, ее будет тратиться больше. Но никто не мешает продолжать использовать для хранения 32-битные типы, если их размера достаточно.
- Инструкции (на том же x86-64) могут быть слегка длиннее из-за префиксов, непосредственных значений (констант) и прочих данных, зависящих от размера регистра или указателя.
> по одному адресу хранится только 32-разрядное двоичное числое, а в 64-разрядных приложениях только 64-разрядное двоичное число
Нет. Минимально адресуемая единица - всегда байт по определению. Вот размер байта на некоторых архитектурах иногда может отличаться от привычных 8 бит, но если размер байта на 32-битной и 64-битной архитектурах совпадает (почти всегда), то по одному адресу хранится один и тот же байт.
Большое спасибо за разъяснение.
И что вы там?
Да ничего.
Три года назад я сделал процессор по образцу http://www.excamera.com/files/j1.pdf но до сих пор не могу понять какой у меня получился размер байта.
Все инструкции оперируют только с 16-разрядными данными. Считываться из памяти также может только по 16 разрядов. Но адресуется следующим образом: нулевое 16-разрядное слово считывается по адресу 0, первое слово считывается по адресу 2, второе слово по адресу 4 и т.д., младший бит адреса отбрасывается. Вроде бы получается что адресуется по 8 бит, а вроде бы и не совсем.
Сколько у меня получилось бит в байте?
Все инструкции оперируют только с 16-разрядными данными. Считываться из памяти также может только по 16 разрядов. Но адресуется следующим образом: нулевое 16-разрядное слово считывается по адресу 0, первое слово считывается по адресу 2, второе слово по адресу 4 и т.д., младший бит адреса отбрасывается. Вроде бы получается что адресуется по 8 бит, а вроде бы и не совсем.
Сколько у меня получилось бит в байте?
> младший бит адреса отбрасывается
Очевидно, что если софт может читать по адресу 1, то байт 16-битный.
*не может
Одной инструкцией это не прочитать, но можно написать небольшую функцию.
Сишный char на таком процессоре вполне может быть восьмибитным. Собственно я и сделал этот сдвиг адреса для более удобной работы с восьмибитными кодировками.
бамп
Тред не читал.
Торвальдс - Бог. Его ядро - это олицетворение, того, каким должно быть программирование в целом, каким должно быть ядро ОС вообще, пример идеальной архитектуры, пример того, что микроядра не более чем красивая теоретическая сказка, примерно как ООП и ФП языки на практике. Ядро линукса - это лучший проект в CS за всю историю человечества.
Таненбаум - пидор и лох, которые соснул у Торвальдса, со совей говноподелкой, опозорился на весь мир, потерял авторитет, жалко пытался наверстать упущенное публикуя свое говно под открытой лицензией, пытаясь сделать из этого general purpose ядро, но все его попытки были такими же жалкими как и он сам и с грохотом провалились. Я даже его книгу сжег.
>Таненбаум - пидор и лох, которые соснул у Торвальдса, со совей говноподелкой
Intel ME использует MINIX, так что не надо тут.
Сука, прочитал голосом Гитлера и проиграл на всю квартиру.
>Бизнес, это в первую очередь решение проблем, взятие на себя чужих рисков. И только в самую последнюю, получения бабла.
>И только в самую последнюю, получения бабла
АХАХАХАХАХАХА
для справедливости там вообще что угодно можно использовать, хоть нуклеус.
а так спор микроядро vs монолит усторел лет на 20 не в пользу микроядер. сосут они
с проглотом по перформансу и никакие костыли это не исправят.
Дурень дубовый.
Оба подхода сосут у гибридного ядра.
>ФП имеет четкую теоретическую базу. Все концепции ФП ясны, описуемы, реализуемы. ФП основывается на математике.
>Достаточно написать 2 слоя поверх аппаратуры, с учетом современных потребностей, и используя методы хорошо себя зарекомендовавшие. Этого будет достаточно для всех задач. Таким образом произойдет уплотнение всего стека программ. Объем кода уменьшится. Сложность уменьшится. Скорость и производительность увеличатся.
https://ru.wikipedia.org/wiki/%D0%9B%D0%B8%D1%81%D0%BF-%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%D0%B0
>Лисп-машина
Может быть и виртуальной. http://losak.sourceforge.net/
Или просто взять регистровую виртуалку поверх существующего железа, чтобы огород не городить. https://en.wikipedia.org/wiki/Inferno_(operating_system) Это если надо, чтобы работало быстро. Можно и стековую, если надо, чтобы работало вообще везде. https://en.wikipedia.org/wiki/Forth_(programming_language).
Я лисп машины к тому упомянул, что вот она - та самая железяка с минимумом прослоек, заточенная под выполнение кода на функциональном языке. Вот только она умерла ещё 40 лет назад, потому что оказалась нахуй не нужна.
>Вот только она умерла ещё 40 лет назад, потому что оказалась нахуй не нужна.
На самом деле, не все так однозначно.
40 лет назад она выполняла задачи уровня современных десктопов.
Ключевую роль сыграло 2 фактора.
1) Продвижение x86 IBM-PC архитектуры на массовый рынок в качестве монополии.
2) Высокая стоимость разработки собственной архитектуры(в момент когда несколько компаний захватили лидерство в производстве высокотехнологичного кремния)
Сейчас, когда развитие микроэлектроники упирается в физические законы, а разработкой высокоинтегрированных микросхем может и школьник заниматься, самое время для реинкарнации годных, но по разным причинам забытых, аппаратных архитектур.
Так то в лиспмашинах много годного.
Плюс, за менеджет системами будущее, а рост вычислительных мощностей нивелирует возможные ==ботлнеки:3
Ящитаю, что, числодробление бинарных команд в духе х86 или жпу, имеет применение именно в качестве сопроцессоров-числодробилок.
Доступных из вне через безопасный интерфейс, в духе OpenCL
Зато все языки переняли фичи из Лиспа.
И в итоге х86 при своей относительной дешевизне смогло догнать и перегнать лишп-мащины по производительности. И это даже с учётом того что лишп-машины разрабатывались под конкретную задачу с нуля, без необходимости поддержки тонны легаси.
В приниципе ситуация такая же как и с любыми другими альтернативными архитектурами - либо ушли в другую область, либо померли.
Алсо, троичная архитектура тоже вроде как годная.
И с Алгола тоже все языки фичи переняли, только где он теперь? - закономерно отмер в ходе эволюции.
Кстати, насчёт современных ЯП-машин - есть жи GA144 и иже с ним для форта - эталонная (впрочем, не значит "лучшая") железячная реализация. Если бы на нём было проще/быстрее/удобнее решать задачи общего назначения, все кто-нибудь бы так и делал, однако пока что он остаётся игрушкой, которой даже создатели не нашли конкретного применения.
>И с Алгола тоже все языки фичи переняли, только где он теперь?
Какие например? Лисп вечен. Ему уже 60 лет, а на нем пишут до сих пор. Ни один язык столько не прожил.
>закономерно отмер в ходе эволюции
ORLY?
>Алсо, троичная архитектура тоже вроде как годная.
Эмиттерно-связанная логика тоже годная, что с того? Оно тебе кажется годным потому что в схемотехнике не разбираешься.
Она не сильно-то отличается от "не лисп-машин" в железном плане, по крайней мере первые модели. Просто подкрутили конвейер, чтобы ускорить проверку типов в рантайме. Основная фишка была именно в language-based OS, когда пользовательский процесс не может напрямую выполнять машинный код на непосредственном железе, а лишь код, скомпилированный для некой виртуалки. Inferno (UNIX 2.0) и майкрософтовская Singularity как раз из этой оперы. Получаем многопользовательскую операционку с вытесняющей многозадачностью, которой не нужен MMU и прочие костыли в процессоре, которая не боится переполнений буфера и вообще в разы проще существующего зоопарка. правильно написал, что за ними будущее.
>есть жи GA144 и иже с ним для форта - эталонная (впрочем, не значит "лучшая") железячная реализация.
Для colorForth'а.
>однако пока что он остаётся игрушкой, которой даже создатели не нашли конкретного применения.
Потому что нужно быть Чаком Муром или около того, чтобы писать под нее эффективный код. Хотя вариация с 40 ядрами вроде использовалась в каком-то продвинутом слуховом аппарате с шумодавом.
>Лисп вечен. Ему уже 60 лет, а на нем пишут до сих пор. Ни один язык столько не прожил.
COBOL тоже вечен, ему до 60 два годика осталось. И пишут на нем до сих пор. Такое себе преимущество.
Я дописал свою операционку до наличия гуя и оконных приложений. Сама ось на асме, приложения - на си
И когда на языке семейства КОБОЛ последний стартап написали?
Где вакансии? На Лиспах можно найти работу даже в СНГ, даже в вебе.
> за ними будущее
Щас бы продолжать асбтрагироваться от железа, когда закон мура практически перестал работать.
Вот это уже теплее. На Лиспе имеет смысл начинать писать что-то новое в наши дни, а на Коболе - нет. Но это явно не из-за почтенного возраста и уважения к регалиям.
https://www.monster.com/jobs/search/?q=COBOL
https://www.monster.com/jobs/search/?q=LISP
https://www.monster.com/jobs/search/?q=Clojure
Иногда абстрагирование от кривоватого железа дает возможность настолько упростить ОС и пользовательский софт, что суммарный выигрыш в производительности начинает в разы превышать потери от введения этой самой абстракции. Почитай, что такое Inferno и что она умеет. Все же те же самые люди делали, что и оригинальный UNIX. Под влиянием полученного опыта, так сказать.
>Она не сильно-то отличается от "не лисп-машин" в железном плане, по крайней мере первые модели. Просто подкрутили конвейер, чтобы ускорить проверку типов в рантайме.
Не знаю что там в первой модели, но отличается сильно от х86, насколько хватает моего разумения. Там поддержка именно символьных вычислений, тегированная память, вот это все. И аппаратная поддержка сборки мусора.
>когда пользовательский процесс не может напрямую выполнять машинный код на непосредственном железе, а лишь код, скомпилированный для некой виртуалки. Inferno (UNIX 2.0) и майкрософтовская Singularity как раз из этой оперы. Получаем многопользовательскую операционку с вытесняющей многозадачностью, которой не нужен MMU и прочие костыли в процессоре, которая не боится переполнений буфера и вообще в разы проще существующего зоопарка. правильно написал, что за ними будущее.
Двачую люто.
>Щас бы продолжать асбтрагироваться от железа, когда закон мура практически перестал работать.
Речь как раз идет об избавлении от лишних абстракций.
У тебя код в обычной ос уже в лучшем случае работает в 2х вложенных "виртуальных машинах". Если ты на няшной сишечке пишешь.
И с десятком разнообразных прослоек соединяющих абстракции с абстракциями.
И когда у тебя проект чуть посложнее хеллоу верд становится, то возникает необходимость в управляемой памяти, лол, и вот ты пишешь свой сборщик мусора, добро пожаловать в еще один уровень скоства.
Rust в этом плане огромный шаг вперед, но пока с неизвестным результатом. Все же он больше похож на прокачанную сишечку, чем на что-то уровня хотя бы С#, или ерланга, да даже Го.
И что ты суешь? Я тебе про СНГ. На лиспах и в России пишут, и даже веб пишут. Кобол уже давно никому не нужен.
https://arhivach.org/thread/276524/ добавил в архивач
Здесь мы (чуточку) похоливарим насчёт "монолит vs микроядро", поговорим об ассемблерах, железе, обработке сообщений и прочих прелестях низкоуровневого программирования и железа. А так же, при желании, познакомимся IRL