Что не хватает Форту?

 
1 9 10 11 12 13 14 15

Veden12

втянувшийся
Gudleifr> Мне вообще кажется странным, что рабочие станции имеют свой универсальный процессорный блок.
Мне тоже.
Gudleifr> С другой стороны, вот сейчас пишу на ноуте, у которого вот-вот кончится батарейка, причем львиная доля заряда ушла на запуск Windows (т.е. читай - на поднятие всех возможных драйверов). Так что какая-никакая гибкость пока нужна...
Батарейка – расплата за то, что при установке/конфигурировании сразу не собирается оптимальное ядро. На Андроиде это возможно. Но и там дальше этого не пошли. Хотя обычно используются одни и те же приложения, оптимальную для них логику управления не компилируют. Идеология UNIX – священна.

Gudleifr> Зачем мы тогда ее обсуждаем? Посмотрите, например, у Брукса...
Спасибо, гляну.
То, что я предлагаю (каждый сам по себе, что вышло – публикует для других), строго говоря, схемой разработки не является. У разработки есть цель – конечный продукт, отлаженный. Здесь он у каждого свой. Быть может, недоделанный. Причём это абсолютно не важно. Это игра. Важен процесс, цель – условность, не более. Я лишь предлагаю наиболее эффективный из известных семи способов разрешения конфликтов, так или иначе возникающих в ходе разработки (и не только).

Veden12>> А вот компиляция ветвлений выглядит красиво.
Gudleifr> Как?
Машинные коды переходов вкомпилированы в шитый код. Для 64-битной системы это выглядит ещё веселее: 32-битный относительный адрес перехода можно вкомпилировать в старшие байты того же значения, что содержит инструкцию перехода. Аналогично, можно в код DO спрятать адрес для LEAVE.

Kopa> В IForth не помню, но стек данных реализован на стеке процессора.
Странно, что в SPF на стек процессора повесили стек возвратов.
И ещё. Поправьте меня, пожалуйста, если неправ, но на современных процессорах ROT быстрее всего выполняется парой XCHG (вершина стека – в регистре).

Balancer> Intel выпустит новый процессор
Интел впилил в процессор графическое ядро (матричный процессор). Учитывая, что это было ответом на CUDA, наверняка его можно использовать и в лоб. Осталось понять: Как?
Вероятно, ответом на вопрос "Что это значит для Форта?" будут исходные тексты под матричный форт-процессор GA144 и подобные.
 33.0.1750.15433.0.1750.154
RU Balancer #22.03.2014 13:49  @Gudleifr#22.03.2014 10:31
+
-
edit
 

Balancer

администратор
★★★★☆
Gudleifr> Мне вообще кажется странным, что рабочие станции имеют свой универсальный процессорный блок. Проще иметь свой личный наладонник, который по потребности можно прицеплять к

См. полную концепцию Asus Padfone:






Но эта, считаю, неправильная. И не приживётся :) Потому что глупо получится — уйдёшь ты с телефоном на работу, а как ребёнку мультик посмотреть или жене поработать с документами? И это при том, что чисто вычислительная начинка (процессор-память) сегодня стоит копейки. Достаточный по производительности для домашней станции HDMI-stick с Андроидом уже не первый год меньше $50 стоит:

MK908 RK3188 Quad Core Android 4.2.2 Mini PC TV Box 2G RAM 8G rom Bluetooth 4.0 tv dongle Google TV Free Shipping-in Consumer Electronics on Aliexpress.com

Cheap tv box, Buy Quality tv smart android box directly from China tv box hd Suppliers:MK908 RK3188 Quad Core Android 4.2.2 Mini PC TV Box 2G RAM 8G rom Bluetooth 4.0 tv dongle Google TV Free Shipping  // www.aliexpress.com
 

(этот чуть дороже $50, искать лениво, указал первый попавшийся).

А вот на что стоит делать упор — это на простоту и эффективность обмена данными, на протоколы. Для медиаданных уже есть почти идеальное решение, DLNA (UPnP). И оно работает почти всюду. Я могу прийти в гости к товарищу и в пару кликов на телефоне показать на большом экране фотку, сделанную по пути или залитый из дому на телефон фильм.

Gudleifr> С другой стороны, вот сейчас пишу на ноуте, у которого вот-вот кончится батарейка, причем львиная доля заряда ушла на запуск Windows (т.е. читай - на поднятие всех возможных драйверов)

Это странно. Windows сегодня очень эффективно относится к заряду. И уж тем более, загружать её приходится раз в месяц (грубо говоря, зависит от частоты и необходимости автообновлений). Я под Linux на ноуте так и не смог добиться такого же времени работы, как под Win7 (5.5 часов под Linux против 6 часов под Win7).

Gudleifr> Во-во, и зарядка от одного телефона к другим не подходит...

Сегодня все нормальные телефоны заряжаются от micro-USB. И это уже не одно поколение так. У меня сейчас 5 из 6 гаджетов заряжаются именно через этот разъём. Правда, на планшете — свой разъём. Но! Со стороны розетки кабель оканчивается там же USB. Так что все мои зарядки одинаковые. Все — с USB-выходом :) Даже аккумуляторы к геймпадам Xbox заряжаются от кабеля, втыкающегося в USB.
 33.0.1750.15433.0.1750.154

Balancer

администратор
★★★★☆
Kopa> Прикол в том что и "удвоение" процессора оказалось недостаточно или чего то ещё

Ну, не знаю... Развитие, конечно, отчасти пилообразное, в среднем тренд показывает на серьёзное ускорение работы. Сейчас, когда ОС с нуля загружается 5..15 секунд, а просыпается мгновенно, когда страницы сайтов, открывающиеся больше секунды считаются тяжёлыми и тормозными, когда софт, запускающийся больше пары секунд вызывает недоумение «а он, вообще, работает?» кажутся нереальными воспоминания из прошлых лет, когда быстрой загрузкой ОС считалось 40 секунд, а раздражаться народ начинал, если система грузилась дольше пары минут. Запуск программы за 15..20 секунд считался нормальным. Открытия страниц сайтов ждали, порой, минуту... Нет, чтобы ощутить всю прелесть прогресса, иногда полезно достать девайс 1990-х годов и поработать немного на нём :D У меня так до сих пор IBM Thinkpad 560X валяется. И Toshiba Libretto недавно отдал даром :)
 33.0.1750.15433.0.1750.154
+
-
edit
 

Balancer

администратор
★★★★☆
Veden12> Интел впилил в процессор графическое ядро (матричный процессор). Учитывая, что это было ответом на CUDA, наверняка его можно использовать и в лоб. Осталось понять: Как?

Для меня этот вопрос был актуален в свете майнинга криптовалют. «Знающие люди» сказали, что идея совершенно бесполезная. Типа, встроенный GPU там не отдельный, а использует те же процессорные мощности. Так что выигрыша по сравнению с генерацией на чистом CPU нет. Фактически это старый софтовый рендеринг, только сделанный в железе :)
 33.0.1750.15433.0.1750.154
+
-
edit
 

Veden12

втянувшийся
Balancer> «Знающие люди» сказали, что идея совершенно бесполезная. Типа, встроенный GPU там не отдельный, а использует те же процессорные мощности. Так что выигрыша по сравнению с генерацией на чистом CPU нет.


Как видно, у каждого – свой кэш. Общий лишь доступ к внешней памяти.

Balancer> Фактически это старый софтовый рендеринг, только сделанный в железе :)
Сегодня есть только один способ получить текстовой режим "байт на символ": запустить эту бетономешалку :) Конвейер рендеринга трижды проходит через матрицу унифицированных "шейдерных процессоров". NVidia сделали эту матрицу открытой для вычислительных задач (никакого GPGPU). Intel, полагаю, тоже. Вот только документации о том, как достучаться до неё, я не нашёл, увы. Странно. Не похоже на Intel.
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

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

Veden12> Причём это абсолютно не важно. Это игра. Важен процесс, цель - условность, не более.
Я окончательно запутался.

Veden12> Странно, что... на стек процессора повесили стек возвратов.
Рассуждать можно, например, так: при оптимизации критических кусков, последние переписываются в кодах, передача данных через стек не используется. А рекурсия - вещь постоянная.

Правильный ответ в данном случае: оптимизировать стек данных нет никакого смысла. FORTH-у он глубоко параллелен, его вообще может не быть. Нужен "стек ввода" - место накопления еще не обработанных данных из потока. Его использование для вычислительных нужд - удобное упрощение и не более. Можно, например, вычислять и в стеке вещественных/упакованных, в регистрах, в специальных массивах...
Более того, т.к. ввод из потока - штука медленная, то и скоростной стек ввода не нужен...
 27.027.0
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Где провести границу между Unix и Андроидом, я затрудняюсь.
Есть такая граница. Вот только проходит она не по вертикали, а по горизонтали. Всё есть UNIX. Для Microsoft – начиная с Windows NT, для Apple – начиная c NeXT. Ну а FreeBSD, Linux'ы разного разлива (включая Андроид) – откровенные реализации всё той же концептуальной модели UNIX. Что ещё тут можно сказать, если организация любой успешной ОС – калька с UNIX'а?
Gudleifr> Так, что мы, скорее, всего имеем желание одинаково плохо удовлетворить желание всех. Одно хорошо - обрезать можно по самое некуда.
Вот это самое желание осчастливить всех и делает UNIX UNIX'ом: «когда в руках молоток, все проблемы кажутся гвоздями». Отрежем его – не будет UNIX'а. Получим экзоядро. Но этого мало. Надо ещё чтобы загрузка ОС до работоспособного состояния была подобна загрузке BOOT-сектора.

Gudleifr> Правильный ответ в данном случае: оптимизировать стек данных нет никакого смысла. FORTH-у он глубоко параллелен, его вообще может не быть.
Если имеется несколько уровней вложенности вызовов слов и мне нужно передать данные сразу нескольким словам, вызывающим друг друга, то любая структура данных так или иначе сведётся к стеку. Вы предлагаете загнать всё в стек возвратов?
Gudleifr> Нужен "стек ввода" - место накопления еще не обработанных данных из потока.
Если я правильно понимаю, это уже будет очередь или даже кэш – как мне кажется, слишком низкоуровневая структура, чтобы её можно было бы рассматривать применительно к любому языку программирования.
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Если имеется несколько уровней вложенности вызовов слов...
Veden12> Если я правильно понимаю, это уже будет очередь...
Нет, именно, стек. Посмотрите обоснование у Дейкстры. Вы путаете три вещи:
1. обеспечение вложенности, рекурсии - стек возвратов
2. накопление ввода - стек ввода (данных)
(эти два нужны FORTH-системе)
3. обмен данными между словами - зависит от проблемно-ориентированного языка. Использование для этого стека данных - очень частный случай.

Речь не о том, где будут жить DUP и SWAP, а о том, что они, часто, вообще не нужны.
 27.027.0
Это сообщение редактировалось 23.03.2014 в 12:03

Kopa

новичок

Gudleifr> 3. обмен данными между словами - зависит от проблемно-ориентированного языка. Использование для этого стека данных - очень частный случай.
Gudleifr> Речь не о том, где будут жить DUP и SWAP, а о том, что они, часто, вообще не нужны.
Если "абстрагироваться" от возможности прямого управления "межпроцедурным местом накопления данных" то это уже будет больше похоже на Лисп, но и там списком тоже "рулят". Можно и в Форте обходится без DUP, SWAP, OVER ... используя механизм локальных и глобальных переменных как в большинстве существующих языков, а стоит ли? Стек в Форте это свой способ при создании кода, и оперирования "значениями" ячеек, также как в Лисп списки или предикаты Пролога. Может в Форте не хватает синтаксического сахара?

P.S. DUP, например это вполне понимаемая операция резервирования ещё одной копии ячейки. Оптимизатор это отмечает и знает сколько времени будет актуально значение данной ячейки и где оно было отмечено (грубо)
 
Это сообщение редактировалось 23.03.2014 в 16:05

Gudleifr

втянувшийся

Kopa> Если "абстрагироваться" от возможности прямого управления "межпроцедурным местом накопления данных"...
Не надо ни от чего абстрагироваться...
Есть стек возвратов и стек ввода. Они необходимы FORTH для работы.
Если возникает необходимость "где-то что-то сохранить" можно ими воспользоваться,.. но можно и не пользоваться.
Например:
1. Вычисления в стеке ввода (ну тут все очевидно, поэтому мы и предпочитаем называть его стеком данных). Иногда, даже, его "стековая сущность" удобна для вычислений (см., например, мое решение задачи о переправе).
2. Вычисление частично в стеке ввода. Те же WORD и FIND. Адрес слова и флаг IMMEDIATE идут через стек, а само слово - через словарь (тоже, по сути, стек).
3. Вычисление в стеке возвратов - тот же DO ... LOOP.
4. Вычисление в специальном отдельном стеке - стек приоритетов при обработке инфиксной арифметики.
5. Вычисления "где-то рядом". Пример Мура (проблемно-ориентированного языка) для работы с таблицами БД, где все шло через промежуточный файл.
И т.д., и т.п...
 27.027.0

Kopa

новичок

Gudleifr> И т.д., и т.п...
По моему всё перечисленное немного надуманные проблемы.
И что и где вычислять Форт особо не ограничивает
Gudleifr> 4. Вычисление в специальном отдельном стеке - стек приоритетов при обработке инфиксной арифметики.
А зачем? Можно же добавьте к языку поддержку инфиксной записи на уровень трансляции до использования инфиксных выражений.

P.S. Есть же статистика использования в реальных програмах слов "перестановки" ячеек стека и вроде не сильно плохая и при программировании задачи не так их и обременительно использовать. Локальные переменные не часто встречаются в программах на Форт.
 

Gudleifr

втянувшийся

Kopa> И что и где вычислять Форт особо не ограничивает
Именно! И стек ввода - только "один из".

Kopa> А зачем? Можно же добавьте к языку поддержку инфиксной записи на уровень трансляции до использования инфиксных выражений.
Как бы классика. Обоснование можно посмотреть у Мура - он там предлагал подобные "арифметики" использовать и для других целей.
А трансляция? Думаете она не будет использовать дополнительных стеков? Как бы, деревья грамматического разбора предрасполагают...

Kopa> P.S. Есть же статистика использования в реальных програмах слов "перестановки" ячеек стека и вроде не сильно плохая и при программировании задачи не так их и обременительно использовать.
А кто-нибудь видел на FORTH задачи, требующие сложной обработки данных? Как бы, даже, простейшие задачи (та же задача переправа) на кошачьем форуме аукаются применением языка файловых манипуляторов...
 27.027.0

Kopa

новичок

Gudleifr> А кто-нибудь видел на FORTH задачи, требующие сложной обработки данных?
Насколько сложных и какой области? Мульти-сервер Eserv сложно? (nncron?)
Существующий базис Форт кода-библиотек достаточно разнообразный (есть и БНФ и регепсы и также обработка XML, не упоминая даже базу математических алгоритмов) было бы желание использовать.
Списки вроде на любой вкус, бектрекинг. А также возможность подключить сторонние библиотеки.
Тузов на Win32Forth построил систему лингвистического анализа языка (SemLP) вот только где и кто опубликует исходники. Один Растановщик ударений написан на SPF4.

P.S. Что всё таки не хватает Форту? :)
 
Это сообщение редактировалось 23.03.2014 в 17:05

Gudleifr

втянувшийся

Kopa> Насколько сложных и какой области? Мульти-сервер Eserv сложно? (nncron?)
Kopa> P.S. Что всё таки не хватает Форту? :)
Ответ на оба вопроса один. Не хватает сложных задач. Т.е. задач, которые бы окупили написание FORTH специально для их решения.
 27.027.0
+
+1
-
edit
 

Kopa

новичок

Gudleifr> Ответ на оба вопроса один. Не хватает сложных задач. Т.е. задач, которые бы окупили написание FORTH специально для их решения.
Нету заказчиков на решение задач на Форт, кроме самих Форт пользователей языка.
А будут ли они и смогут ли решать сложные задачи на энтузиазме?
Или видим его базу в "академических" учереждениях или не видим кто, что и как его использует кроме разных "островков".

P.S. Чтобы сказал на это Хищник :)
 
Это сообщение редактировалось 23.03.2014 в 17:28
+
+1
-
edit
 

Gudleifr

втянувшийся

Kopa> Нету заказчиков на решение задач на Форт, кроме самих Форт пользователей языка.
Что значит "на Форт"? Например, если Вы напишете микроядро FORTH на С и остальная задача будет на нем...
Просто, мы привыкли к неким парадигмам программирования. Например, типичная программа "на C++" - это обычно C-программа с комментариями "через 2 косых" и классами вместо структур (в худшем случае - с жуткими наследованиями из библиотечных классов). Вот - конструктор главного окна, вот - по файлу-форме на все остальные окна... Считать это программой "на каком-то конкретном языке" даже язык не поворачивается. Так и пишут, например, "Qt" - и сразу ясно, где что лежит, даже если Вы плохо знаете C++...
Область FORTH - построение проблемно-ориентированных языков. Нужен такой язык? Тогда Вы поневоле слепите что-то FORTH-образное, на любом языке, который под рукой. (Правда 'nix-ы ушли дальше и Вы сможете писать в их среде гораздо более замысловатые языки).
Минус FORTH - текстовый проблемно-ориентированный язык. Какой уважающий пользователь будет что-то набивать в консоли? Так что программист вынужден играть в это сам с собой. Но, опять же, FORTH, если к нему присмотреться, может читать и другие языки (язык кнопок, язык сообщений, язык пакетов)...

Так что главную проблему можно сформулировать так: "Прежде, чем исследовать границы применимости FORTH-метода, нужно определить FORTH как метод. А не как язык, систему, среду разработки..."
 27.027.0
+
-
edit
 

Veden12

втянувшийся
Gudleifr> 2. накопление ввода - стек ввода (данных)
Как Вы себе представляете накопление ввода? Почему для ввода обязательно нужен стек?
Gudleifr> Речь не о том, где будут жить DUP и SWAP, а о том, что они, часто, вообще не нужны.
Если они не реализованы в железе.

Kopa> P.S. Что всё таки не хватает Форту? :)
Фантазии, IMHO. Как всегда, все стараются сделать на Форте то, что уже есть. Другое, но есть. Поэтому то, что выходит, никому не нужно. Разве KolibriOS – плохая система? Просто она не предлагает ничего нового.

Gudleifr> Минус FORTH - текстовый проблемно-ориентированный язык. Какой уважающий пользователь будет что-то набивать в консоли?
Если Форт – метод построения проблемно-ориентированных языков, то среда разработки зависит от того, с какого уровня начата разработка. Если слова Форта достаточно высокого уровня, то можно создать под это дело разного рода визуальные среды (скорее проектирование, чем программирование). Если же основание разработки предельно низкого уровня, то наиболее удобной будет текстовая среда. Те редакторы, что я видел, функциональны по минимуму (нужен библиотекарь, поддержка разных типов данных, стеки в реальном времени, а иногда картинка памяти). Кроме того, их удобство оставляет желать лучшего. Да, у каждого своя реализация Форт-системы. Но, насколько я могу судить, наиболее популярная – SPF. Для него нужен редактор и ролик с ним на YouTube. Одни будут приобщаться, другие при наличии исходников и конечного представления легко сообразят себе такой.
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Как Вы себе представляете накопление ввода? Почему для ввода обязательно нужен стек?
Стек достаточен для контекстно независимого интерпретатора (в общем случае). С одной стороны интерпретатор не обязан содержать в себе автомат, допускающий некую грамматику (мол, ввели номер строки, значит сейчас будет оператор, ввели оператор - ждем параметры...); с другой - не мешает такие псевдограмматические переключатели состояний создавать (я называю их оборотами, например, CREATE, и предложениями, например, IF ... THEN).

Veden12> Если они не реализованы в железе.
А зачем? Чтобы заранее себя ограничить?

Veden12> Если слова Форта достаточно высокого уровня, то можно создать под это дело разного рода визуальные среды (скорее проектирование, чем программирование).
Это как? Визуальные среды основаны на минимизации "словаря" (иначе программист не сможет отследить все возможные ситуации), а чем более высокоуровневый у нас FORTH, тем обширнее его словарь.

Veden12> Если же основание разработки предельно низкого уровня, то наиболее удобной будет текстовая среда.
Все зависит не от уровня A, а от уровня P.

И не надо путать проблемно-ориентированный язык с языком среды разработки.
 27.027.0

Kopa

новичок

Veden12> Разве KolibriOS – плохая система? Просто она не предлагает ничего нового.
Она пока что не предлагает ничего лишнего для "переусложнённого" создания прикладных программ и есть возможность при её разработке создать Операционную среду следующую принципу "минимаксимализма" А что и и в каком направлении дальше равитие пройдёт будет видно.

P.S. По возможностям для создания пользовательского софта уже Win95 была достаточна с несколькими своими "базисными" dll-ками. Хотя 95 и не шедевр осе строения. У разных пользователей и задач разные требования к наполнению Оси.

Забавная статья о минимаксимализме наводит на размышления.
 
Это сообщение редактировалось 24.03.2014 в 00:18
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Стек достаточен для контекстно независимого интерпретатора (в общем случае).
Понимаю. Как, Вы считаете, его следует реализовывать? Строки или уже шитый код?

Veden12>> Если они не реализованы в железе.
Gudleifr> А зачем? Чтобы заранее себя ограничить?
144-ядерный процессор Чарльза Мура поступил в продажу по $20 (не ново, впрочем): DUP/DROP, OVER.

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

Veden12>> Если же основание разработки предельно низкого уровня, то наиболее удобной будет текстовая среда.
Gudleifr> Все зависит не от уровня A, а от уровня P.
F начинает расти от уровня A до уровня P. Поэтому начальный язык разработки F = A. Разве нет?
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Как, Вы считаете, его [стек] следует реализовывать? Строки или уже шитый код?
Я не понял противопоставления "строк" и "шитого кода".

Veden12> 144-ядерный процессор Чарльза Мура поступил в продажу...
И что? FORTH в железе - это просто отмазка для неудачников. Есть железо, которое может "почти все", а мы, чтобы не мучиться обоснованием всяких пределов вычислимости, реализуем в нем то, что идет на ЛЮБОМ железе. Ведь, для всяких, LISP-, SmallTalk-, Prolog- и, даже, Okkam-машин - думать надо...

Veden12> Визуальные среды нужны, в первую очередь, для заточки виджетов и программирования их поведения.
Т.е. сами для себя. Но, ведь, и полезный выход хочется иметь...

Veden12> F начинает расти от уровня A до уровня P. Поэтому начальный язык разработки F = A. Разве нет?
Нет, F еще надо создать: написать процедуры СИМВОЛ (EXPECT, WORD, FIND, NUMBER), ВЫПОЛНИТЬ, КОМПИЛИРОВАТЬ, СЛЕДУЮЩИЙ (NEXT), ОК и определиться с видом структур ПОТОК, ЗНАЧЕНИЕ, СТЕК, СЛОВАРЬ. И, самое главное, когда FORTH-машины начинают усложняться, решить, "через что они объединяются" (обычно - СЛОВАРЬ).
 27.027.0

Veden12

втянувшийся
Kopa> ...есть возможность при её разработке создать Операционную среду следующую принципу "минимаксимализма" А что и и в каком направлении дальше равитие пройдёт будет видно.
Развитие KolibriOS будет видно только если будет видно её саму. А пока что это "неуловимый Джо".
Принципу "минимаксимализма" следуют все ОСи. Это нужно им, чтобы удержаться на рынке. Но чтобы захватить рынок – Вы должны нарушить этот принцип, выбить пол из-под пользователя.

P.S. Не думаю, что Вы знаете маркетинг хуже меня. Не стану цитировать Джобса и Талеба. Но Вы же понимаете: Сегодня нет задач, решаемых только на Форте. Однако, их можно придумать.
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Но Вы же понимаете: Сегодня нет задач, решаемых только на Форте. Однако, их можно придумать.
Почему?! Такая задача давно придумана: изготовление почти универсальных процессоров с минимумом усилий на разработку. И соответственно - попытка этакое изделие применить.

P.S. Я знаю еще одно применение: программирование в очень неблагоприятной среде (например, мой проект FOBOS), но я не знаю, решаема ли эта задача в принципе.
 27.027.0
Это сообщение редактировалось 24.03.2014 в 15:50
+
-
edit
 

Veden12

втянувшийся
Gudleifr> Я не понял противопоставления "строк" и "шитого кода".
Вводимые пользователем слова должны помещаться в стек для обработки в обратном порядке. Верно? Но что должно быть в стеке? Ссылки на хранимые где-то последовательности символов (исходные слова) или адреса слов в словаре, числовые значения с предшествующим кодом обработчика (готовый шитый код)?

Gudleifr> Почему?! Такая задача давно придумана: изготовление почти универсальных процессоров с минимумом усилий на разработку. И соответственно - попытка этакое изделие применить.
Это просто игрушка. Хотя... Если такую вот пластинку кремния использовать в робототехнике. И сделать не какой-нибудь спутник или луноход (кому это сегодня надо?), а серьёзную конструкцию – для приготовления яичницы-глазуньи и подачи кофе в постель (не буквально :) ) – тогда да, это способно потрясти основы нашей цивилизации (а тут мне уже совсем не смешно).

Gudleifr> P.S. Я знаю еще одно применение: программирование в очень неблагоприятной среде (например, мой проект FOBOS), но я не знаю, решаема ли эта задача в принципе.
Признаться, я не смог соотнести "текстовое представление бинарных кодов" и "полная свобода просмотра и редактирования кода пользователем". Зачем выкладывать код ядра? Либо человек не захочет развивать Вашу систему (и код вместо исходников лишь подтолкнёт его в этом направлении: вдруг Вы измените что-то в ядре и вся его работа насмарку), либо захочет (а в этом случае он почти наверняка дружит с дизассемблером). С другой стороны, быть может, Вы хотите таким образом зафиксировать ядро? Похоже, я половину не понял, а вторую половину – понял неправильно :)
 33.0.1750.15433.0.1750.154
+
-
edit
 

Gudleifr

втянувшийся

Veden12> Вводимые пользователем слова должны помещаться в стек для обработки в обратном порядке...
Понял. Стек накапливает "символы" (в смысле Машины Тьюрингка), "распознанные лексемы" (в смысле программ-парсеров)... Зачем же мы их распознавали? Т.е. в случае слов - их адреса (кстати, это тоже самое, что и ссылки на строки, т.к. последние хранятся в статьях словаря). Числа хранятся "просто как числа". Это одна из краеугольных идей - ячейка может содержать все сущности, потребные системе. Возможно применение тегов типа и/или "символов"-ограничителей...
Хранить адреса исполнения слов или адреса статей? С одной стороны, для оптимизации (и обоснования FORTH как компилятора) удобно первое, с другой - хранение адресов слов на стеке в обычных FORTH-системах используется крайне редко (обычно они исполняются/компилируются "не дойдя" до него). Дело вкуса. Мур, например, сначала предлагал и в шитом коде хранить ссылки на начало статей, а не адреса кода.

Veden12> Это просто игрушка...
Да, нет, люди деньги делают. И сам Мур - во главе. Сами же ссылались.

Veden12> Признаться, я не смог соотнести "текстовое представление бинарных кодов" и "полная свобода просмотра и редактирования кода пользователем".
Соотносится просто - хошь скачивай и ставь (дамп), хошь скачивай и читай (исходник), хошь скачивай, правь и ассемблируй (тоже исходник). Как бы, обычно все приложения с исходниками так и выкладываются.

Veden12> Зачем выкладывать код ядра? Либо человек не захочет развивать...
Задача развития "человеками" не ставилась. Изначально целью было "организовать раздачу работающих программных иллюстраций к моей страничке в условиях ограничений хостинга"... Отсюда постепенно вылезла вторая: "организовать удобный программистский интерфейс к Win-API". А когда "удобного интерфейса" сразу не получилось, главной целью стало "выяснить, чего я не понимаю в FORTH, что не дает достичь предыдущей цели".
 27.027.0
Это сообщение редактировалось 25.03.2014 в 10:58
1 9 10 11 12 13 14 15

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru