Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
Цитата: не поверишь, их таки больше двух. У меня постоянно используется 4-е низкоуровневых(определенных на асме) и два и более, ээ, других в общем.
Поверю, в Нове их 5: данные, возвраты, плав.точка, контекст, окружение. Разговор о том, что тяжелей их использовать совместно в одном зрительном пространстве. Навряд ли встречается что-то вроде: DUP >R ALSO CONTEXT ! R@ >A F@ EXECUTE SWAP A> Короче, смешение с потерей смысла. Цитата: и это говорит о том, что работу на стеке (обычную, нормальную) вы просто не освоили 8( и стиль у вас неудачный. имхо.
Вот залез и посмотрел в свои наработки. Всё пучком. Цитата: Я пока придерживаюсь мнения, что по мере освоения Форта стековых манипуляций у программистов становится все меньше и меньше. Поэтому и потребность в упрощении стековых манипуляций уменьшается естественным путем.
Ну, так оно и есть. Насчёт стековых манипуляторов. вот 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 код для замены одного символа другим в строке И асм не напрягаем. Короче, это инструмент для оптимизации по скорости и по наглядности (да-да, надо учиться) кода. Только и всего и нужен он, естественно, не везде, а лишь в отдельных случаях.
[quote] не поверишь, их таки больше двух. У меня постоянно используется 4-е низкоуровневых(определенных на асме) и два и более, ээ, других в общем. [/quote]
Поверю, в Нове их 5: данные, возвраты, плав.точка, контекст, окружение. Разговор о том, что тяжелей их использовать совместно в одном зрительном пространстве.
Навряд ли встречается что-то вроде: DUP >R ALSO CONTEXT ! R@ >A F@ EXECUTE SWAP A>
Короче, смешение с потерей смысла. [quote] и это говорит о том, что работу на стеке (обычную, нормальную) вы просто не освоили 8( и стиль у вас неудачный. имхо. [/quote]
Вот залез и посмотрел в свои наработки. Всё пучком. :D
[quote] Я пока придерживаюсь мнения, что по мере освоения Форта стековых манипуляций у программистов становится все меньше и меньше. Поэтому и потребность в упрощении стековых манипуляций уменьшается естественным путем. [/quote] Ну, так оно и есть. Насчёт стековых манипуляторов. вот 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( и стиль у вас неудачный. имхо.
[quote="Victor__v"]Вспоминаем комбинаторику. 2 стека - 2 варианта взаимодействия (2!=2) , 3 стека 6 вариантов взаимодействий (3!=6) и т. д. [/quote] И тут не совсем верно. Т.к. появляются запрещенные перемещения и операции. И, все-таки, говорить что-то, стоит сначала разобравшись 8)
[quote="Victor__v"]А ежели в форте постоянно, непрерывно, используются более 2-х стеков?[/quote] не поверишь, их таки больше двух. У меня постоянно используется 4-е низкоуровневых(определенных на асме) и два и более, ээ, других в общем. И я не путаюсь, т.к. они совсем разные.
[quote="Victor__v"]Шо? Кто против стековых комбинаторов? [/quote] я против 8) дичайшая вещь.
[quote="Victor__v"]На счёт стекомахания. Бывают просто такие ситуации. В обычной практике далее связки SWAP ROT заходить не приходится[/quote] и это говорит о том, что работу на стеке (обычную, нормальную) вы просто не освоили 8( и стиль у вас неудачный. имхо.
|
|
|
|
Добавлено: Вс мар 11, 2018 21:05 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
Victor__v писал(а): Шо? Кто против стековых комбинаторов? Это DSL для более эффективного (в плане быстродействия) по сравнению с фортом кода. К примеру, нужно сделать в одном месте какое-то действие (лень лезть в свои исходники в поисках примера). На форте это вылилось бы в лишнее стекомахание, а тут тишь да гладь.
Я пока придерживаюсь мнения, что по мере освоения Форта стековых манипуляций у программистов становится все меньше и меньше. Поэтому и потребность в упрощении стековых манипуляций уменьшается естественным путем. Victor__v писал(а): Насчёт попроще, это явно диверсия. Они посложнее форта, особенно в моей реализации. Именно. И раз нет явной волны запросов на стековые комбинаторы, автоматически встает вопрос, а нужно ли добавлять вещь, обязательную к реализации. Для меня резко снижается привлекательность наработок, если я знаю, что их автор может заявить "а вот тут я поставлю слово, которое мне нравится, и без него делать не буду, а слово мне нужно, чтобы обосновать редкую вещь, которая не во всяком Форте есть". Из той же серии совсем уже бредовые заявления Максимова "отдам библиотеки только за криптовалюту". Может еще в Oriflame торговым представителем надо зарегистрироваться?
[quote="Victor__v"]Шо? Кто против стековых комбинаторов? Это DSL для более эффективного (в плане быстродействия) по сравнению с фортом кода. К примеру, нужно сделать в одном месте какое-то действие (лень лезть в свои исходники в поисках примера). На форте это вылилось бы в лишнее стекомахание, а тут тишь да гладь. [/quote] Я пока придерживаюсь мнения, что по мере освоения Форта стековых манипуляций у программистов становится все меньше и меньше. Поэтому и потребность в упрощении стековых манипуляций уменьшается естественным путем. [quote="Victor__v"]Насчёт попроще, это явно диверсия. Они посложнее форта, особенно в моей реализации.[/quote] Именно. И раз нет явной волны запросов на стековые комбинаторы, автоматически встает вопрос, а нужно ли добавлять вещь, обязательную к реализации. Для меня резко снижается привлекательность наработок, если я знаю, что их автор может заявить "а вот тут я поставлю слово, которое мне нравится, и без него делать не буду, а слово мне нужно, чтобы обосновать редкую вещь, которая не во всяком Форте есть". Из той же серии совсем уже бредовые заявления Максимова "отдам библиотеки только за криптовалюту". Может еще в Oriflame торговым представителем надо зарегистрироваться? :D
|
|
|
|
Добавлено: Вс мар 11, 2018 20:57 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
Hishnik писал(а): Вон и стековые комбинаторы что-то не показывают победного шествия. Я не имею в виду примеры кода, "которые работают же!". Я имею в виду объективную статистику, когда при сравнении подходов совершенно посторонние программисты говорят "да, с комбинаторами-то проще, изучу я их, пожалуй". Шо? Кто против стековых комбинаторов? Это DSL для более эффективного (в плане быстродействия) по сравнению с фортом кода. К примеру, нужно сделать в одном месте какое-то действие (лень лезть в свои исходники в поисках примера). На форте это вылилось бы в лишнее стекомахание, а тут тишь да гладь. Насчёт попроще, это явно диверсия. Они посложнее форта, особенно в моей реализации. P.S. На счёт стекомахания. Бывают просто такие ситуации. В обычной практике далее связки SWAP ROT заходить не приходится
[quote="Hishnik"] Вон и стековые комбинаторы что-то не показывают победного шествия. Я не имею в виду примеры кода, "которые работают же!". Я имею в виду объективную статистику, когда при сравнении подходов совершенно посторонние программисты говорят "да, с комбинаторами-то проще, изучу я их, пожалуй". [/quote]
Шо? Кто против стековых комбинаторов? Это DSL для более эффективного (в плане быстродействия) по сравнению с фортом кода. К примеру, нужно сделать в одном месте какое-то действие (лень лезть в свои исходники в поисках примера). На форте это вылилось бы в лишнее стекомахание, а тут тишь да гладь.
Насчёт попроще, это явно диверсия. Они посложнее форта, особенно в моей реализации.
P.S. На счёт стекомахания. Бывают просто такие ситуации. В обычной практике далее связки SWAP ROT заходить не приходится
|
|
|
|
Добавлено: Вс мар 11, 2018 18:46 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
_KROL писал(а): Как я понял, вы хотели сказать, что стек удобен зачастую удобен для конечного решения определённой задачи, но не для программиста, который во время процесса решения продумывает, что у него лежит в каждом стеке. Вспоминаем комбинаторику. 2 стека - 2 варианта взаимодействия (2!=2) , 3 стека 6 вариантов взаимодействий (3!=6) и т. д. А ежели в форте постоянно, непрерывно, используются более 2-х стеков? Нагрузка на фортера больше, а выхлопа нет почти. Создать новый стек для сущностей? Запросто, но зачем они должны захватывать форт-систему, аки вирус организм? Пусть тусуются в рамках своей задачи.
[quote="_KROL"]Как я понял, вы хотели сказать, что стек удобен зачастую удобен для конечного решения определённой задачи, но не для программиста, который во время процесса решения продумывает, что у него лежит в каждом стеке.[/quote]
Вспоминаем комбинаторику. 2 стека - 2 варианта взаимодействия (2!=2) , 3 стека [b]6[/b] вариантов взаимодействий (3!=6) и т. д.
А ежели в форте постоянно, непрерывно, используются более 2-х стеков? Нагрузка на фортера больше, а выхлопа нет почти.
Создать новый стек для сущностей? Запросто, но зачем они должны захватывать форт-систему, аки вирус организм? Пусть тусуются в рамках своей задачи.
|
|
|
|
Добавлено: Вс мар 11, 2018 18:35 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
mOleg писал(а): ээм, а совместимости с чем? странно слышать именно это утверждение от тебя Совместимость существует методологическая. Читаем книги и нарабатываем код. К моменту завершения чтения книг и статей у программиста уже что-то в голове отложилось. Можно попытаться впихнуть ему что-то свое, но практика показывает, что лишнее и ненужное отваливается за ненадобностью. Вот в рамках привыкания к Форту программист вполне может привыкнуть к постфиксу и словам DUP DROP SWAP OVER ROT. mOleg писал(а): нет, размер - это размер. пример не засчитан 8( Размер это именно размер. Это и данные, потому что с ними надо сравнивать координату (которая тоже данные), и он же используется для вычисления размера массива. mOleg писал(а): в конце концов, ты ведь не путаешься, где надо писать ! , а где + а, ведь тоже надо разделять, где адрес лежит в первом случае. Так это и есть тот самый практически вырабатываемый шаблон программирования, образующийся, пока человек изучает основы. Слова ! @ в целом дань традициям. Можно заменить на SET и GET или STORE и FETCH. Можно, конечно, пользуясь отдаленной аналогией, пойти в детский сад и там рассказывать, что Земля плоская, но сколько у детей продержится такое знание на практике? Вон и стековые комбинаторы что-то не показывают победного шествия. Я не имею в виду примеры кода, "которые работают же!". Я имею в виду объективную статистику, когда при сравнении подходов совершенно посторонние программисты говорят "да, с комбинаторами-то проще, изучу я их, пожалуй". Вот и с адресным стеком (и заодно со стеком строк, стеком словарей и прочими) точно так же. Для себя - сколько угодно. Рассчитывать, что все сейчас бросят наработанные подходы и станут все переписывать - большой вопрос. Который и решается не дискуссиями, а наблюдением за реально складывающейся картиной, которую формируют независимые программисты.
[quote="mOleg"]ээм, а совместимости с чем? странно слышать именно это утверждение от тебя 8)[/quote] Совместимость существует методологическая. Читаем книги и нарабатываем код. К моменту завершения чтения книг и статей у программиста уже что-то в голове отложилось. Можно попытаться впихнуть ему что-то свое, но практика показывает, что лишнее и ненужное отваливается за ненадобностью. Вот в рамках привыкания к Форту программист вполне может привыкнуть к постфиксу и словам DUP DROP SWAP OVER ROT. [quote="mOleg"]нет, размер - это размер. пример не засчитан 8( [/quote] Размер это именно размер. Это и данные, потому что с ними надо сравнивать координату (которая тоже данные), и он же используется для вычисления размера массива.
[quote="mOleg"]в конце концов, ты ведь не путаешься, где надо писать ! , а где + а, ведь тоже надо разделять, где адрес лежит в первом случае.[/quote] Так это и есть тот самый практически вырабатываемый шаблон программирования, образующийся, пока человек изучает основы. Слова ! @ в целом дань традициям. Можно заменить на 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 писал(а): Я как-то не понимаю, в чём сложность держать два стека в голове? Не привычно? Да. Почему не три? Не четыре? В качестве модели "почему бы и не так" оно имеет право на существование. В конце концов, можно много чего написать, в том числе и реализовать совершенно постороннюю вычислительную модель на Форте. Другое дело, что это имеет мало шансов стать мейнстримом, потому что существует рабочий подход, основанный на единственном стеке. А раз стек адресов можно не делать, то он и не будет сделан. Просто по принципу экономии сил.
[quote="_KROL"]Не вижу проблемы Код: : VARIABLE ( -- \\ -- a:addr ) CREATE 0 , DOES> ; : CONSTANT ( d: x -- \\ -- d: x) CREATE , DOES> @ ; [/quote] Оно вобщем-то именно так обычно и реализуется. Вопрос в том, что с отдельным стеком адресов слово CREATE должно и число класть на стек адресов. А это значит, что подходы, рассчитанные на "создали и проверили, где выделена память" тоже надо переориентировать.
[quote="_KROL"]Я как-то не понимаю, в чём сложность держать два стека в голове? Не привычно? Да.[/quote] Почему не три? Не четыре? В качестве модели "почему бы и не так" оно имеет право на существование. В конце концов, можно много чего написать, в том числе и реализовать совершенно постороннюю вычислительную модель на Форте. Другое дело, что это имеет мало шансов стать мейнстримом, потому что существует рабочий подход, основанный на единственном стеке. А раз стек адресов можно не делать, то он и не будет сделан. Просто по принципу экономии сил.
|
|
|
|
Добавлено: Пт мар 09, 2018 18:03 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
mOleg писал(а): _KROL писал(а): Олег, если тебя смущает AD+ (видишь как суммму адреса и двойной ячейки), то вот ещё варианты: A+D A:D Последний вроде точно по смыслу подходит. меня устраивает A+ Вполне по Фортовски для различения разных сущностей вводить свои лексиконы слов. P.S. До этого была мысль, например, добавить к системе дублирование верхнего элемента стэка в регистре A вводимому в некоторых системах, но тогда >R R> слова отчасти уйдут из употребления в коде, что тоже не лучший вариант (т.к. будет использован 'неявный' контекст создания кода в Форт системе)
[quote="mOleg"][quote="_KROL"]Олег, если тебя смущает AD+ (видишь как суммму адреса и двойной ячейки), то вот ещё варианты: A+D A:D Последний вроде точно по смыслу подходит.[/quote] меня устраивает A+[/quote] Вполне по Фортовски для различения разных сущностей вводить свои лексиконы слов. :)
P.S. До этого была мысль, например, добавить к системе дублирование верхнего элемента стэка в регистре A вводимому в некоторых системах, но тогда >R R> слова отчасти уйдут из употребления в коде, что тоже не лучший вариант (т.к. будет использован 'неявный' контекст создания кода в Форт системе)
|
|
|
|
Добавлено: Пт мар 09, 2018 14:54 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
_KROL писал(а): Олег, если тебя смущает AD+ (видишь как суммму адреса и двойной ячейки), то вот ещё варианты: A+D A:D Последний вроде точно по смыслу подходит. меня устраивает A+
[quote="_KROL"]Олег, если тебя смущает AD+ (видишь как суммму адреса и двойной ячейки), то вот ещё варианты: A+D A:D Последний вроде точно по смыслу подходит.[/quote] меня устраивает A+
|
|
|
|
Добавлено: Пт мар 09, 2018 14:17 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
Hishnik писал(а): mOleg писал(а): нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+
Ну терминологически это "составляющая адреса", и это непринципиально. Важнее то, что слово-то другое - A+. А это уже делает код несовместимым. нет, принципиально. На стеке адресов могут быть только адреса - только так можно ввести хоть какой-нибудь контроль за работой системы и отвязаться от того, как представлен адрес. ээм, а совместимости с чем? странно слышать именно это утверждение от тебя 8) Hishnik писал(а): mOleg писал(а): а вот примеры литералов-адресов "в студию" можно предоставить?
Вот только что. Вот у меня размер карты в константе. С одной стороны, надо с помощью этой константы вычислять смещения, т.е. делать потом A+ вместо +. С другой - это чистые данные, потому что надо проверять координату и прочее. нет, размер - это размер. пример не засчитан 8( в конце концов, ты ведь не путаешься, где надо писать ! , а где + а, ведь тоже надо разделять, где адрес лежит в первом случае.
[quote="Hishnik"]mOleg писал(а): нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+
Ну терминологически это "составляющая адреса", и это непринципиально. Важнее то, что слово-то другое - A+. А это уже делает код несовместимым.[/quote] нет, принципиально. На стеке адресов могут быть только адреса - только так можно ввести хоть какой-нибудь контроль за работой системы и отвязаться от того, как представлен адрес. ээм, а совместимости с чем? странно слышать именно это утверждение от тебя 8)
[quote="Hishnik"]mOleg писал(а): а вот примеры литералов-адресов "в студию" можно предоставить?
Вот только что. Вот у меня размер карты в константе. С одной стороны, надо с помощью этой константы вычислять смещения, т.е. делать потом A+ вместо +. С другой - это чистые данные, потому что надо проверять координату и прочее.[/quote] нет, размер - это размер. пример не засчитан 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. Как я понял, вы все просто хотите оживить форум?
[quote="Hishnik"][quote="mOleg"]нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+[/quote] Ну терминологически это "составляющая адреса", и это непринципиально. Важнее то, что слово-то другое - A+. А это уже делает код несовместимым.[/quote]Олег, если тебя смущает AD+ (видишь как суммму адреса и двойной ячейки), то вот ещё варианты: A+D A:D Последний вроде точно по смыслу подходит.
[quote="Hishnik"][quote="mOleg"]а вот примеры литералов-адресов "в студию" можно предоставить?[/quote] Вот только что. Вот у меня размер карты в константе. С одной стороны, надо с помощью этой константы вычислять смещения, т.е. делать потом A+ вместо +. С другой - это чистые данные, потому что надо проверять координату и прочее.[/quote] Не вижу проблемы[code]: VARIABLE ( -- \\ -- a:addr ) CREATE 0 , DOES> ; : CONSTANT ( d: x -- \\ -- d: x) CREATE , DOES> @ ;[/code]
[quote="Hishnik"][quote="mOleg"]И, не то, чтоб я не видел проблем, просто они достаточно легко преодолимы.[/quote] Так вот это как раз к Оккаму вопрос. Точнее, от него тут ответ :) Есть много вариантов реализации самых разных вещей. Стек циклов, к слову, не меняет в коде ничего - все основные шаблоны остаются теми же. Стек адресов меняет исходные тексты, так что надо выбирать серьезно.[/quote]Я как-то не понимаю, в чём сложность держать два стека в голове? Не привычно? Да.
P.s. Как я понял, вы все просто хотите оживить форум? :D
|
|
|
|
Добавлено: Пт мар 09, 2018 12:29 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
mOleg писал(а): нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+ Ну терминологически это "составляющая адреса", и это непринципиально. Важнее то, что слово-то другое - A+. А это уже делает код несовместимым. mOleg писал(а): а вот примеры литералов-адресов "в студию" можно предоставить? Вот только что. Вот у меня размер карты в константе. С одной стороны, надо с помощью этой константы вычислять смещения, т.е. делать потом A+ вместо +. С другой - это чистые данные, потому что надо проверять координату и прочее. mOleg писал(а): И, не то, чтоб я не видел проблем, просто они достаточно легко преодолимы. Так вот это как раз к Оккаму вопрос. Точнее, от него тут ответ Есть много вариантов реализации самых разных вещей. Стек циклов, к слову, не меняет в коде ничего - все основные шаблоны остаются теми же. Стек адресов меняет исходные тексты, так что надо выбирать серьезно.
[quote="mOleg"]нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+[/quote] Ну терминологически это "составляющая адреса", и это непринципиально. Важнее то, что слово-то другое - A+. А это уже делает код несовместимым.
[quote="mOleg"]а вот примеры литералов-адресов "в студию" можно предоставить?[/quote] Вот только что. Вот у меня размер карты в константе. С одной стороны, надо с помощью этой константы вычислять смещения, т.е. делать потом A+ вместо +. С другой - это чистые данные, потому что надо проверять координату и прочее.
[quote="mOleg"]И, не то, чтоб я не видел проблем, просто они достаточно легко преодолимы.[/quote] Так вот это как раз к Оккаму вопрос. Точнее, от него тут ответ :) Есть много вариантов реализации самых разных вещей. Стек циклов, к слову, не меняет в коде ничего - все основные шаблоны остаются теми же. Стек адресов меняет исходные тексты, так что надо выбирать серьезно.
|
|
|
|
Добавлено: Пт мар 09, 2018 01:12 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
Hishnik писал(а): mOleg писал(а): причем тут размеры массивов? как они относятся к адресному типу?
Ну вот я привожу пример. X, Y - это данные, но выражение Y*sizeX + X - это смещение в массиве, т.е. адрес. нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+ Hishnik писал(а): Как вообще разделить литералы-данные и литералы-адреса? а вот примеры литералов-адресов "в студию" можно предоставить? с Variable сложнее, в него адреса сохранять и данные не получится, придется вводить какой-нибудь Pointer , что не так уж и плохо, а Variable оставлять для данных. Интереснее, как реализовать помещение адреса, представленного в текстовом виде на стек адресов? Можно типа: 0xFECBDA Nil A+ т.е. как смещение от нулевого указателя, а можно и так: '0x12ED45 И, не то, чтоб я не видел проблем, просто они достаточно легко преодолимы.
[quote="Hishnik"]mOleg писал(а): причем тут размеры массивов? как они относятся к адресному типу?
Ну вот я привожу пример. X, Y - это данные, но выражение Y*sizeX + X - это смещение в массиве, т.е. адрес.[/quote] нет. смещение - это смещение. Адрес- это адрес. Адрес появляется, когда ты смещение добавляешь к базе, а это и есть A+
[quote="Hishnik"]Как вообще разделить литералы-данные и литералы-адреса?[/quote] а вот примеры литералов-адресов "в студию" можно предоставить?
с Variable сложнее, в него адреса сохранять и данные не получится, придется вводить какой-нибудь Pointer , что не так уж и плохо, а Variable оставлять для данных. Интереснее, как реализовать помещение адреса, представленного в текстовом виде на стек адресов? Можно типа: 0xFECBDA Nil A+ т.е. как смещение от нулевого указателя, а можно и так: '0x12ED45
И, не то, чтоб я не видел проблем, просто они достаточно легко преодолимы.
|
|
|
|
Добавлено: Пт мар 09, 2018 00:49 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
mOleg писал(а): потому и привожу такой пример. Ведь укладывается в голове, что идет на стек данных, а что на FP ?! Но это именно из-за возможностей x87. И код в целом приходит к стилю "сначала все, что нужно, на стек с плавающей точкой, потом считаем, потом при необходимости обратно на целочисленный стек". Смесь кода неудобно отлаживать. mOleg писал(а): это похоже просто на блок в голове 8( тут нет стены, тут нет сложностей (если их не придумывать) ну, попробуй сам хотя бы с десяток вариантов перебрать так и сяк. я, ведь, тоже не сразу это понял, что все достаточно гладко выходит, и преимущества таки есть, и тема о трехстековой машине тут на форуме была поднята не мной (уж и не помню кем) и я был сначала тоже очень против. Даже набросок системы сделал, чтобы понять, что так а что нет. Ну, могу только напомнить, что я вообще-то такой стек уже делал для Кварка и показывал примеры. Так что аргумент "зелен виноград" тут не пройдет. Есть бритва Оккама, которая как раз для таких ситуаций и была придумана еще в незапамятные времена, а именно когда в богословии стали придумывать вещи на уровне "а еще вот так можно, поэтому давайте так и считать". Сейчас-то попроще, потому что можно тут же проверить - ну так и надо проверить. Но аргумент "почему бы не так" проверяется как раз бритвой Оккама - если можно без этого, значит рано или поздно оно само и отвалится. Просто когда кто-то напишет Форт, отложит стек адресов на потом, и по ходу дела обнаружит, что и так вобщем-то все работает. mOleg писал(а): причем тут размеры массивов? как они относятся к адресному типу? Ну вот я привожу пример. X, Y - это данные, но выражение Y*sizeX + X - это смещение в массиве, т.е. адрес. Так что достаточно пробежаться глазами по коду на Си и посмотреть, сколько там выражений в квадратных скобках - вот как раз вычисление адреса. Всегда ли там внутри литералы? Как вообще разделить литералы-данные и литералы-адреса? Вот поэтому и вопросы к новому предложению всегда лежат в плоскости "а давайте это попробуем сломать, а потом посмотрим на список неудачных попыток - чем он больше, тем лучше предложение".
[quote="mOleg"]потому и привожу такой пример. Ведь укладывается в голове, что идет на стек данных, а что на FP ?![/quote] Но это именно из-за возможностей x87. И код в целом приходит к стилю "сначала все, что нужно, на стек с плавающей точкой, потом считаем, потом при необходимости обратно на целочисленный стек". Смесь кода неудобно отлаживать. [quote="mOleg"]это похоже просто на блок в голове 8( тут нет стены, тут нет сложностей (если их не придумывать) ну, попробуй сам хотя бы с десяток вариантов перебрать так и сяк. я, ведь, тоже не сразу это понял, что все достаточно гладко выходит, и преимущества таки есть, и тема о трехстековой машине тут на форуме была поднята не мной (уж и не помню кем) и я был сначала тоже очень против. Даже набросок системы сделал, чтобы понять, что так а что нет.[/quote] Ну, могу только напомнить, что я вообще-то такой стек уже делал для Кварка и показывал примеры. :D Так что аргумент "зелен виноград" тут не пройдет. Есть бритва Оккама, которая как раз для таких ситуаций и была придумана еще в незапамятные времена, а именно когда в богословии стали придумывать вещи на уровне "а еще вот так можно, поэтому давайте так и считать". Сейчас-то попроще, потому что можно тут же проверить - ну так и надо проверить. Но аргумент "почему бы не так" проверяется как раз бритвой Оккама - если можно без этого, значит рано или поздно оно само и отвалится. Просто когда кто-то напишет Форт, отложит стек адресов на потом, и по ходу дела обнаружит, что и так вобщем-то все работает.
[quote="mOleg"]причем тут размеры массивов? как они относятся к адресному типу?[/quote] Ну вот я привожу пример. X, Y - это данные, но выражение Y*sizeX + X - это смещение в массиве, т.е. адрес. Так что достаточно пробежаться глазами по коду на Си и посмотреть, сколько там выражений в квадратных скобках - вот как раз вычисление адреса. Всегда ли там внутри литералы? Как вообще разделить литералы-данные и литералы-адреса? Вот поэтому и вопросы к новому предложению всегда лежат в плоскости "а давайте это попробуем сломать, а потом посмотрим на список неудачных попыток - чем он больше, тем лучше предложение".
|
|
|
|
Добавлено: Пт мар 09, 2018 00:35 |
|
|
|
|
|
Заголовок сообщения: |
Re: 3-х стековая виртуальная машина. размышления. |
|
|
_KROL писал(а): Как я понял, вы хотели сказать, что стек удобен зачастую удобен для конечного решения определённой задачи, но не для программиста, который во время процесса решения продумывает, что у него лежит в каждом стеке. У Форта постоянно указывают на стек как на недостаток, потому что получается непривычная запись выражений. Однако с точки зрения реализации многое достаточно удобно программировать. Например, в Си знак + сам по себе ничего вобщем-то не означает. Нужен еще синтаксический анализ, чтобы понять, какой код получится. А для стекового языка + имеет совершенно понятную реализацию - взять два числа со стека, сложить, и поместить результат на стек. Получаются и удобные схемы - например, в стековом процессоре адрес всегда лежит на вершине стека. Однако имеет место и некий культ вокруг стека. Дескать, это нечто с глубоким смыслом, и если мы начнем использовать стек, то откроются прекрасные далеко идущие перспективы. А это не так. Что хорошо в Форте - многие вещи уже проработаны для стековой реализации. Но тащить все на стек ради непонятной мистики не стоит. _KROL писал(а): А почему бы и нет? Вон ALIT где-то видел. Вводить новое, так вводить до конца Я уже показывал это, довольно давно. Сделать отдельный стек для адресов - это не проблема. Проблема больше в дальнейшем использовании - в каких именно случаях числа кладутся на этот стек? Например, VARIABLE должна класть число на стек адреса. А вот CONSTANT? Я выше привел пример того, как константы используются для вычисления адреса. Например, мы имеем карту, которая представлена двумерным массивом. Координаты объекта X, Y - это ведь данные. Но на их основе надо вычислить адрес ячейки в массиве карты, чтобы понять, что там находится. Поэтому пока на такой модели с отдельным стеком адреса не будет написано достаточно кода, будет непонятно, насколько это рабочее. Причем писать код надо с целью "сломать", а не показать работающие примеры. Такой подход лежит достаточно глубоко в научной методологии - вопрос не в том, как мы доказываем, а какими способами мы пытались опровергнуть гипотезу (и это не получилось). Чем больше вот таких примеров, когда мы подсовывали новому методу интересные задачки, а он справлялся, тем ценнее метод.
[quote="_KROL"]Как я понял, вы хотели сказать, что стек удобен зачастую удобен для конечного решения определённой задачи, но не для программиста, который во время процесса решения продумывает, что у него лежит в каждом стеке.[/quote] У Форта постоянно указывают на стек как на недостаток, потому что получается непривычная запись выражений. Однако с точки зрения реализации многое достаточно удобно программировать. Например, в Си знак + сам по себе ничего вобщем-то не означает. Нужен еще синтаксический анализ, чтобы понять, какой код получится. А для стекового языка + имеет совершенно понятную реализацию - взять два числа со стека, сложить, и поместить результат на стек. Получаются и удобные схемы - например, в стековом процессоре адрес всегда лежит на вершине стека.
Однако имеет место и некий культ вокруг стека. Дескать, это нечто с глубоким смыслом, и если мы начнем использовать стек, то откроются прекрасные далеко идущие перспективы. А это не так. Что хорошо в Форте - многие вещи уже проработаны для стековой реализации. Но тащить все на стек ради непонятной мистики не стоит.
[quote="_KROL"]А почему бы и нет? Вон ALIT где-то видел. Вводить новое, так вводить до конца[/quote] Я уже показывал это, довольно давно. Сделать отдельный стек для адресов - это не проблема. Проблема больше в дальнейшем использовании - в каких именно случаях числа кладутся на этот стек? Например, VARIABLE должна класть число на стек адреса. А вот CONSTANT? Я выше привел пример того, как константы используются для вычисления адреса. Например, мы имеем карту, которая представлена двумерным массивом. Координаты объекта X, Y - это ведь данные. Но на их основе надо вычислить адрес ячейки в массиве карты, чтобы понять, что там находится. Поэтому пока на такой модели с отдельным стеком адреса не будет написано достаточно кода, будет непонятно, насколько это рабочее. Причем писать код надо с целью "сломать", а не показать работающие примеры. Такой подход лежит достаточно глубоко в научной методологии - вопрос не в том, как мы доказываем, а какими способами мы пытались опровергнуть гипотезу (и это не получилось). Чем больше вот таких примеров, когда мы подсовывали новому методу интересные задачки, а он справлялся, тем ценнее метод.
|
|
|
|
Добавлено: Пт мар 09, 2018 00:24 |
|
|
|
|