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

P.S. Конечно, можно предположить что "правильные пчёлы" где то сидят в своих ульях и друг с другом почти не пересекаются.

Да не бывает "таких" алгоритмов. 64К - это 32 страницы печатного текста. Вы можете привести пример 32-страничного алгоритма? Не делящегося на отдельные процессы? Не состоящего из достаточно слабо связанных частей, которые живут лишь ограниченное время? Не имеющего пары-тройки "ядер" (по паре десятков команд), занимающих 99,9% процентов времени? Или, как Вы правильно заметили, не разваливающегося естественно на A, B, C, D и далее "по алфавиту"?
"На практике" мы имеем простыни по несколько мегабайт кода, но после выливания "воды" и без учета "ресурсных файлов диалогов" остается пара-другая килобайт, которые и делают всю работу. Более того, т.к. мозг программиста имеет ограниченную вместимость, то больше этой пары килобайт обычно и не может считаться чем-то, что мы понимает "как работает", остальные же мегабайты - ввод/вывод/проверки параметров и обработка "особых ситуаций".

Вот это и есть софизм "настоящий шотландец" А что же тогда не ограничиться 256 байтами?


Поэтому в кальсонах врывался на форумы и учил жизни их обитателей

Убедили. А теперь, пожалуйста, приведите пример подобного алгоритма.

Лол, как это не бывает? А это тогда что:

• У меня есть программа с исходниками более молумегабайта - и это без учета подключенных внешних библиотек еще примерно на 10 мегабайт (и это еще в сжатом виде они).
• Рендеринг HTML страницы. Объем исходного кода, ресурсов, дополнительных библиотек и утилит на примере хромиума занимает объем около 20 гигабайт дискового пространства.
• Рендеринг трехмерных сцен в играх и любых 3D приложениях. Например, исходный код Unreal Engine 4 занимает примерно 9 гигабайт.
• Операционные системы - размер исходного кода варьируется очень сильно. От нескольких килобайт для МК, до десятков гигабайт для ПК, серверов, кластеров и т.п.

Требовалось:
Конечно, можно сказать, что я опять про "неправильных пчел", но речь-то шла о процессах, код которых влезает в 64K, а не о гигабайтах данных/ресурсов. Можно, конечно, кивать на известные первоисточники, например, коды ядра Linux, TeX, Wolfenstein3D, но мы там погрязнем в разборках "сколько там процессов" и каждый останется при своем мнении. Так, что найдите честно изложенный на десятке-другом страниц [русского языка] неделимый (!) алгоритм, и я с Вами соглашусь.

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

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

Определение см. в предыдущкм посте. Вопрос-то состоит в том, является ли существование более, чем 64K-сегментов кода следствием быдлокодерства (возможно, порожденным несовершенством ОГС) или полезным приемом программирования. И единственный способ доказать второе - привести именно неделимый (!) полезный алгоритм. Неделимый не в смысле одного оператора, а в смысле требования размещения всего кода в одном сегменте. И не надо мегабайт, достаточно будет 30 страниц [русского] текста.

И это может оказаться избыточным т.к. если рассматривать алгоритмы из предмета ПРИМА,
то и советские ПМК были весьма круты на сотне шагов программы

Так, сначала речь шла об алгоритме. Потом о неделимом алгоритме. Теперь речь об алгоритме, размещенном в одном сегмента. Например, в той в моей программе весь алгоритм в одном сегменте. И вообще, что это за требование такое? И откуда оно происходит?

0.5 Мб = 524288 байта = ~277 страниц английского текста = 277*1.2 = ~332.4 страницы русского текста.

См. начало темы. Все началось с "прогрессивности" замены 2+ на CELL+...

А почему в кавычках? CELL+ будет работать на любом Форте начиная с 83. В то же время 2+ будет работать мало на каком Форте запущенном на современном железе.

А неделимым в итоге будет признан только такой, который умещается в 64к? Вот например, алгоритм нахождения корней квадратного уравнения неделимый? Вроде бы да, но можно заявить, что он делится на нахождение дискриминанта и нахождение корней по известному дискриминанту. А в цифровой технике вообще есть базисы Шеффера и Пирса, с помощью которых можно выразить любую цифровую схему. Только так на практике не делают.
Ну да ладно, пью кофе и фантазирую
1. Когда совсем нельзя без 64к.
Рассматриваем некий самомодифицирующийся код, используемый для генетического алгоритма. Код выполняется с целью вычисления некоей ранее определенной фитнес-функции и модифицируется по заранее установленным правилам. Каков максимальный размер этого кода? Я не знаю. 65536 байт не является размером, имеющим математически доказуемые фундаментальные ограничения. Поэтому я не могу доказать утверждение "не существует генетического алгоритма с модифицируемым кодом, больше 65536 байт". Оверлеи не помогут, поскольку будут всего лишь техническим способом размещения кода. Алгоритм-то все равно имеет возможность модифицировать ячейку с номером 100000, и с этим придется как-то справляться.
2. Когда технически нецелесообразно, вплоть до потери функциональности.
Элементарно - realtime. Переключения страниц (а тем более подгрузка кода с внешних носителей) ведут к неминуемому снижению производительности. В случае именно жесткого RT это недопустимо, в случае типа "трехмерная игра" ведет к снижению fps и ощутимому ухудшению потребительских свойств программы.
3. Когда неудобно.
Когда код технически может быть разделен на страницы, но поддержка такого разделения выступает в качестве отдельной задачи и именно неудобна, потому что заставляет тратить время и внимание.

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

Самомодифицируемость кода не имеет решающего значения. С тем же успехом он может разделятся на куски и/или быть управляемым данными.
Realtime? Как раз, наоборот. Критические фрагменты кода всегда невелики. Зато требование распараллеливания и грамотного распределения ресурсов между процессами намного важнее.
Гораздо неудобнее рассматривать огромный кусок кода, как единую кучу мусора.
В принципе, можно придумать много вариантов и столько же контрвариантов, но одно ограничение несомненно. Код, весящий больше, чем может отследить программист просто опасен (даже если порожден тупыми средствами макрогенерации и/или копипаста). Именно поэтому я предлагал поискать алгоритм на пару другую страниц человеческого текста. Разбиение подобного материала на отдельно усвояемые ("отдельно работающие") леммы и теоремы практикуется всеми авторами.

Тем не менее, такой код не адресуется 16 битами. Да, можно его переделать, но это будет вынужденной мерой, тогда как 32 бита на адрес устраняют в корне.

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

Это же разные случаи - анализ исходного текста и размер сгенерированного кода. Никто не мешает логически разбивать программу на легко анализируемые модули. Просто потом, когда они все будут подгружены, возникнет закономерный вопрос "и почему они все вместе не помещаются в память, хотя ее гораздо больше 64к"? Еще раз обращаю внимания, что технические характеристики не то чтобы определяют требования к алгоритмам, однако достижение определенных результатов открывает возможности для постановки задачи на новом уровне. И если сейчас доступна память для программ с размером кода в мегабайты, имеет смысл подумать, а чем это может быть полезно. Ну вот люди и думают, и пишут программы. А глядя на них, пользователи ожидают подобных характеристик и от других программ.