Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт мар 19, 2024 10:56

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - 3-х стековая виртуальная машина. размышления.
Автор Сообщение
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
Цитата:
не поверишь, их таки больше двух.
У меня постоянно используется 4-е низкоуровневых(определенных на асме) и два и более, ээ, других в общем.


Поверю, в Нове их 5: данные, возвраты, плав.точка, контекст, окружение. Разговор о том, что тяжелей их использовать совместно в одном зрительном пространстве.

Навряд ли встречается что-то вроде:
DUP >R ALSO CONTEXT ! R@ >A F@ EXECUTE SWAP A>

Короче, смешение с потерей смысла.
Цитата:
и это говорит о том, что работу на стеке (обычную, нормальную) вы просто не освоили 8(
и стиль у вас неудачный. имхо.


Вот залез и посмотрел в свои наработки. Всё пучком. :D

Цитата:
Я пока придерживаюсь мнения, что по мере освоения Форта стековых манипуляций у программистов становится все меньше и меньше. Поэтому и потребность в упрощении стековых манипуляций уменьшается естественным путем.

Ну, так оно и есть. Насчёт стековых манипуляторов.
вот 0/1#11&<1^ это аналогично R> @ >R , только в первом случае стек данных не участвует. Вот и меньше трогаем стек данных.
Вот резервирование места в стеке возвратов под, хм, дострой строки 0/3#R0-3^
аналог на форте примерный: DUP R> OVER RP@ - RP! >R
А здесь снятие этого выделения и смещения указателя в стеке окружений на новую строку 1/2#R0+2^0i01+0
Что-то по общеупотребительней, хм: 3/B1&3..?(1&2..<)1i0dU код для замены одного символа другим в строке
И асм не напрягаем.

Короче, это инструмент для оптимизации по скорости и по наглядности (да-да, надо учиться) кода. Только и всего и нужен он, естественно, не везде, а лишь в отдельных случаях.
Сообщение Добавлено: Вс мар 11, 2018 23:29
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
Victor__v писал(а):
Вспоминаем комбинаторику.
2 стека - 2 варианта взаимодействия (2!=2) , 3 стека 6 вариантов взаимодействий (3!=6) и т. д.

И тут не совсем верно. Т.к. появляются запрещенные перемещения и операции.
И, все-таки, говорить что-то, стоит сначала разобравшись 8)

Victor__v писал(а):
А ежели в форте постоянно, непрерывно, используются более 2-х стеков?

не поверишь, их таки больше двух.
У меня постоянно используется 4-е низкоуровневых(определенных на асме) и два и более, ээ, других в общем.
И я не путаюсь, т.к. они совсем разные.

Victor__v писал(а):
Шо? Кто против стековых комбинаторов?

я против 8)
дичайшая вещь.

Victor__v писал(а):
На счёт стекомахания. Бывают просто такие ситуации.
В обычной практике далее связки SWAP ROT заходить не приходится

и это говорит о том, что работу на стеке (обычную, нормальную) вы просто не освоили 8(
и стиль у вас неудачный. имхо.
Сообщение Добавлено: Вс мар 11, 2018 21:05
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
Victor__v писал(а):
Шо? Кто против стековых комбинаторов?
Это DSL для более эффективного (в плане быстродействия) по сравнению с фортом кода. К примеру, нужно сделать в одном месте какое-то действие (лень лезть в свои исходники в поисках примера). На форте это вылилось бы в лишнее стекомахание, а тут тишь да гладь.

Я пока придерживаюсь мнения, что по мере освоения Форта стековых манипуляций у программистов становится все меньше и меньше. Поэтому и потребность в упрощении стековых манипуляций уменьшается естественным путем.
Victor__v писал(а):
Насчёт попроще, это явно диверсия. Они посложнее форта, особенно в моей реализации.

Именно. И раз нет явной волны запросов на стековые комбинаторы, автоматически встает вопрос, а нужно ли добавлять вещь, обязательную к реализации. Для меня резко снижается привлекательность наработок, если я знаю, что их автор может заявить "а вот тут я поставлю слово, которое мне нравится, и без него делать не буду, а слово мне нужно, чтобы обосновать редкую вещь, которая не во всяком Форте есть". Из той же серии совсем уже бредовые заявления Максимова "отдам библиотеки только за криптовалюту". Может еще в Oriflame торговым представителем надо зарегистрироваться? :D
Сообщение Добавлено: Вс мар 11, 2018 20:57
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
Hishnik писал(а):
Вон и стековые комбинаторы что-то не показывают победного шествия. Я не имею в виду примеры кода, "которые работают же!". Я имею в виду объективную статистику, когда при сравнении подходов совершенно посторонние программисты говорят "да, с комбинаторами-то проще, изучу я их, пожалуй".


Шо? Кто против стековых комбинаторов?
Это DSL для более эффективного (в плане быстродействия) по сравнению с фортом кода. К примеру, нужно сделать в одном месте какое-то действие (лень лезть в свои исходники в поисках примера). На форте это вылилось бы в лишнее стекомахание, а тут тишь да гладь.

Насчёт попроще, это явно диверсия. Они посложнее форта, особенно в моей реализации.

P.S.
На счёт стекомахания. Бывают просто такие ситуации.
В обычной практике далее связки SWAP ROT заходить не приходится
Сообщение Добавлено: Вс мар 11, 2018 18:46
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
_KROL писал(а):
Как я понял, вы хотели сказать, что стек удобен зачастую удобен для конечного решения определённой задачи, но не для программиста, который во время процесса решения продумывает, что у него лежит в каждом стеке.


Вспоминаем комбинаторику.
2 стека - 2 варианта взаимодействия (2!=2) , 3 стека 6 вариантов взаимодействий (3!=6) и т. д.

А ежели в форте постоянно, непрерывно, используются более 2-х стеков?
Нагрузка на фортера больше, а выхлопа нет почти.

Создать новый стек для сущностей? Запросто, но зачем они должны захватывать форт-систему, аки вирус организм? Пусть тусуются в рамках своей задачи.
Сообщение Добавлено: Вс мар 11, 2018 18:35
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
mOleg писал(а):
ээм, а совместимости с чем? странно слышать именно это утверждение от тебя 8)

Совместимость существует методологическая. Читаем книги и нарабатываем код. К моменту завершения чтения книг и статей у программиста уже что-то в голове отложилось. Можно попытаться впихнуть ему что-то свое, но практика показывает, что лишнее и ненужное отваливается за ненадобностью. Вот в рамках привыкания к Форту программист вполне может привыкнуть к постфиксу и словам DUP DROP SWAP OVER ROT.
mOleg писал(а):
нет, размер - это размер.
пример не засчитан 8(

Размер это именно размер. Это и данные, потому что с ними надо сравнивать координату (которая тоже данные), и он же используется для вычисления размера массива.

mOleg писал(а):
в конце концов, ты ведь не путаешься, где надо писать ! , а где +
а, ведь тоже надо разделять, где адрес лежит в первом случае.

Так это и есть тот самый практически вырабатываемый шаблон программирования, образующийся, пока человек изучает основы. Слова ! @ в целом дань традициям. Можно заменить на SET и GET или STORE и FETCH. Можно, конечно, пользуясь отдаленной аналогией, пойти в детский сад и там рассказывать, что Земля плоская, но сколько у детей продержится такое знание на практике? Вон и стековые комбинаторы что-то не показывают победного шествия. Я не имею в виду примеры кода, "которые работают же!". Я имею в виду объективную статистику, когда при сравнении подходов совершенно посторонние программисты говорят "да, с комбинаторами-то проще, изучу я их, пожалуй". Вот и с адресным стеком (и заодно со стеком строк, стеком словарей и прочими) точно так же. Для себя - сколько угодно. Рассчитывать, что все сейчас бросят наработанные подходы и станут все переписывать - большой вопрос. Который и решается не дискуссиями, а наблюдением за реально складывающейся картиной, которую формируют независимые программисты.
Сообщение Добавлено: Пт мар 09, 2018 18:13
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
_KROL писал(а):
Не вижу проблемы
Код:
: VARIABLE ( -- \\ -- a:addr ) CREATE 0 , DOES> ;
: CONSTANT ( d: x -- \\ -- d: x) CREATE , DOES> @ ;

Оно вобщем-то именно так обычно и реализуется. Вопрос в том, что с отдельным стеком адресов слово CREATE должно и число класть на стек адресов. А это значит, что подходы, рассчитанные на "создали и проверили, где выделена память" тоже надо переориентировать.

_KROL писал(а):
Я как-то не понимаю, в чём сложность держать два стека в голове? Не привычно? Да.

Почему не три? Не четыре? В качестве модели "почему бы и не так" оно имеет право на существование. В конце концов, можно много чего написать, в том числе и реализовать совершенно постороннюю вычислительную модель на Форте. Другое дело, что это имеет мало шансов стать мейнстримом, потому что существует рабочий подход, основанный на единственном стеке. А раз стек адресов можно не делать, то он и не будет сделан. Просто по принципу экономии сил.
Сообщение Добавлено: Пт мар 09, 2018 18:03
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
mOleg писал(а):
_KROL писал(а):
Олег, если тебя смущает AD+ (видишь как суммму адреса и двойной ячейки), то вот ещё варианты: A+D A:D
Последний вроде точно по смыслу подходит.

меня устраивает A+

Вполне по Фортовски для различения разных сущностей вводить свои лексиконы слов. :)

P.S. До этого была мысль, например, добавить к системе дублирование верхнего элемента стэка в регистре A вводимому в некоторых системах, но тогда >R R> слова отчасти уйдут из употребления в коде, что тоже не лучший вариант (т.к. будет использован 'неявный' контекст создания кода в Форт системе)
Сообщение Добавлено: Пт мар 09, 2018 14:54
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
_KROL писал(а):
Олег, если тебя смущает AD+ (видишь как суммму адреса и двойной ячейки), то вот ещё варианты: A+D A:D
Последний вроде точно по смыслу подходит.

меня устраивает A+
Сообщение Добавлено: Пт мар 09, 2018 14:17
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
Hishnik писал(а):
mOleg писал(а):
нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+

Ну терминологически это "составляющая адреса", и это непринципиально. Важнее то, что слово-то другое - A+. А это уже делает код несовместимым.

нет, принципиально. На стеке адресов могут быть только адреса - только так можно ввести хоть какой-нибудь контроль за работой системы и отвязаться от того, как представлен адрес.
ээм, а совместимости с чем? странно слышать именно это утверждение от тебя 8)

Hishnik писал(а):
mOleg писал(а):
а вот примеры литералов-адресов "в студию" можно предоставить?

Вот только что. Вот у меня размер карты в константе. С одной стороны, надо с помощью этой константы вычислять смещения, т.е. делать потом A+ вместо +. С другой - это чистые данные, потому что надо проверять координату и прочее.

нет, размер - это размер.
пример не засчитан 8(

в конце концов, ты ведь не путаешься, где надо писать ! , а где +
а, ведь тоже надо разделять, где адрес лежит в первом случае.
Сообщение Добавлено: Пт мар 09, 2018 13:57
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
Hishnik писал(а):
mOleg писал(а):
нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+

Ну терминологически это "составляющая адреса", и это непринципиально. Важнее то, что слово-то другое - A+. А это уже делает код несовместимым.
Олег, если тебя смущает AD+ (видишь как суммму адреса и двойной ячейки), то вот ещё варианты: A+D A:D
Последний вроде точно по смыслу подходит.

Hishnik писал(а):
mOleg писал(а):
а вот примеры литералов-адресов "в студию" можно предоставить?

Вот только что. Вот у меня размер карты в константе. С одной стороны, надо с помощью этой константы вычислять смещения, т.е. делать потом A+ вместо +. С другой - это чистые данные, потому что надо проверять координату и прочее.

Не вижу проблемы
Код:
: VARIABLE ( -- \\ -- a:addr ) CREATE 0 , DOES> ;
: CONSTANT ( d: x -- \\ -- d: x) CREATE , DOES> @ ;


Hishnik писал(а):
mOleg писал(а):
И, не то, чтоб я не видел проблем, просто они достаточно легко преодолимы.

Так вот это как раз к Оккаму вопрос. Точнее, от него тут ответ :) Есть много вариантов реализации самых разных вещей. Стек циклов, к слову, не меняет в коде ничего - все основные шаблоны остаются теми же. Стек адресов меняет исходные тексты, так что надо выбирать серьезно.
Я как-то не понимаю, в чём сложность держать два стека в голове? Не привычно? Да.

P.s. Как я понял, вы все просто хотите оживить форум? :D
Сообщение Добавлено: Пт мар 09, 2018 12:29
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
mOleg писал(а):
нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+

Ну терминологически это "составляющая адреса", и это непринципиально. Важнее то, что слово-то другое - A+. А это уже делает код несовместимым.

mOleg писал(а):
а вот примеры литералов-адресов "в студию" можно предоставить?

Вот только что. Вот у меня размер карты в константе. С одной стороны, надо с помощью этой константы вычислять смещения, т.е. делать потом A+ вместо +. С другой - это чистые данные, потому что надо проверять координату и прочее.

mOleg писал(а):
И, не то, чтоб я не видел проблем, просто они достаточно легко преодолимы.

Так вот это как раз к Оккаму вопрос. Точнее, от него тут ответ :) Есть много вариантов реализации самых разных вещей. Стек циклов, к слову, не меняет в коде ничего - все основные шаблоны остаются теми же. Стек адресов меняет исходные тексты, так что надо выбирать серьезно.
Сообщение Добавлено: Пт мар 09, 2018 01:12
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
Hishnik писал(а):
mOleg писал(а):
причем тут размеры массивов? как они относятся к адресному типу?

Ну вот я привожу пример. X, Y - это данные, но выражение Y*sizeX + X - это смещение в массиве, т.е. адрес.

нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+

Hishnik писал(а):
Как вообще разделить литералы-данные и литералы-адреса?

а вот примеры литералов-адресов "в студию" можно предоставить?

с Variable сложнее, в него адреса сохранять и данные не получится,
придется вводить какой-нибудь Pointer , что не так уж и плохо, а Variable оставлять для данных.
Интереснее, как реализовать помещение адреса, представленного в текстовом виде на стек адресов?
Можно типа: 0xFECBDA Nil A+ т.е. как смещение от нулевого указателя, а можно и так: '0x12ED45

И, не то, чтоб я не видел проблем, просто они достаточно легко преодолимы.
Сообщение Добавлено: Пт мар 09, 2018 00:49
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
mOleg писал(а):
потому и привожу такой пример. Ведь укладывается в голове, что идет на стек данных, а что на FP ?!

Но это именно из-за возможностей x87. И код в целом приходит к стилю "сначала все, что нужно, на стек с плавающей точкой, потом считаем, потом при необходимости обратно на целочисленный стек". Смесь кода неудобно отлаживать.
mOleg писал(а):
это похоже просто на блок в голове 8(
тут нет стены, тут нет сложностей (если их не придумывать)
ну, попробуй сам хотя бы с десяток вариантов перебрать так и сяк.
я, ведь, тоже не сразу это понял, что все достаточно гладко выходит, и преимущества таки есть,
и тема о трехстековой машине тут на форуме была поднята не мной (уж и не помню кем) и я был сначала тоже очень против.
Даже набросок системы сделал, чтобы понять, что так а что нет.

Ну, могу только напомнить, что я вообще-то такой стек уже делал для Кварка и показывал примеры. :D Так что аргумент "зелен виноград" тут не пройдет. Есть бритва Оккама, которая как раз для таких ситуаций и была придумана еще в незапамятные времена, а именно когда в богословии стали придумывать вещи на уровне "а еще вот так можно, поэтому давайте так и считать". Сейчас-то попроще, потому что можно тут же проверить - ну так и надо проверить. Но аргумент "почему бы не так" проверяется как раз бритвой Оккама - если можно без этого, значит рано или поздно оно само и отвалится. Просто когда кто-то напишет Форт, отложит стек адресов на потом, и по ходу дела обнаружит, что и так вобщем-то все работает.

mOleg писал(а):
причем тут размеры массивов? как они относятся к адресному типу?

Ну вот я привожу пример. X, Y - это данные, но выражение Y*sizeX + X - это смещение в массиве, т.е. адрес. Так что достаточно пробежаться глазами по коду на Си и посмотреть, сколько там выражений в квадратных скобках - вот как раз вычисление адреса. Всегда ли там внутри литералы? Как вообще разделить литералы-данные и литералы-адреса? Вот поэтому и вопросы к новому предложению всегда лежат в плоскости "а давайте это попробуем сломать, а потом посмотрим на список неудачных попыток - чем он больше, тем лучше предложение".
Сообщение Добавлено: Пт мар 09, 2018 00:35
  Заголовок сообщения:  Re: 3-х стековая виртуальная машина. размышления.  Ответить с цитатой
_KROL писал(а):
Как я понял, вы хотели сказать, что стек удобен зачастую удобен для конечного решения определённой задачи, но не для программиста, который во время процесса решения продумывает, что у него лежит в каждом стеке.

У Форта постоянно указывают на стек как на недостаток, потому что получается непривычная запись выражений. Однако с точки зрения реализации многое достаточно удобно программировать. Например, в Си знак + сам по себе ничего вобщем-то не означает. Нужен еще синтаксический анализ, чтобы понять, какой код получится. А для стекового языка + имеет совершенно понятную реализацию - взять два числа со стека, сложить, и поместить результат на стек. Получаются и удобные схемы - например, в стековом процессоре адрес всегда лежит на вершине стека.

Однако имеет место и некий культ вокруг стека. Дескать, это нечто с глубоким смыслом, и если мы начнем использовать стек, то откроются прекрасные далеко идущие перспективы. А это не так. Что хорошо в Форте - многие вещи уже проработаны для стековой реализации. Но тащить все на стек ради непонятной мистики не стоит.

_KROL писал(а):
А почему бы и нет? Вон ALIT где-то видел. Вводить новое, так вводить до конца

Я уже показывал это, довольно давно. Сделать отдельный стек для адресов - это не проблема. Проблема больше в дальнейшем использовании - в каких именно случаях числа кладутся на этот стек? Например, VARIABLE должна класть число на стек адреса. А вот CONSTANT? Я выше привел пример того, как константы используются для вычисления адреса. Например, мы имеем карту, которая представлена двумерным массивом. Координаты объекта X, Y - это ведь данные. Но на их основе надо вычислить адрес ячейки в массиве карты, чтобы понять, что там находится. Поэтому пока на такой модели с отдельным стеком адреса не будет написано достаточно кода, будет непонятно, насколько это рабочее. Причем писать код надо с целью "сломать", а не показать работающие примеры. Такой подход лежит достаточно глубоко в научной методологии - вопрос не в том, как мы доказываем, а какими способами мы пытались опровергнуть гипотезу (и это не получилось). Чем больше вот таких примеров, когда мы подсовывали новому методу интересные задачки, а он справлялся, тем ценнее метод.
Сообщение Добавлено: Пт мар 09, 2018 00:24

Часовой пояс: UTC + 3 часа [ Летнее время ]


cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB