Forth
http://fforum.winglion.ru/

о преимуществах и недостатках существующих стандартов
http://fforum.winglion.ru/viewtopic.php?f=36&t=1799
Страница 3 из 6

Автор:  Hishnik [ Сб янв 17, 2009 22:05 ]
Заголовок сообщения: 

Но если ячейка памяти может вместить и данные, и адрес, то в VALUE влезет и то, и другое.

Автор:  mOleg [ Сб янв 17, 2009 22:09 ]
Заголовок сообщения: 

Хищник писал(а):
Но если ячейка памяти может вместить и данные, и адрес, то в VALUE влезет и то, и другое.

можно, но это не означает, что форматы данных будут совпадать. К примеру, адрес возврата может состоять из двух чисел: seg disp (кажется так было в FPC), тогда с помощью A>R переносится два числа на стек возвратов(точнее число двойной длины), а с помощью >R число одинарной длины.
VALUE переменная по умолчанию возвращает число одинарной длины... то есть адрес не помещается.
Может быть обратная ситуация.

Автор:  Hishnik [ Сб янв 17, 2009 22:55 ]
Заголовок сообщения: 

Так, хорошо. Тогда может иметь немалый смысл определить области действия стандарта. Если мы сейчас будем угождать и нашим, и вашим, будет совсем плохо. Универсальная система часто оказывается неэффективной (именно из-за наличия внутри массы компромиссов и "регулировок"). Сейчас ситуация видится так.
1) PC. 32/64 бита. Если адрес больше данных, то это означает адресное пространство более 4 Гб на 32-разрядной основной машине. Вот тогда-то и начинаются проблемы с обычным union. Решение может быть "чисто силовое" - запретить такие вещи. Надо сказать, что эта проблема уже далеко не настолько остра, как в 16-битных форт-системах. Вот там предел в 64 кб был действительно актуальным и была масса способов расширения адресного пространства. То есть получается, что сойдет и "мягкое" ограничение в виде union, с оговоркой, что если уж вам надо больше 4Г, то и озаботьтесь переходом к соответствующей разрядности ячейки данных.
2) МК и форт-процессоры. Тут налицо актуальность экономии ресурсов. Стек возвратов в форт-процессорах практически однозначно имеет разрядность, строго равную разрядности адресов (обычно это даже меньше 16). Делать 32 бита очень нерационально, просто потому, что ресурсоемкость существенно растет, а весь сыр-бор укладывается в аргумент "ну а вдруг кому-то захочется".

Автор:  mOleg [ Сб янв 17, 2009 23:00 ]
Заголовок сообщения: 

по первому частично согласен (только ты не учел различные типы ШК)

Хищник писал(а):
2) МК и форт-процессоры. Тут налицо актуальность экономии ресурсов. Стек возвратов в форт-процессорах практически однозначно имеет разрядность, строго равную разрядности адресов (обычно это даже меньше 16). Делать 32 бита очень нерационально, просто потому, что ресурсоемкость существенно растет, а весь сыр-бор укладывается в аргумент "ну а вдруг кому-то захочется".


ты забыл еще один вариант(самый распространенный) - форт-система на микроконтроллере от фирм, которые не делают форт-чипы.

Автор:  Hishnik [ Сб янв 17, 2009 23:29 ]
Заголовок сообщения: 

mOleg писал(а):
ты забыл еще один вариант(самый распространенный) - форт-система на микроконтроллере от фирм, которые не делают форт-чипы.

Я же написал - МК. Там тоже попадается вариант 2, данные могут быть и 32-битные, а счетчик команд на 16 бит. Но если ресурсы есть, все плавно сводится к системе 32/32.

Автор:  mOleg [ Пн янв 19, 2009 20:47 ]
Заголовок сообщения: 

еще пара моментов.
переменная STATE скорее должна быть VALUE переменной, в то время, как SOURCE-ID обычной VARIABLE.
собственно STATE чаще всего используется в виде STATE @ а изменяется только словами [ ] (чаще всего).

Автор:  Hishnik [ Пн янв 19, 2009 21:01 ]
Заголовок сообщения: 

Кстати, не факт. В ассемблере удобнее рассматривать state просто как область памяти. А VALUE удобна для Форта, и ее оформление появляется дальше по тексту. Поэтому если мы напишем

state dd 0
то можем потом оформить слово STATE как код, кладущий на стек state. Можно, конечно, и mov eax, [state] вместо mov eax, state, но тогда как на ранних этапах разработки выполнять запись туда? Придется добираться до адреса, по которому лежит это значение, и писать непосредственно туда, а это уже зависит от структуры VALUE.

Автор:  mOleg [ Пн янв 19, 2009 21:04 ]
Заголовок сообщения: 

Хищник писал(а):
Кстати, не факт. В ассемблере удобнее рассматривать state просто как область памяти. А VALUE удобна для Форта, и ее оформление появляется дальше по тексту. Поэтому если мы напишем

state dd 0

то можем потом оформить слово STATE как код, кладущий на стек state. Можно, конечно, и mov eax, [state] вместо mov eax, state, но тогда как на ранних этапах разработки выполнять запись туда? Придется добираться до адреса, по которому лежит это значение, и писать непосредственно туда, а это уже зависит от структуры VALUE.

ну, как-то же дальше определяются VALUE переменные - тот же SOURCE-ID
кроме того, state является USER переменной, а значит, уже не так просто "state dd 0"

Автор:  Hishnik [ Пн янв 19, 2009 21:18 ]
Заголовок сообщения: 

mOleg писал(а):
кроме того, state является USER переменной, а значит, уже не так просто "state dd 0"

Просто state dd 0 :) USER-переменные - это из области "первопроходческой многозадачности", которая в современных условиях выглядит достаточно надуманной. Разве что из ностальгических соображений можно продолжать выполнять "закат солнца вручную", когда такие ОС, как Windows/Linux, могут без особых проблем назапускать множество копий одного приложения.

Автор:  mOleg [ Пн янв 19, 2009 21:21 ]
Заголовок сообщения: 

Хищник писал(а):
Windows/Linux, могут без особых проблем назапускать множество копий одного приложения.

про Windows пожалуйста подробнее, очень интересно как можно сделать линуксевые потоки :)

Автор:  Hishnik [ Пн янв 19, 2009 21:53 ]
Заголовок сообщения: 

Пуск -> программы -> стандартные -> калькулятор. И так 5 раз.

Автор:  mOleg [ Пт янв 23, 2009 21:15 ]
Заголовок сообщения: 

Хищник писал(а):
Пуск -> программы -> стандартные -> калькулятор. И так 5 раз.

а зачем вы это сказали? зачем хамить-то? вопрос ведь задан совсем другой!

Автор:  mOleg [ Пт янв 23, 2009 21:26 ]
Заголовок сообщения: 

еще один момент, касающийся ФМ (Форт машины и вирутальной и железной).
Совсем не обязательно, что разрядность стеков (данных и возвратов) будет совпадать, и совсем не обязательно, что адреса на стеке возвратов будут представляться простым образом.
Предложение: набор слов, работающих со стеком возвратов расширить и изменить следующим образом:

A>R - перенести адрес на вершину стека возвратов, причем, такой адрес будет действительным для EXIT, то есть операция A>R EXIT аналогична EXECUTE
AR> - перенести адрес на вершину стека данных, причем такой адрес можно использовать совместно с @ и ! , таким образом литерал может быть определен через : (lit) AR> DUP @ SWAP ADDR + A>R ;
AR@ - копировать адрес на вершину стека данных с вершины стека возвратов, полученным адресом можно пользоваться для нахождения данных.
ARDROP - удалить адрес с вершины стека возвратов
AR+ - добавить число к содержимому верхнего элемента стека возвратов, число должно иметь разрядность CELL
>R - перенести CELL число на вершину стека возвратов, при этом это самое число на стеке возвратов может занимать, к примеру, две ячейки
R> - перенести CELL число на вершину стека данных
R@ - копировать CELL число на вершину стека данных
R+ - добавить CELL значение к CELL значению на вершине стека данных
RDROP - удалить CELL значение с вершины стека возвратов
при условии одинаково разрядности данных и адресов, а так же прямой адресации возвратов (например, как в SPF сделано), слова:
>R R> R@ R+ RDROP будут являться ALIAS-ами слов A>R AR> AR@ AR+ ARDROP, то есть дублирования кода не будет, а будет просто несколько имен у одного кода.

Автор:  Hishnik [ Сб янв 24, 2009 00:31 ]
Заголовок сообщения: 

mOleg писал(а):
Хищник писал(а):
Пуск -> программы -> стандартные -> калькулятор. И так 5 раз.

а зачем вы это сказали? зачем хамить-то? вопрос ведь задан совсем другой!

:shock: А в чем хамство-то? Было же написано:

Хищник писал(а):
Windows/Linux, могут без особых проблем назапускать множество копий одного приложения.

Чем калькулятор не приложение и почему я не могу аналогично запустить пять кварков? Зачем мне еще что-то добавлять в само приложение, когда его копии легко запускаются операционной системой?

Автор:  вопрос [ Сб янв 24, 2009 00:34 ]
Заголовок сообщения: 

Хищник писал(а):
Зачем мне еще что-то добавлять в само приложение, когда его копии легко запускаются операционной системой?

Пусть Хищник наконец-то укажет, какие задачи ему кажутся приоритетными для форт-сообщества в целом :) :wink:

Страница 3 из 6 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/