KolibriN 10.1 - операционная система, написанная на ассемблере

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

ваще пушка

нафейхоа очкам или станку скидула эта ваша? лишние тормоза для 2,5 постоянно выполняющихся задач.

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

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

Но Линукс реально же не подходит для рилтайма, даже софтового? Это совершенно понятно и очевидно всем, кто пытался на нём систему оного класса сделать.

От низкоуровневых оптимизаций компилятором толку чуть, когда присутствуют retpolines, разделённая модель памяти, tlb shutdown по любому поводу и т.п.

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

ась? ВНЕЗАПНО: если нет переключения контекстов - нет и тормозов! вопрос повторно - зачем для 2-3 задач супер-планировщик? в RT-11FB ничего такого не было, а всё прекрасно работало.

шедулинг инструкций не имет никакого отношения к переключению контекстов

https://en.wikipedia.org/wiki/Instruction_scheduling

этому онанизмусу - непонятно. ему обязательно нужен кодировщик H.264 в кажном станке! БУГАГА!

а, вы про это? эта байда уже до плавления и спектра довела! нафиг не надь в станке! и даже местами и вредит!

на скриншоте к новости вантузный десктоп с того самого станка?

обязательно нужен … в кажном станке!

по-твоему, в каждом станке нужно замедление процессора в десятки раз?

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

Реальное время - это реальное время. Инструкции и ядра здесь не при чём.

О чём вы спорите? Где сказано, что она реального времени?

Неужели лень прочесть 1 страницу? Начало тут - KolibriN 10.1 - операционная система, написанная на ассемблере (комментарий).

Это я читал, я о том, что Колибри, вроде, не позиционируется как ОС реального времени. Я понимаю, её простота может косвенно этому способствовать, но не является целью, не?

какое замедление? что ты несёшь? можешь себе представить, что для управления многими станками до сих пор вполне достаточно i486 которые поэтому всё ещё выпускаются? и что вся эта многоядерность и предсказательность не бесплатна и по факту увеличивает накладные расходы? (в данном случае бессмысленные)

тот, кому я отвечал, говорил именно про «быстро»

http://wiki.kolibrios.org/wiki/EmbeddedKOS. Речь про то что может быть важен быстрый «отклик».

какое замедление

такое, в mips/flops надеюсь хоть осилишь посчитать

многими

т.е. уже таки не всеми гипотетическими станками с вантузным десктопом из оп-поста? понятно

100% experimental

ух щас бы поуправлять ядерным реактором в реалном времени…

Щас бы так бездарно троллить...

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

Даже АСУП собирали? Неплохо. А туда OSCADA впихивали? Конечно, нет, но было бы неимоверно круто. И LinuxCNC портировать :)

ясно. обнаружен флопсодрокер! в своё время на меня большое впечатление произвела тулзень для проверки-лечения zip дисков от Гибсона, на асме писанная, в 300 килобайтах делали все эти проверки, имела развитый гуй в котором писала обширные комментарии по теме и мыргала при этом глюкалками прям как большая прога! понятно, что ей минимально для работы i486 нужен был и ОЗУ сколько минимально для операционки. блиайжшие аналоги были облы, озорны, огромны, стозевны о нескольких мегабайтах и лаяй за $! только дело своё делали хуже если вообще делали. вот под такие «программы»/bloatware всё и затачивается, Wintel картель называется если не в курсе, чем хуже ПО тем лучше! ну и я так понял, что мой дискурс про сомнительную пользу «speculative execution» в свете особенностей управления станками и Spectre & MeltDown намеренно игнорируется? в курсе кстати, что оно «speculative execution» и real-time - по сути, взаимоисключающие вещи?

впечатление

ну раз уж так, то на меня в своё время произвела впечатление демка kkrieger, невеорятно долго у меня на компе дого стартовавашая и капитально тормозившая в то время. но зато да, 96кб, ух так победим

Котеечка, почему у тебя на аве Пахом не в расово-верной(ведо-родноверческой), грибоэлектрической, черной вышитой рубахе?! =)

Нехорошо!

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

взять реализацию MUMPS какую-то.

к примеру, реализации MUMPS под CP/M весьма компактны.

да и из той книжки про реализацию на С++ тоже довольно просто.

хотя вот например на Arity Prolog есть поддержка Btree : список предикатов

ArityProlog32 : install : исходники на GitHub

написан на masm. есть компилятор подмножества Си, достаточный для линковки с Си DLL. 32-битный компилятор под Win32, когда-то была поддержка DOS, OS2 (если не выпилили).

умеет компилировать в .exe, .dll минималистичные самодостаточные.

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

и потом портировать имея минималистичное кроссплатформное пролог-ядро. легко, куда угодно.

пролог гомоиконный, как и лисп.

метацикличный интерпретатор пролога на самом прологе пишется в четыре строки.

это и прочее, например, интерпретатор лиспа на прологе – есть на https://www.metalevel.at/

кул сторис

ужасный факториал

если логику обычных программ типа паскаля можно представить как «Алгоритмы + данные = программа», то пролога – «управление + логика = алгоритмы» (даже статья такая есть, именно так и называется).

программа это дерево. пролог делает перебор дерева сначала вглубь (SLDF). обходит дерево, перебирает подстановкой «переменные» (на самом деле, привязки). если подстановка успешна, и в базе данных есть факт (предикат-атом), подстановка успешна, значение возвращается. если подстановка неуспешна – перебирается следующий предикат.

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

что по сути реализует «ужасный факториал» ?

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

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

метаинтерпретатор является расширяемым «на самом себе», поскольку его расширение и реализация eval – это подстановка в базу данных пролога новых предикатов (введенной строки).

далее в духе такого же отсечения как в «ужасном факториале» реализуется выполнение этого кода нового предиката.

теперь что интересного есть в Arity Prolog32. есть предикаты работы с BTree деревьями.

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

который будет устроен как метациклический интерпретатор выше. только ещё дополнительно он должен парсить через DCG команды MUMPS-а.

и реализовать VM MUMPS-а. в духе Thinking in States статьи.

на Arity Prolog уже есть реализация BTree, генерация .exe/.dll, подключение внешних .dll FFI, и прочее.

есть исходники. есть кроссплатформенное ядро (кроссплатформенное среди DOS/Win32/OS/2).

логично было бы туда запилить поддержку Kolibri.

и затем реализовать на таком вот Arity Kolibri Prolog какой-то MUMPS.

выглядит реалистично.

или вот такой пролог кроссплатформный есть: ciao

• JVM implemented in Ciao

• Java bidirectional interface

• tcl/tk support

• LLVM interface (пока только в другую сторону, чем нужно).

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

а какой толк от «реализации MUMPS под CP/M»? примерно как от C++ на Спектруме? 8)

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

например, последний раз живой адабас видел в гаёвне лет 10 назад на сдохшем SFV890.

и да - нефига не понял, зачем делать для мампса б-деревья в прологе?8) их несложно сделать на чём угодно. проблема не в них.

а какой толк от «реализации MUMPS под CP/M»? примерно как от C++ на Спектруме? 8)

примерно :)) Зорка написать с машинным обучением на prologmud и logicMoo с OpenCyc :)))

проблема не в них.

а в чём?

и да - нефига не понял, зачем делать для мампса б-деревья в прологе?8) их несложно сделать на чём угодно.

ну да, сейчас YottaDB вот любопытственна. по сути GT.M только откуда M как язык выкинули. а библиотечно оставили. в итоге легко пишутся биндинги (уже есть из коробки) под какой-нибудь Go с асинхронщиной на горутинах. биндинги пишутся к C API, то есть подо всё. ну и обещают больше языков из коробки через год-два.

а так, ну почему бы и не на прологе :))) там кроссплафторменное ядро небольшое же. его бы разумно было бы с линуксизмов с сигналами и форков (из GT.M) переписать на какую-нибудь аду. через рандеву и таски в рантайме. кроссплатформное подо всё.

или вот, на прологе с двоичными деревьями, например :)) и из него сразу какой-то LLVM код генерировать.

хотя да, в Yotta DB неплохо так это ядро мумпса модулярилизовали. может лет через пять и под винду или там колибри с реактосом – тоже соберётся :))

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

а «кроссплафторменное ядро небольшое» - это Forth. прологу до него чапать и чапать.;-)