Я не говорю, об ограничении памяти компьютера 64K. Я лишь говорю, что 64K для кода (и 16-разрядов для адресации внутри него) для большинства процессов достаточно. Выход же наружу (страницы, сегменты, процессы, порты, шлюзы...) в большинстве систем на большинстве процессоров - тоже не проблема.
Дык, признак хорошей системы - их изоморфность.

Помнится Форт системы с нибл-ячейками были (4-е разряда)

P.S. А можно ли считать неделимым алгоритм поведения (AI) ирового бота и требовать его размещения в 64Кб адресного пространства преодлевая "карму" 32/64 разрядных систем?

1) Обычно эти AI очень просты. 2) Исторически AI делится на несколько слабо связанных процессов (см. например ROG-O-MATIC), иногда даже реализованных совершенно на различных принципах/ресурсах (см. например Амосов "Автоматы и разумное поведение").

Вы не там ищете источник весомости современных программ.
С форума игроделов:

P.S. Кстати, об AI. Пример того, что я хотел показать. Очень элементарный. Игра состоит (кроме компьютера) из настольного "органайзера", "калькулятора игры" (включающего AI) и "программы диалогов". Реализация каждого из этих "процессов" в наиболее выгодной "программно-аппаратной среде" позволила даже на таком убогом железе сделать что-то замечательное. Конечно, мы можем, по нынешним временам, перерисовать/переписать все в виде одного большого модуля на каком-нибудь из "WIN-BASIC-ов", но при этом не только пропадет "запах картона", но и появится огромная куча ОО- и API- мусора, которая не только увеличит размер кода порядка на два-три, но, наверняка, сделает игру менее удобной и, гарантирую, правила игры "поедут".

P.P.S. К чему это все в разговоре о FORTH-стандарте (нам еще повезло, что никто к "устаревшему" 2+ не добавил BLOCK и строковый редактор)? К тому, что нельзя переход от 2+ к CELL+ считать прогрессом. Это лишь невозможность современных тупых процессоров работать в наиболее экономичном и удобном для FORTH режиме, которую приходится блокировать, меняя в своих программах 2+ на 4+. Стандартизировать все возможные аппаратно-программные выверты (например, COMPILE,) невозможно в принципе. Проще запомнить, как оно работает. Особенно по двум причинам: в ядре FORTH машинно-зависимых слов крайне мало (в нем вообще мало слов), а в FORTH-программе подобные слова встречаются только в узкой прослойке "введения удобных слов" (например).

Эмм... У меня тут бразуер запущен, занимает от 2 до 10 гигабайт. Ну или вот например ннкрон запущен - занимает 3 мегабайта ОЗУ (Форт, между прочим). Проверил остальные процессы - в среднем занимают 5-100 мб памяти, более тяжелые процессы - от нескольких Гб. И где тут большинство процессов меньше 64к?

Не нужно менять 2+ на 4+. Нужно менять 2+ на CELL+. Регистры процессора нынче обычно 64х-битные, а через лет 15 будут 128 битные. Зачем искусственно добавлять ограничение в 64K, если в аппаратуре его нет?

Это, если писать подумавши. Например о том, зачем ннкрону 3Мб? Он такой умный? Чтобы не копаться в столь больших проектах (наверняка, там и процессов десяток, и данных <цензура>% от объема, и мусора <цензура>% от оставшегося) и предлагал Вам приводить обозримые примеры.
Выше я уже написал, почему это не нужно. Добавить могу только одно. Замена 2+ на CELL+ ни коим образом не сделает FORTH переносимым.
Повторяю, никто ничего искусственно (нли естественно) не добавляет (было 2+ и осталось). Добавить требуете Вы - CELL+. А ограничение аппаратуры, в данном случае есть, и мерзейшее: из-за него я не могу нормально играть в старые игры без эмуляторов и вынужден мириться с тем, что половина FORTH-программы - мусор (т.к. старшие 16 - или, даже, 48 - разрядов ячейки избыточны).
Смысл 2+ не в том, что понадобилось специальное слово для пересчитывания ячеек память, а в том, что прибавлять двойку приходилось часто, в т.ч. для перемещения по ячейкам...

Это уже несколько устаревшая зацепка. Дескать, программисты не думают, а полагаются на компилятор, который берет числом, а не умением. И если бы программисты думали, то программы были бы маленькие, быстрые и надежные. Здесь есть рациональное зерно, однако обдумывание программы отнюдь не обязательно приводит к решению сделать ее минимально возможной.
Насколько велик цикл от 0 до 100? А такой же цикл от 0 до 100000? А с разворачиванием кода? Расточительство? Не факт. Если объем памяти достаточен (да к тому же ориентирован на объективно требуемые гигабайты данных), то почему бы не повысить производительность за счет увеличения требуемого объема? Допустимый прием. Не обязательный, но допустимый. А раз так, то зачем привязывать к языку неактуальные более технические ограничения?


Зато замена CELL+ на 2+ сделает Форт НЕпереносимым.





В 32-битном режиме вызов по 16-битным адресам идет с префиксом. Так что не все так очевидно. К тому же что за экономия по Плюшкину? В системе и так крутятся десятки процессов, а претензии почему-то только к Форту. Вот куда память уходит, оказывается! Форт вылез за предел 64к!

Не только, например, распространенные приемы "масштабирования", "матрешки", "елочки" да и обычного "копипаста" вполне осмысленно применяются программистами, компилятор там не при чем. Да и подумать я предлагал, скорее, над тем, сколько в этих программах кода (за вычетом буферов "на всякий случай") и насколько осмысленно считать их одним процессом.
Бесполезно говорить о переносимости непереносимого изначально.
А еще очевиднее. Как ни крутись, мусор неизбежен.

Речь не про Forth, а про программы на нём написанные. Конечно, программа использующая CELL+ более переносима, чем использующая 2+ для той же цели.



Корректно написанные игры вполне работают без эмуляторов. Хоть doom, хоть Wolfenstein, хоть Supaplex.



Это кому как. Мне вот приходит 5 Гигов новых данных в день. Причём в связи со спецификой данных - иметь их нужно в ОЗУ. Тут лишние разряды не помешают.



Совершенно верно. Поэтому адаптировать к другой версии Форта программу, использующую 2+, намного сложнее чем использующую CELL+: нужно помнить - "здесь 2+ - это следующая ячейка, здесь 2+ - это так индекс увеличивается, а здесь это мы рыбу заворачивали".

В то время, как если приспичит адаптировать программу использующую CELL+, для работы на Форте без этого слова, можно либо добавить одну строчку с определением, либо сделать поиск и замену "CELL+", на "<скольно-нужно>+". Просто, не правда ли?

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

Уж не знаю, фортер или нет, но я-то как раз буду использовать CELL+, и помнить ничего не нужно. Любой, кто прочтёт - сразу помёт, что именно тут выражено. Даже и не знаю, как объяснить ещё, что специализированное слово лучше чем 2+.

А зачем браузеру 10 гигабайт оперативки? Да, ннкрон такой умный: у меня примерно 5500 записей в словаре. Под словарь отведен ровно мегабайт памяти. Ядро ннкрона занимает около 400кб. Под пользовательские задачи - 400 кб остается примерно.

Лол. Большой? Это ннкрон-то большой? 4 сотни файлов и пару мегабайт исходного кода. Кроме одной иконки, других мультимедийных данных нету. 1 основной процесс, все что больше - пользовательские задачи. А что же тогда хромиум с его 20 гигабайтами?

Вот и примеры больших объемов кода...

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


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

Это нецелесообразно помнить на протяжении всего процесса разработки. Это потенциальный источник логических ошибок. Даже если адрес, индекс, счетчик и еще что-то увеличиваются на 2, рациональнее и нагляднее так и писать - ADR+, INDEX+, COUNTER+. Затраты памяти на это смехотворны, а "оптимизация" и "проявление квалифицированности программиста" на деле оборачиваются необходимостью размениваться по мелочам, постоянно удерживая внимание на малозначительных деталях и упуская возможные проблемы в алгоритме и архитектуре программы.

Ур-ра! Из 100500 способов использования 2+ мы выделили 1, который не нужно запоминать! Осталось всего 10499. Повторяю, чуть ли не единственный плюс FORTH - способность создавать свои языковые [под-языковые, над-языковые и прочие... придумайте любую свою терминологию] структуры. И любой поднаторевший в этом деле фортер знает, что 2+ относится не к яблокам, а адресам, не потому, что видит CELL+, а потому, что видит, что это слово явно имеет дело с адресной арифметикой.
Так, что думаю, очевидно, что о необходимости размещения всей этой хрени в одном сегменте кода речь не идет. Повторю, найдите алгоритм на 30-страниц русского текста - и приходите.
Избыточно больших.
Так за рулем-то те же ямщики. И качество их работы только ухудшается. Только еще и бензином воняет. Впрочем, Вы, кажется, раньше уже радовались тому, как стало лучше от внедрения компьютеров в повседневную жизнь, так что замнем.
И не надо, я же приводил пример - 10 строк на определение примитивов работы со списками, а дальше уже они... Причем, лучше было бы в течение следующих 20 строк перейти на более крупные примитивы, но у меня не получилось...