Непонимание...

Господа, я понимаю, что вопрос поиска НДВ, защиты от НСД и прочие упражнения в сравнительной оценке аппаратных реализаций дискреционной и мандатной политик интересны, но при чем здесь Forth?

Ведь даже Win32 вполне допускает запись в сегмент кода. А для каких еще ОС нужен Forth? Для Win64? Не раньше, чем он перестанет поддерживать Win32 (т.к. 75% мусора в программе - многовато). А Forth для 'nix-ов? Зачем? Там нет проблемы написания простых интерпретаторов (как и сложных компиляторов).

Gudleifr> Господа, я понимаю, что вопрос поиска НДВ, защиты от НСД и прочие упражнения в сравнительной оценке аппаратных реализаций дискреционной и мандатной политик интересны, но при чем здесь Forth?

Это вопрос разделения. Нужна ли ОС, или всё это язык. Лучшле ли интерпретатор чистый или с аппаратной поддержкой. Форт по всем пунктам подходит.

PS ИМХО, просто все эти споры про P и А бесполезны без решения вопроса выше.

Mishka> Форт по всем пунктам подходит.
Mishka> ИМХО, просто все эти споры про P и А бесполезны без решения вопроса выше.
А зачем решать, если "Forth все равно подходит"?
А дается программисту в ощущениях, P следует из понимания задачи. F - просто способ их по-быстрому связать.

Gudleifr> Господа, я понимаю, что вопрос поиска НДВ, защиты от НСД и прочие упражнения в сравнительной оценке аппаратных реализаций дискреционной и мандатной политик интересны, но при чем здесь Forth?
Ранее, в этой же ветке форума Вы разместили ссылку на "заметки на полях" Мура.
Цитирую (в моём переводе):

Портируемость

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

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

 

Та же идея прослеживается и у Броуди. И речь идёт не только об аппаратуре.
Любая операционная система, по сути, представляет собой наименьший общий знаменатель ряда прикладных программ - а стало быть, согласно идеологии Форта, не имеет права на существование.
Операционные системы одинаково плохо удовлетворяют уникальные особенности прикладных задач.
Честно ответив на вопрос "Зачем?" легко продемонстрировать сказанное.

Veden12> Любая операционная система, по сути, представляет собой наименьший общий знаменатель ряда прикладных программ - а стало быть, согласно идеологии Форта, не имеет права на существование.
Почему? Любая ОС решает конкретную задачу: сделать конкретное железо привлекательным для клиентов.
Аппаратно-независимые ОС? Да нет, при качественно отличающимся железе, это, скорее, разные ОС, выглядящие снаружи одинаково.
Кстати, ребята из XEROX как-то заметили, что "снаружи одинаково" могут выглядеть ОС, как основанные на сообщениях, так и основанные на процессах/семафорах.

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

Veden12>> Любая операционная система, по сути, представляет собой наименьший общий знаменатель ряда прикладных программ - а стало быть, согласно идеологии Форта, не имеет права на существование.
Gudleifr> Почему? Любая ОС решает конкретную задачу: сделать конкретное железо привлекательным для клиентов.
Разве это не задача драйверов от производителей железа? А к набору драйверов сводятся, быть может, лишь экзоядерные ОС (название придумали, идёт активный поиск смысла).
Gudleifr> Аппаратно-независимые ОС?
Пользовательские интерфейсы всех ОС объявляются независимыми от железа. Но что лучше - зависимость от аппаратуры или от ОС?
Скажите, разве вытесняющая многозадачность (прерывания) на восьмиядерном процессоре - не маразм? Для настольной машины, не сервера.
Gudleifr> Да нет, при качественно отличающимся железе, это, скорее, разные ОС, выглядящие снаружи одинаково.
Если я правильно понимаю "выглядят" (буквально), то это свойство не ОС, а приложений (вспомним MS Office под MacOS).

Gudleifr> Аналогично я могу рассматривать стандартизацию Forth на уровне основополагающих идей (сверхнизком) или на уровне потенциальных возможностей (свервысоком). Но не на уровне реализации обязательного набора слов.
Для Форта стандартизация - заведение набора неиспользуемых слов. Я тоже не вижу в этом смысла.

Veden12> Разве это не задача драйверов от производителей железа?
И тот "одинаковый внешний вид", который они имеют, в сумме и дает ОС.
Win95, например, так и позиционировался - набор виртуальных драйверов.

Veden12> Пользовательские интерфейсы всех ОС объявляются независимыми от железа.
Если не считать пользователем системного программиста (и, даже, сисадмина).

Veden12> Но что лучше - зависимость от аппаратуры или от ОС?
Попробуйте рассказать про "независимость от железа" поклонникам компьютерных игрушек.

Veden12> Скажите, разве вытесняющая многозадачность (прерывания) на восьмиядерном процессоре - не маразм? Для настольной машины, не сервера.
Думаю, маразм для настольной машины - восьмиядерный процессор.

Veden12> Если я правильно понимаю "выглядят" (буквально), то это свойство не ОС, а приложений (вспомним MS Office под MacOS).
Почему же, все 'nix-ы одинаковы и для программиста.

Но мы опять уходим от Forth. Он-то здесь причем?

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

Veden12>> Но что лучше - зависимость от аппаратуры или от ОС?
Gudleifr> Попробуйте рассказать про "независимость от железа" поклонникам компьютерных игрушек.
Драйвер 3D-ускорителя - по сути, специализированная ОС - это клин, вбитый глубоко в ядро любой ОС общего назначения. Со всеми вытекающими. И отношения между этими двумя ОС всегда были натянутыми.
Veden12>> Скажите, разве вытесняющая многозадачность (прерывания) на восьмиядерном процессоре - не маразм? Для настольной машины, не сервера.
Gudleifr> Думаю, маразм для настольной машины - восьмиядерный процессор.
Прогресс, однако... Но не во всём.

Gudleifr> Но мы опять уходим от Forth. Он-то здесь причем?
Gudleifr> А то, мы здесь столько наговорили, что любая попытка сделать хоть что-то реальное будет на этом фоне банальной и пошлой...
Возможно. Мне трудно об этом судить. На данный момент, мне интересно насколько эффективна (решение задач, не быстродействие и не занимаемое место) 64-битная Форт-система сама по себе, без поддерживающей ОС, без прерываний. Голый процессор, порты, память сколько есть вся. И современный BIOS с поддержкой FAT32, сети и ещё много чего. Пока я обнаружил, что для логики взаимодействия с аппаратурой Форт очень удобен. Программирование больше похоже на обучение. Лишние программные интерфейсы обязательно порождают явно лишние стековые движения - и это сразу видно. Сейчас разбираюсь с терминалом. Вот это - вполне реальное. Исследовательский проект, конечно.

Veden12> На данный момент, мне интересно насколько эффективна (решение задач, не быстродействие и не занимаемое место) 64-битная Форт-система
А не напрягает то, что для "собственно Forth" и 32-бит многовато? Или так много 64-битных данных?

Veden12>> На данный момент, мне интересно насколько эффективна (решение задач, не быстродействие и не занимаемое место) 64-битная Форт-система
Gudleifr> А не напрягает то, что для "собственно Forth" и 32-бит многовато? Или так много 64-битных данных?
Я себе очень плохо представляю Forth с разным размером адресов и данных (параметров). Не иметь доступа ко всей памяти - печально. Не думаю, что система опухнет до такой степени, что съест больше мегабайта. А даже мегабайт по сегодняшним меркам - ничто.
С другой стороны, 32-битные режимы x86 были, в основном, предназначены для многозадачных ОС - дескрипторы сегментов, страницы, кольца защиты. И только в x86-64 появился нормальный Flat Mode, подобный тому, что некогда был в i8080.

Veden12> Я себе очень плохо представляю Forth с разным размером адресов и данных (параметров).
Была бы нормальная ОС - хватило бы 64К кода. Даже для работы с большими блоками данных.
Просто в FOBOS меня взбесило, что половина памяти (все старшие 16 бит каждого адреса) - это все мусор. Получилась полная ерунда: примеры в 32-битной программе примерно влезают в 128К памяти, но если бы она была 16-битной, хватило бы и 64К, т.е. переход к большей размерности определяется ростом потребления, вызванным увеличением размерности.
Veden12> Не иметь доступа ко всей памяти - печально.
Не надо думать за ОС.
Veden12> И только в x86-64 появился нормальный Flat Mode, подобный тому, что некогда был в i8080.
Так начиная с Win95 все прекрасно работает во Flat-32.

Gudleifr> Просто в FOBOS меня взбесило, что половина памяти (все старшие 16 бит каждого адреса) - это все мусор.
Признаться, у меня система лежит до границы в 4 Гб. Почти половина шитого кода - нули. Однако вызвать переполнение при математических операциях из-за ограниченной разрядности стало просто немыслимо. Даже если это операции с адресами. А если мне потребуется слить значение со стека сопроцессора в стек параметров или наоборот - и тут 64 бита окажутся не лишними.
Veden12>> Не иметь доступа ко всей памяти - печально.
Gudleifr> Не надо думать за ОС.
Тут есть две тонкости: во-первых, Форт-система в моём случае - сама себе ОС; во-вторых, я не рассчитываю на запуск абстрактных приложений, как ОС общего назначения - не дело это Форта.
Veden12>> И только в x86-64 появился нормальный Flat Mode, подобный тому, что некогда был в i8080.
Gudleifr> Так начиная с Win95 все прекрасно работает во Flat-32.
Big Real Mode? Когда возвращаются в Real Mode оставляя 32-битный сегмент? Беда в том, что BIOS в те времена оставался 16-битным. А значит - всё с нуля. Сегодня же ситуация изменилась в корне: имеем 64-битный BIOS, который грузит свои приложения (драйверы, загрузчики ОС) уже в 64-битном Flat Mode (Intel называет его x86-64 Long Mode). Не нужно никуда переключаться. На смену int 21h пришёл богатый набор 64-битных функций. Свои ужасы есть (куда без них?), но они не фатальные.

Veden12> Признаться, у меня система лежит до границы в 4 Гб...
Вот монстр-то...
Veden12> Big Real Mode? Когда возвращаются в Real Mode оставляя 32-битный сегмент?
Нет, Flat проще: все сегменты ставятся по 4Гб (с началом в 0) и все. Win32 делает вид, что берет себе 2Гб и честно отдает оставшиеся 2Гб программе.

Veden12>> Признаться, у меня система лежит до границы в 4 Гб...
Gudleifr> Вот монстр-то...
Зародыш менее 18К (основной словарь на базе F83, работа с плавающей запятой ANS94 и системный - инициализация, вызовы BIOS), а блоки дают столько же шитого кода, каков их размер. Это много?
Veden12>> Big Real Mode? Когда возвращаются в Real Mode оставляя 32-битный сегмент?
Gudleifr> Нет, Flat проще: все сегменты ставятся по 4Гб (с началом в 0) и все. Win32 делает вид, что берет себе 2Гб и честно отдает оставшиеся 2Гб программе.
Не слышал про такое. А код Win32 при этом можно было как-то вызвать?

Veden12> Это много?
Я так понял, что было взято хорошее железо (A) и F был реализован с максимальным КПД использования A. Но оправдывает ли это роскошество P? Ведь сам по себе такой F мало кому по средствам и потребностям.
Veden12> А код Win32 при этом можно было как-то вызвать?
Так я же говорю - это штатный (и самый рекомендованный) режим работы программ под Win32.
Трудности только с тем, что было похерено почти все межпроцессорное взаимодействие Win16. Каждое приложение считает, что в памяти оно одно. И даже DLL грузятся для каждого процесса, а не одно на систему.

Gudleifr> Я так понял, что было взято хорошее железо (A)
Железо устаревает и обновляется довольно быстро. UEFI - продуманная система. Полагаю, это всерьёз и надолго.
Gudleifr> и F был реализован с максимальным КПД использования A.
А вот в этом я не уверен. Если у Вас есть желание глянуть, могу прислать исходники. Мне интересно Ваше мнение. К сожалению, без поддержки терминала (нет ещё ввода/вывода) - лишь пакетный режим.
Gudleifr> Но оправдывает ли это роскошество P? Ведь сам по себе такой F мало кому по средствам и потребностям.
Это всего лишь инструмент. До P ещё очень далеко... Драйверы железа - вот основная проблема. Там нет особых секретов, но повозиться придётся.
Gudleifr> Каждое приложение считает, что в памяти оно одно. И даже DLL грузятся для каждого процесса, а не одно на систему.
Я правильно понял, что речь идёт о виртуальной памяти процесса?

Veden12> А вот в этом я не уверен. Если у Вас есть желание глянуть, могу прислать исходники.
Нет, уж. Forth, как Вы правильно писали, источник удовольствия. Так что, не дай бог, Вас напрягать дурацкими замечаниями. Да и времени почти нет.
(Как только что писал Forth-общение приятно сверхнизком и сверхвысоком уровне).

Veden12> Я правильно понял, что речь идёт о виртуальной памяти процесса?
Но он об этом не знает... Как писал наш коллега, там у Windows все достаточно сложно, вплоть до горячего переключения сбойных банков памяти.

Gudleifr> Так что, не дай бог, Вас напрягать дурацкими замечаниями. Да и времени почти нет.
Понимаю. Всё равно - спасибо. И отдельное спасибо за Вашу страничку - очень много ценной информации.
Gudleifr> Как писал наш коллега, там у Windows все достаточно сложно, вплоть до горячего переключения сбойных банков памяти.
Серьёзный подход. Я полагал, это функция контроллера памяти. Но для ОС это плюс, конечно.

Все забывал рассказать этот анекдот.
Как известно, наиболее распространены два вида непонимающих-Forth:

• МИКРО-ФОРТЕР - фортер, считающий что Forth существует только в тех узких рамках, в которых он его понимает (обычно - в рамках стековой машины с шитым кодом). Следовательно, можно создать некое Forth-ядро (виртуальную Forth-машину), которую можно будет продавать любым Forth-программистам даже без объяснения внутреннего устройства.
• СТРУКТУРНЫЙ ФОРТЕР. Тоже верит в незыблемость понятия виртуальной Forth-машины. Однако, считает, что Forth есть нечто большее - а именно, структурное расширение этого "ядра" до размеров "обычного" языка программирования высокого уровня.

Их объединяет два постулата веры:
1. Написание своей Forth-системы есть не упражнение примерно уровня Этюдов Уэзерелла, но серьезное коммерческое предприятие.
2. Forth-система может быть достаточно серьезной и универсальной, чтобы на ней можно было "серьезно программировать", не вкладывая более ничего в развитие самой системы.

Но, вернусь к анекдоту.
Некие "серьезные манагеры" задумали приподняться путем участия в конкурсе по созданию серьезного девайса с Forth-начинкой. Чтобы не называть имен, пусть это будет условный космический корабль.
И, вот, через считанные недели после запуска проекта Forth-программист начал радостно рапортовать: "Уже почти готово! Вот-вот полетит!"
Не полетит.
Ибо допущены четыре ошибки:
1. Строя девайс, контактирующий с внешней средой, надо исходить из того, что он должен на эту среду реагировать. Подход: "Добавим чугуния и пофигу нам законы физики!"- не работает почти никогда. Правда, когда ребята заявили, что корпус девайса заказан в просвещенной Атавии, я, было воспрял духом, подумав, что купят достаточно летающую саму по себе вещь, которой надо только пальцем направление телепортации показать... Но, оказалось, что речь только о углепластиковой болванке, сделанной по "нашим эскизам" - картинке из старого журнала.
2. Ни один уважающий себя фортер не скажет: "Я пишу на Forth",- он скажет: "Я написал язык, на котором задача достаточно легко (при наличии у пользователя высшего инженерного образования) может быть описана".
3. Наш форто-демиург выложил даже скриншоты, показывающие лихие (под острым углом) повороты девайса: "Смотрите, как работает!" Очевидно, что так не бывает. Рыскание, помехи, обратная связь и прочие нюансы девайсо-вождения не могут не подпортить эту "геометрию". Лажа, однозначно.
4. Есть и скриншоты самой аппаратуры. И опять прокол - нет и следа "космического исполнения". А любой, имеющий дело с ВПК инженер скажет, что пока конструктора свое веское слово не сказали, вся электронная/программная начинка - тьфу.

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

Вот это я и называю тем "Непониманием", которое вынес в заголовок темы.

На Филиале Кошачьего Форума опять случился анекдот.
Вопрос:

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

 

Ответ:

1. 256 CELLS CONSTANT /UserStack
2. CREATE UserStack /UserStack ALLOT
3. VARIABLE UserStackPointer
4.  
5. : >UserStack   \ ( x -- )
6.   UserStack UserStackPointer @ CELLS + !
7.   UserStackPointer 1+!
8. ;
9.  
10. : UserStack>   \ ( -- x )
11.   -1 UserStackPointer +!
12.   UserStack UserStackPointer @ CELLS + @
13. ;

Отрадно, что на FORTH можно почти понятно и почти удобно написать

1. int us[256], usp;
2. ...
3. us[usp++] = a;
4. ...
5. a = us[--usp];

Но зачем тогда FORTH? Где краткость и удобство?
В том-то и дело, что на FORTH нельзя спросить: "Как сделать стек?" Нужно сначала выяснить, какого размера стек, что в него пишем, для чего он нужен?
Например, здесь: "сортировка". Что сортируем, каков объем, по какому алгоритму..? Все получившиеся "стеки" ДОЛЖНЫ быть разными! (Например, возможен строковый стек, тупо размещаемый в словаре).
Я даже прикинул, что, если идет речь о быстросорте, то и обычного стека вполне достаточно...
Хорошо не встрял...

Оказалось, все проще и страшнее.
Спрашивающий реализовывал сортировку пузырьком, гоняя весь массив из одного стека на другой с перестановкой соседей...
Всю эту конструкцию загнал в одно слово.
И когда исправит все ошибки, вполне вероятно это будет работать.
И это FORTH?!
В чем выигрыш? В введении слов >UserStack и UserStack> ?
И еще спрашивают, почему на нем не пишут?
Если писать ТАК, то, действительно, незачем...

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

1. Если данные на стеке, то естественно их оттуда брать по одному. Следовательно, сортировать деревом...
2. Где размещать дерево? Как где? В словаре. Не надо никаких ALLOT. Тупо обращаемся со всей памятью после HERE, как с массивом троек "число-меньшие-большие". Никакой очистки после решения, очевидно, тоже не требуется.
3. Надо ли проверять DEPTH при вытаскивании данных из стека? Если у нашей системы есть проверка на исчерпание стека - то нафиг не надо. Само рухнет. Дерево-то останется целым в словаре...

Ну, после HERE немного отступить... Ну, дерево не так хранить... Главное - как удобнее, а не "как у всех"... Сделали - и забыли... В следующий раз - по другому сделаем.

А вот этого я сам не понимаю.

Где проходит граница между FORTH и не-FORTH?

Попробуем реализацию машины "из коробков" Д.Мичи (воспетую Гарднером и Саберхагеном).

Машина, предназначенная для игры в простые игры - шашки 4*4, крестики-нолики, Баше, лабиринт - состоит из коробков с разноцветными бусинами. Каждый коробок соответствует некой игровой ситуации. Цвет бусины соответствует варианту поведения (ходу) машины. Сеанс игры соответствует в случайном выборе бусин. Если машина выигрывает - в сыгравшие коробки добавляются бусины, того цвета, который был выбран. Если проигрывает - сыгравшие бусины удаляются (добавляются бусины других цветов).
Через несколько партий машина научается играть.

FORTH-реализация вполне может состоять в создании слов-коробков.
КОРОБОК создается автоматически при появлении в игре новой комбинации.

При создании в каждый коробок прошивается столько слов-БУСИН, сколько возможно вариантов:
СТАРТ LIT e1 LIT k1 БУСИНА LIT e2 LIT k2 БУСИНА ... LIT eN LIT kN БУСИНА ФИНИШ EXIT
где

1. : СТАРТ IP>ИГРОСТЕК 0 0 ;
2. : БУСИНА  ( e k eI kI -- e' k+kI)
3.    ROT OVER + ВЫПАЛО? IF ROT ELSE SWAP THEN DROP ;
4. : ФИНИШ DROP DUP >ИГРОСТЕК EXECUTE ;

ИГРОСТЕК используется для запоминания сыгравших вариантов.
IP>ИГРОСТЕК - запоминает в в ИГРОСТЕКЕ адрес первого LIT в КОРОБКЕ.
kI - число бусин.
eI - адрес процедуры хода.
ВЫПАЛО? ( k1, k2 — k2, f) выдает TRUE c вероятностью k1/k2 (в случае k2 == 0 - TRUE).
Обучение состоит в прохождении ИГРОСТЕКА, заполненного парами КОРОБОК-e1, и соответствующем измененении kI.

Можно конечно хранить коробки в честных списках, вынеся за пределы шитого кода.
Получится гораздо короче (LIT-ы и БУСИНЫ уйдут, останутся только пары eI-kI).
По сути, это просто выбор между прямым и косвенным шитым кодом.
Ведь список пар eI-kI - именно косвенный шитый код.

P.S. Внезапно. А ведь слово "!" - компилирующее. Оно пишет не "код", а "данные"? А FORTH-у не пофиг?!

Balancer> Чтобы понять логику условных блоков Форта, нужно выкинуть ELSE.
Проще выкинуть все, что мы знаем об if...then...else...
И попытаться понять, что такое "оборот в шитом коде" - код, который читает следующие за ним коды в обход интерпретатора шитого хода.
там и далее.

Вот, кстати, изумительный юмористический пример "Непонимания": сайт "Каким должен быть язык программирования?" - "Почему обречён язык Форт".
Кажется, кому не порассуждать о "метасвойствах метаязыка", как не человеку, открывшему сайт о поиске "идеального языка программирования"? В конце концов, из подобных лингвистических рассуждений и Perl когда-то появился.
Однако, современный "лингвист" языкам не обучен...