Автор |
Сообщение |
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): А как сочетаются "на мой взгляд" и "стандарт"? как любая работа, которую делают люди Хищник писал(а): Дело не в преимуществах, дело в том, что при рассмотрении только того, что нравится, за бортом окажется масса вариантов, которые, тем не менее, смогут реализовать форт-систему. я никак не пойму ,почему они должны оказаться за бортом. Я предлагаю взять самую прозрачную и понятную схему и на ней построить все пояснения. То есть пеимущества в простоте Хищник писал(а): mOleg писал(а):Ну, тот же DUP не зависит от типа ШК никак, а вот DOES> еще как зависит. А разве при разных типах ШК DOES> делает разные вещи?
нет, но устроен по-разному. И это придется описывать, либо "не разевать рот" на совместимость с различными типами ШК, и методами работы процессоров.
[quote="Хищник"]А как сочетаются "на мой взгляд" и "стандарт"?[/quote] как любая работа, которую делают люди :D
[quote="Хищник"]Дело не в преимуществах, дело в том, что при рассмотрении только того, что нравится, за бортом окажется масса вариантов, которые, тем не менее, смогут реализовать форт-систему.[/quote] я никак не пойму ,почему они должны оказаться за бортом. Я предлагаю взять самую прозрачную и понятную схему и на ней построить все пояснения. То есть пеимущества в простоте 8)
[quote="Хищник"]mOleg писал(а):Ну, тот же DUP не зависит от типа ШК никак, а вот DOES> еще как зависит. А разве при разных типах ШК DOES> делает разные вещи?[/quote]
нет, но устроен по-разному. И это придется описывать, либо "не разевать рот" на совместимость с различными типами ШК, и методами работы процессоров.
|
|
|
|
Добавлено: Вс авг 23, 2009 23:43 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): И опять же, преимуществ для Форта у байт-кода и подобных ему на мой взгляд меньше, чем у ITC А как сочетаются "на мой взгляд" и "стандарт"? Дело не в преимуществах, дело в том, что при рассмотрении только того, что нравится, за бортом окажется масса вариантов, которые, тем не менее, смогут реализовать форт-систему. Так что такая неведома зверушка, называемая Стандартом, будет нежизнеспособна по определению, поскольку разве что новички попытаются ей воспользоваться, пока не плюнут. mOleg писал(а): Но перед этим должна быть некая абстрактная "базовая модель" (вычислений, процессора, взаимодействия и т.п.) и в конкретных случаях оговаривать возможные варианты реализаций. Так эта модель уже вылезает всеми частями тела в области, которые фортеру приятны, но никак не могут быть упиханы в рамки. mOleg писал(а): Ну, тот же DUP не зависит от типа ШК никак, а вот DOES> еще как зависит.
А разве при разных типах ШК DOES> делает разные вещи?
[quote="mOleg"]И опять же, преимуществ для Форта у байт-кода и подобных ему на мой взгляд меньше, чем у ITC [/quote] А как сочетаются "на мой взгляд" и "стандарт"? Дело не в преимуществах, дело в том, что при рассмотрении только того, что нравится, за бортом окажется масса вариантов, которые, тем не менее, смогут реализовать форт-систему. Так что такая неведома зверушка, называемая Стандартом, будет нежизнеспособна по определению, поскольку разве что новички попытаются ей воспользоваться, пока не плюнут. [quote="mOleg"]Но перед этим должна быть некая абстрактная "базовая модель" (вычислений, процессора, взаимодействия и т.п.) и в конкретных случаях оговаривать возможные варианты реализаций. [/quote] Так эта модель уже вылезает всеми частями тела в области, которые фортеру приятны, но никак не могут быть упиханы в рамки. [quote="mOleg"]Ну, тот же DUP не зависит от типа ШК никак, а вот DOES> еще как зависит.[/quote]
А разве при разных типах ШК DOES> делает разные вещи?
|
|
|
|
Добавлено: Вс авг 23, 2009 23:37 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): DTC, STC - более сложны? Прямой шитый код появился как более быстрый вариант косвенного шитого кода. Потом дальше стали развивать подпрограммный ШК, который, кстати, в том же СПФ не совсем чистый. (есть места с DTC), иными словами чистой выглядят две модели: косвенный шитый код индексный (к примеру байт) код И опять же, преимуществ для Форта у байт-кода и подобных ему на мой взгляд меньше, чем у ITC Хищник писал(а): Тут получается не взять, а из всего многообразия достигнутых разными людьми результатов на основе непонятно чего назначить единственно правильный вариант. Что и будет благополучно отодвинуто в сторону и забыто.
опять есть ощущение у меня, что мое желание и мои намерения не верно истолкованы. Я не хочу ничего отрицать! я хочу включить все возможные варианты и разрулить возможные противоречия. Но перед этим должна быть некая абстрактная "базовая модель" (вычислений, процессора, взаимодействия и т.п.) и в конкретных случаях оговаривать возможные варианты реализаций.
Ну, тот же DUP не зависит от типа ШК никак, а вот DOES> еще как зависит.
[quote="Хищник"]DTC, STC - более сложны?[/quote] Прямой шитый код появился как более быстрый вариант косвенного шитого кода. Потом дальше стали развивать подпрограммный ШК, который, кстати, в том же СПФ не совсем чистый. (есть места с DTC), иными словами чистой выглядят две модели: косвенный шитый код индексный (к примеру байт) код И опять же, преимуществ для Форта у байт-кода и подобных ему на мой взгляд меньше, чем у ITC
[quote="Хищник"]Тут получается не взять, а из всего многообразия достигнутых разными людьми результатов на основе непонятно чего назначить единственно правильный вариант. Что и будет благополучно отодвинуто в сторону и забыто.[/quote]
опять есть ощущение у меня, что мое желание и мои намерения не верно истолкованы. Я не хочу ничего отрицать! я хочу включить все возможные варианты и разрулить возможные противоречия. Но перед этим должна быть некая абстрактная "базовая модель" (вычислений, процессора, взаимодействия и т.п.) и в конкретных случаях оговаривать возможные варианты реализаций.
Ну, тот же DUP не зависит от типа ШК никак, а вот DOES> еще как зависит.
|
|
|
|
Добавлено: Вс авг 23, 2009 23:26 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Цитата: Тут получается не взять, а из всего многообразия достигнутых разными людьми результатов на основе непонятно чего назначить единственно правильный вариант. Что и будет благополучно отодвинуто в сторону и забыто.
нало же, хочется повторить за Хищником... что бы это значило.
когда разнообразие трудноисчерпаемо, то нормы (в стандартах также) уступают место определениям
- конкретные нормы - общим определениям
иногда это определение описывает сам предмет, иногда - способ формализации описания предмета
[quote]Тут получается не взять, а из всего многообразия достигнутых разными людьми результатов на основе непонятно чего назначить единственно правильный вариант. Что и будет благополучно отодвинуто в сторону и забыто.[/quote]
нало же, хочется повторить за Хищником... что бы это значило.
когда разнообразие трудноисчерпаемо, то нормы (в стандартах также) уступают место определениям
- конкретные нормы - общим определениям
иногда это определение описывает сам предмет, иногда - способ формализации описания предмета
|
|
|
|
Добавлено: Вс авг 23, 2009 22:22 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Хищник писал(а): А все остальные разновидности, получается, из рассмотрения выпадают?
да, выпадают как менее регулярные и более сложные. DTC, STC - более сложны? mOleg писал(а): и да и нет. Базовый метод (шкала с фиксированной точкой отсчета) должен быть описан. Вопрос только в том, что за базу взять. насчет семантики согласен, но одно без другого как? Вот и предлагаю я взять базовую модель Форт-машины, с базовой моделью выполнения кода,,, и так далее.
Тут получается не взять, а из всего многообразия достигнутых разными людьми результатов на основе непонятно чего назначить единственно правильный вариант. Что и будет благополучно отодвинуто в сторону и забыто.
[quote="mOleg"]Хищник писал(а): А все остальные разновидности, получается, из рассмотрения выпадают?
да, выпадают как менее регулярные и более сложные. [/quote] DTC, STC - более сложны? [quote="mOleg"]и да и нет. Базовый метод (шкала с фиксированной точкой отсчета) должен быть описан. Вопрос только в том, что за базу взять. насчет семантики согласен, но одно без другого как? Вот и предлагаю я взять базовую модель Форт-машины, с базовой моделью выполнения кода,,, и так далее.[/quote]
Тут получается не взять, а из всего многообразия достигнутых разными людьми результатов на основе непонятно чего назначить единственно правильный вариант. Что и будет благополучно отодвинуто в сторону и забыто.
|
|
|
|
Добавлено: Вс авг 23, 2009 22:14 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Хищник писал(а): А все остальные разновидности, получается, из рассмотрения выпадают? да, выпадают как менее регулярные и более сложные. Хищник писал(а): При чем тут вообще ШК, если для ВМ важнее семантика, а уж варианты реализации просто перечисляются, и служат иллюстрацией к возможным методам реализации?
и да и нет. Базовый метод (шкала с фиксированной точкой отсчета) должен быть описан. Вопрос только в том, что за базу взять.
насчет семантики согласен, но одно без другого как?
Вот и предлагаю я взять базовую модель Форт-машины, с базовой моделью выполнения кода,,, и так далее.
[quote="Хищник"]А все остальные разновидности, получается, из рассмотрения выпадают? [/quote] да, выпадают как менее регулярные и более сложные.
[quote="Хищник"]При чем тут вообще ШК, если для ВМ важнее семантика, а уж варианты реализации просто перечисляются, и служат иллюстрацией к возможным методам реализации?[/quote]
и да и нет. Базовый метод (шкала с фиксированной точкой отсчета) должен быть описан. Вопрос только в том, что за базу взять.
насчет семантики согласен, но одно без другого как?
Вот и предлагаю я взять базовую модель Форт-машины, с базовой моделью выполнения кода,,, и так далее.
|
|
|
|
Добавлено: Вс авг 23, 2009 21:33 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Короче, опять возникает проблема, что брать за основу - я предлагаю ITC (косвенный ШК), либо индексную ВМ (но это хуже уже хотя бы потому, что реализации ШК через индексную таблицу не распространены).
А все остальные разновидности, получается, из рассмотрения выпадают? При чем тут вообще ШК, если для ВМ важнее семантика, а уж варианты реализации просто перечисляются, и служат иллюстрацией к возможным методам реализации?
[quote="mOleg"]Короче, опять возникает проблема, что брать за основу - я предлагаю ITC (косвенный ШК), либо индексную ВМ (но это хуже уже хотя бы потому, что реализации ШК через индексную таблицу не распространены).[/quote]
А все остальные разновидности, получается, из рассмотрения выпадают? При чем тут вообще ШК, если для ВМ важнее семантика, а уж варианты реализации просто перечисляются, и служат иллюстрацией к возможным методам реализации?
|
|
|
|
Добавлено: Вс авг 23, 2009 21:28 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): Я имел ввиду тот факт, что не стоит фиксировать конкретное решение, выбранное при создании Форт-процессора, как базовое (ведь возможны варианты).
Так ведь предлагается фиксировать не конкретное решение (в конкретном я бы еще указал, что 4(5,6...) бит на опкод, и про префиксы бы ввернул), а более широкое (в том числе включающее в себя вариант с одним опкодом на CELL).
[quote="mOleg"]Я имел ввиду тот факт, что не стоит фиксировать конкретное решение, выбранное при создании Форт-процессора, как базовое (ведь возможны варианты). [/quote]
Так ведь предлагается фиксировать не конкретное решение (в конкретном я бы еще указал, что 4(5,6...) бит на опкод, и про префиксы бы ввернул), а более широкое (в том числе включающее в себя вариант с одним опкодом на CELL).
|
|
|
|
Добавлено: Вс авг 23, 2009 21:24 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
WingLion писал(а): mOleg писал(а):1 CELL хранит одну ссылку на команду. Данное предложение включает в себя и вариант, когда один опкод в CELL... A вот закрепление одного опкода в одном CELL исключает остальные варианты, что не есть гуд. описание базовой модели Форт (Виртуальной) Машины ни коим образом ни в чем не ограничивает создателей ФМ, и ФВМ. Оно лишь является базой для пояснения работы основных механизмов Форт-системы в целом, но при этом так же не налагается ограничений на методики реализации (главное, чтобы интерфейсы: имена и входящие параметры - оставались фиксированными). На мой взгляд тут надо разойтись с проблемой типа "курица:яйцо", и для этого надо что-то предварительно зафиксировать(яйцо) и добираться до "курицы" итеративно, как это принято в Форте. WingLion писал(а): подробнее можно, в каком месте не совпадает, а то не пойму что-то.
прошу прощения, я не совсем точно выразился. Я имел ввиду тот факт, что не стоит фиксировать конкретное решение, выбранное при создании Форт-процессора, как базовое (ведь возможны варианты).
Короче, опять возникает проблема, что брать за основу - я предлагаю ITC (косвенный ШК), либо индексную ВМ (но это хуже уже хотя бы потому, что реализации ШК через индексную таблицу не распространены).
[quote="WingLion"]mOleg писал(а):1 CELL хранит одну ссылку на команду. Данное предложение включает в себя и вариант, когда один опкод в CELL... A вот закрепление одного опкода в одном CELL исключает остальные варианты, что не есть гуд.[/quote] описание базовой модели Форт (Виртуальной) Машины ни коим образом ни в чем не ограничивает создателей ФМ, и ФВМ. Оно лишь является базой для пояснения работы основных механизмов Форт-системы в целом, но при этом так же не налагается ограничений на методики реализации (главное, чтобы интерфейсы: имена и входящие параметры - оставались фиксированными). На мой взгляд тут надо разойтись с проблемой типа "курица:яйцо", и для этого надо что-то предварительно зафиксировать(яйцо) и добираться до "курицы" итеративно, как это принято в Форте.
[quote="WingLion"]подробнее можно, в каком месте не совпадает, а то не пойму что-то.[/quote]
прошу прощения, я не совсем точно выразился. Я имел ввиду тот факт, что не стоит фиксировать конкретное решение, выбранное при создании Форт-процессора, как базовое (ведь возможны варианты).
Короче, опять возникает проблема, что брать за основу - я предлагаю ITC (косвенный ШК), либо индексную ВМ (но это хуже уже хотя бы потому, что реализации ШК через индексную таблицу не распространены).
|
|
|
|
Добавлено: Вс авг 23, 2009 21:18 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): 1 CELL хранит одну ссылку на команду. Данное предложение включает в себя и вариант, когда один опкод в CELL... A вот закрепление одного опкода в одном CELL исключает остальные варианты, что не есть гуд. mOleg писал(а): Я не считаю, что заявленная тема топика совпадает с содержимым 8(
подробнее можно, в каком месте не совпадает, а то не пойму что-то.
[quote="mOleg"]1 CELL хранит одну ссылку на команду.[/quote] Данное предложение включает в себя и вариант, когда один опкод в CELL... A вот закрепление одного опкода в одном CELL исключает остальные варианты, что не есть гуд.
[quote="mOleg"]Я не считаю, что заявленная тема топика совпадает с содержимым 8([/quote]
подробнее можно, в каком месте не совпадает, а то не пойму что-то.
|
|
|
|
Добавлено: Вс авг 23, 2009 21:10 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
mOleg писал(а): А классика - это косвенный шитый код.
А мне казалось, что классика - это Пушкин и Толстой
[quote="mOleg"]А классика - это косвенный шитый код.[/quote]
А мне казалось, что классика - это Пушкин и Толстой :))
|
|
|
|
Добавлено: Вс авг 23, 2009 20:59 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
Я не считаю, что заявленная тема топика совпадает с содержимым 8(
Для виртуальной машины данный вариант не удобен, так как достаточно сложен, требует дополнительных регистров, и оказывается неспешен.
Придумывать на мой взгляд ничего не надо нового, а нужно взять классику. А классика - это косвенный шитый код. А в ITC 1 CELL хранит одну ссылку на команду.
Я не считаю, что заявленная тема топика совпадает с содержимым 8(
Для виртуальной машины данный вариант не удобен, так как достаточно сложен, требует дополнительных регистров, и оказывается неспешен.
Придумывать на мой взгляд ничего не надо нового, а нужно взять классику. А классика - это косвенный шитый код. А в ITC 1 CELL хранит одну ссылку на команду.
|
|
|
|
Добавлено: Вс авг 23, 2009 20:46 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
in4 писал(а): А можно рассказать подробнее, почему приняты такие особенности работы RET и CALL ?
Кажется, уже где-то рассказывал, но можно и повториться.
для CALL "забывание" команд обусловлено тем, что при вызове подпрограммы происходит загрузка IP новым значением и немедленно загружается новый пакет опкодов, поэтому старые пропадают. В противном случае, их пришлось бы где-то запоминать (в расширенном стеке возвратов?) а это не подходит. Возврат из подпрограммы в середину пачки опкодов - невозможен.
для RET ситуация иная. Загрузка IP новым значением происходит из стека возвратов, и так же может быть сделана немедленная загрузка новых опкодов, но, если дешифратор производит поиск RET в пакете опкодов заранее, то при немедленной загрузке после изменения IP произойдет забывание всех опкодов, в том числе и тех, что еще не успели выполниться перед RET.
Кроме того, исполнение опкодов после RET полезно еще в некоторых случаях в конкретной реализации форт-процессора.
[quote="in4"]А можно рассказать подробнее, почему приняты такие особенности работы RET и CALL ?[/quote]
Кажется, уже где-то рассказывал, но можно и повториться.
для CALL "забывание" команд обусловлено тем, что при вызове подпрограммы происходит загрузка IP новым значением и немедленно загружается новый пакет опкодов, поэтому старые пропадают. В противном случае, их пришлось бы где-то запоминать (в расширенном стеке возвратов?) а это не подходит. Возврат из подпрограммы в середину пачки опкодов - невозможен.
для RET ситуация иная. Загрузка IP новым значением происходит из стека возвратов, и так же может быть сделана немедленная загрузка новых опкодов, но, если дешифратор производит поиск RET в пакете опкодов заранее, то при немедленной загрузке после изменения IP произойдет забывание всех опкодов, в том числе и тех, что еще не успели выполниться перед RET.
Кроме того, исполнение опкодов после RET полезно еще в некоторых случаях в [url=http://fforum.winglion.ru/viewtopic.php?t=1517]конкретной реализации форт-процессора.[/url]
|
|
|
|
Добавлено: Вс авг 23, 2009 19:46 |
|
|
|
|
|
Заголовок сообщения: |
|
|
|
А можно рассказать подробнее, почему приняты такие особенности работы RET и CALL ?
А можно рассказать подробнее, [b]почему[/b] приняты такие особенности работы [b]RET[/b] и [b]CALL[/b] ?
|
|
|
|
Добавлено: Вс авг 23, 2009 19:07 |
|
|
|
|
|
Заголовок сообщения: |
Базовый формат команды для форт-процессора (ВФМ) |
|
|
Базовый формат команды для форт-процессора (Виртуальной Форт Машины)
При исполнении опкода перехода, происходит сбрасывание выбранных вслед за CALL опкодов.
Исключение составляет опкод команды RET, который может исполняться заранее, если дешифратор команд обнаружит его в списке загруженных опкодов и перед ним нет выборки литерала или команды перехода. В соответствии с этим после исполнения RET происходит и выполнение всех опкодов, считанных после RET, т.е. Если считано: LIT LIT RET !, то после RET произойдет выполнение команды !.
В то же время, если считана последовательность LIT CALL LIT @, то после CALL производится немедленная загрузка новой порции опкодов из адреса, куда сделан вызов без исполнения следующих за CALL опкодов.
Базовый формат команды для форт-процессора (Виртуальной Форт Машины)
[img]http://fforum.winglion.ru/att/forth-code.png[/img]
При исполнении опкода перехода, происходит сбрасывание выбранных вслед за CALL опкодов.
Исключение составляет опкод команды [b]RET[/b], который может исполняться заранее, если дешифратор команд обнаружит его в списке загруженных опкодов и перед ним нет выборки литерала или команды перехода. В соответствии с этим после исполнения RET происходит и выполнение всех опкодов, считанных после [b]RET[/b], т.е. Если считано: [b]LIT LIT RET ![/b], то после RET произойдет выполнение команды [b]![/b].
В то же время, если считана последовательность [b]LIT CALL LIT @[/b], то после CALL производится немедленная загрузка новой порции опкодов из адреса, куда сделан вызов без исполнения следующих за CALL опкодов.
|
|
|
|
Добавлено: Вс авг 23, 2009 11:30 |
|
|
|
|