Forth http://fforum.winglion.ru/ |
|
Хард-подход к стандарту на Форт http://fforum.winglion.ru/viewtopic.php?f=36&t=1913 |
Страница 5 из 7 |
Автор: | in4 [ Вт фев 03, 2009 04:17 ] |
Заголовок сообщения: | |
WingLion писал(а): Хотя, EXECUTE - это должен быть скорее CALL по адресу из стека данных. а точно не JMP ? Обязательно возвращаться? Если да, то сложнее код патчить... И с реализацией структур управления будут трудности... А также: in4 писал(а): OVER - обязательное
SWAP - необязательное INV (dd2 dd1 --> dd2 ^dd1) - желательно в расширенном списке SWAP по-другому работает со стеком. И возможны варианты, когда без него будет лучший дизайн софтпроца. INV == NOT хотелось бы для полноты логики, раз уж есть AND и OR ... |
Автор: | WingLion [ Вт фев 03, 2009 08:46 ] |
Заголовок сообщения: | |
in4 писал(а): а точно не JMP ? Обязательно возвращаться? Если да, то сложнее код патчить... Sad И с реализацией структур управления будут трудности... Sad JMP - это все-таки переход по непосредственному адресу, а не по адресу, взятому из стека данных.in4 писал(а): SWAP по-другому работает со стеком. И возможны варианты, когда без него будет лучший дизайн софтпроца. Честно говоря, не понимаю, откуда такой "страх" перед SWAP. прекрасно он реализуется в софт-процессоре и без всяких проблем. in4 писал(а): INV == NOT хотелось бы для полноты логики, раз уж есть AND и OR ...
: INV -1 XOR ; - это для ленивых. А вообще, никто не запрещает делать в форт-процессоре дополнительные команды. : NOT IF FALSE ELSE TRUE THEN ; - так логичнее, по моему, нежели NOT = INV |
Автор: | Kopa [ Вт фев 03, 2009 09:08 ] |
Заголовок сообщения: | |
размышляя над системой команд появились такие мысли ( Возможно эта идея уже обсуждалась:) Исполнение токенов можно организовать по такой схеме 1. Состояние выборки токенов на управляющий стек. 2. Встретив токен EXEC переходим к их исполнению до исчерпания управляющего стека. Этот механизм решает по своему заморочки с LIT Например выбрав: LIT LIT EXEC \ получаем на стеке данных 2-a литерала из программной памяти \ После чего опять переходим к выборке команд до следующего EXEC Можно предусмотреть пакетный или одиночный режим EXEC. Необходимость использования управлящего стека, при этом, под вопросом. Далее размышления привели к такому варианту: Ввести отдельный бит в каждом токене ( IMMEDIATE) указывающий, что токен с ним и ранее выбранные токены ( не имеющие признак IMMEDIATE ) необходимо исполнить. Это может помочь в решении: 1. вышеозначенной проблемы с литералами. 2. указании cpu на возможность ( если она есть) включить сложный механизм декодирования и выполнения цепочки токенов. 3. существует потенциальная возможность, при нехватке токенов, ввести новую команду cpu (макро токен). P.S. Интересны подводные камни при этом подходе. |
Автор: | Hishnik [ Вт фев 03, 2009 19:27 ] |
Заголовок сообщения: | |
Kopa писал(а): Исполнение токенов можно организовать по такой схеме
1. Состояние выборки токенов на управляющий стек. 2. Встретив токен EXEC переходим к их исполнению до исчерпания управляющего стека. А зачем такое и чем оно лучше "одноуровневого стека"? Процессор - это же не программа, он все время что-то делает. И задача проектирования процессора - обеспечить ему правильные логические уровни для всех модулей на каждом такте. Операция "помещение токенов на управляющий стек" - это тоже операция, она занимает время (такты) и ресурсы железа. А потом это все будет выполняться. Почему потом - немного непонятно, ведь можно было никуда не класть, а выполнять сразу, тем более что для помещения на управляющий стек надо будет попросту остановить исполнительные блоки. |
Автор: | Kopa [ Ср фев 04, 2009 08:40 ] |
Заголовок сообщения: | |
Хищник писал(а): А потом это все будет выполняться. Почему потом - немного непонятно, ведь можно было никуда не класть, а выполнять сразу, тем более что для помещения на управляющий стек надо будет попросту остановить исполнительные блоки.
Возможность непосредственного выполнения токенов, при установленном бите IMMEDIATE остаётся. В рассмотренной, как идея, схеме команды имеют возможность попадания команд на стек управления как данные, а следующая команда может сама, как вариант, нужным способом их обработать или инициировать процесс выполнения, например, с верхнего элемента стека управления. ( Например: CMP LIT @ LIT @ LIT \ сравнение содержимого двух ячеек памяти ) Если в системе команд есть команды доступа и к этому стеку, то возможно появляются ранее мало используемые схемы организации работы алгоритмов, ( стек похож в данном случае на кеш а подкачкой этого кеша тоже можно из предложенной схемы частично управлять). P.S. Практичен или нет данный подход мне трудно оценить, но идея мне нравится на "подсознательном":) уровне. Лишним или нет будет ещё один стек в системе, не знаю. Расход в 1бит на байт и при необходимости формировать литералы предлагаемым способом один опкод на каждый литерал. |
Автор: | WingLion [ Ср фев 04, 2009 09:03 ] |
Заголовок сообщения: | |
Kopa писал(а): ( Например: CMP LIT @ LIT @ LIT \ сравнение содержимого двух ячеек памяти )
К обратной польской записи выражений народ уже привык, но против "обратной арабской записи программ" он, думаю, просто взбунтуется. |
Автор: | Hishnik [ Ср фев 04, 2009 10:03 ] |
Заголовок сообщения: | |
Kopa писал(а): Возможность непосредственного выполнения токенов, при установленном бите IMMEDIATE
остаётся. Решение полностью эквивалентно пересылке программы из одного места памяти в другое перед выполнением. И да, с помощью этого можно строить алгоритмы, а процессом перекладывания - управлять. Вот только почему ему на месте не лежится, и зачем надо перед выполнением поперекладывать из ячейки в ячейку? |
Автор: | Kopa [ Ср фев 04, 2009 11:09 ] |
Заголовок сообщения: | |
Хищник писал(а): Kopa писал(а): Возможность непосредственного выполнения токенов, при установленном бите IMMEDIATE остаётся. Решение полностью эквивалентно пересылке программы из одного места памяти в другое перед выполнением. И да, с помощью этого можно строить алгоритмы, а процессом перекладывания - управлять. Вот только почему ему на месте не лежится, и зачем надо перед выполнением поперекладывать из ячейки в ячейку? Может из-за того, если предположить, что необходимо использовать Гарвардскую архитектуру? и непосредственный доступ к памяти программ не очень хорошее решение при изоляции одного кода от другого в рамках одного ядра. P.S. Другие аргументы ( возможно мало практичные ) в предыдущих топиках:) |
Автор: | Kopa [ Ср фев 04, 2009 11:14 ] |
Заголовок сообщения: | |
WingLion писал(а): Kopa писал(а): ( Например: CMP LIT @ LIT @ LIT \ сравнение содержимого двух ячеек памяти ) К обратной польской записи выражений народ уже привык, но против "обратной арабской записи программ" он, думаю, просто взбунтуется. А это уже транслятор может снять эти "выверты":) |
Автор: | chess [ Ср фев 04, 2009 12:59 ] |
Заголовок сообщения: | |
По поводу несовместимости. Несовместимость Форт-систем в основном закладывается на этапе реализации(эмуляции) Форт-ВМ на реальной машине. Реализация(эмуляция) структуры памяти ФВМ, реализация(эмуляция) стеков ФВМ, реализация(эмуляция) команд ФВМ - на любом из этих этапов может произойти закладка несовместимости в Форт-систему. В стандарт необходимо изначально заложить ограничения, которые должны быть выполнены в конкретной реализации(эмуляции) ФВМ. |
Автор: | mOleg [ Ср фев 04, 2009 17:44 ] |
Заголовок сообщения: | |
chess писал(а): В стандарт необходимо изначально заложить ограничения, которые должны быть выполнены в конкретной реализации(эмуляции) ФВМ.
это как раз то, что мне никак не удается донести до WingLion 8( абсолютно согласен. кстати, насчет того, что мы забыли про гарвард... мы забыли и про другие модели памяти, все опять скатилось к только плоской памяти с возможно хардварными стеками 8( вобщем опять системный просчет... |
Автор: | Hishnik [ Ср фев 04, 2009 18:36 ] |
Заголовок сообщения: | |
Kopa писал(а): Может из-за того, если предположить, что необходимо использовать Гарвардскую архитектуру?
и непосредственный доступ к памяти программ не очень хорошее решение при изоляции одного кода от другого в рамках одного ядра. Не вижу, как предложенное позволяет обойти эту проблему. Вернее, вижу, что никак. Если вместо того, чтобы положить картошку в кастрюлю, я предварительно покидаю ее в руках, а только потом положу, результат все равно будет одинаковый - картошка в кастрюле. |
Автор: | Hishnik [ Ср фев 04, 2009 18:39 ] |
Заголовок сообщения: | |
mOleg писал(а): кстати, насчет того, что мы забыли про гарвард... мы забыли и про другие модели памяти, все опять скатилось к только плоской памяти с возможно хардварными стеками 8( вобщем опять системный просчет...
Гарвардская архитектура тоже может быть плоской. И деление на фон-Нейман/гарвард абсолютно перпендикулярно плоской/сегментированной модели. В рамках спора с этим утверждением я хотел бы видеть RTL-представление, а не общие слова. |
Автор: | mOleg [ Ср фев 04, 2009 18:42 ] |
Заголовок сообщения: | |
Хищник писал(а): Гарвардская архитектура тоже может быть плоской. собственно речь о том, что надо начинать с различных моделей памяти, а Гарвард или нет это уже вторично. Хищник писал(а): RTL-представление что есть RTL ?
|
Автор: | Hishnik [ Ср фев 04, 2009 18:56 ] |
Заголовок сообщения: | |
mOleg писал(а): собственно речь о том, что надо начинать с различных моделей памяти, а Гарвард или нет это уже вторично. Оно не вторично, а просто из другой области. Это способ доведения команды до ее декодера, и ничего более. С точки зрения электроники, линии, ответственные за номер сегмента, ничем не отличаются от линий, ответственных за смещение ячейки памяти в этом сегменте. mOleg писал(а): что есть RTL ?
Register Transfer Level. Я вот все думаю, когда же вместо рассуждений о возможных характеристиках процессора таки начнутся уточнения, как же он устроен? Мы с Winglion-ом на пару закрываем вопросы проектирования для обоих ведущих производителей ПЛИС... так нет, надо обязательно поспорить по пунктам, которые становятся очевидны разве что через несколько лет регулярной работы. Ну вперед... а я пока Proteus еще подрихтую |
Страница 5 из 7 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |