_Loader_ - Page 6

Do you have a question? Post it now! No Registration Necessary

Threaded View
Re: _Loader_
Всем привет.

Quoted text here. Click to load it

Может. Причем почти всегда результатом будет так-же вывод ошибки (возможно не в
том месте и не того типа).

Quoted text here. Click to load it

Для того, что-бы Форт стал нужен, нужны очень крупные проекты с Форт-ядром. По
сути нужен второй Linux :). Иначе задача будет решатся на Си (Делфи, Жаба,
VB...) как-бы криво она на них не ложилась.

Quoted text here. Click to load it

Конечный продукт :). Хотя очень трудно провести границу между ними.

Quoted text here. Click to load it

В принципе верно, НО !!! Задача программистом решается ДО создания грамматики
соответствующей области решаемой задачи. Далее знание Форта практически не
нужны - использовать полученную грамматику может и специалист в области задачи.
Причем эта грамматика может быть очень гибкой и очень дуракоустойчивой
одновременно (сохраняя высокую эффективность т.к. при исполнении задачи
интерпретатор уже не работает :) ). Кстати Eserv, acWeb, nnCron, xMenu примеры
именно такого подхода.

Quoted text here. Click to load it

Ну а если эта ОС называется Форт-система, чем это не устраивает? Т.е. между
Форт-системой и железом ничего кроме BIOS и где-то лежащего DOSа нет, чем это
хуже при решении критичных по времени задач?

Quoted text here. Click to load it
набивать
Quoted text here. Click to load it

Можно и с клавиатуры - грамматика для решения задачи обычно уже в Форт-системе
есть. А вообще - компилируешь с диска (файл в терминах задачи) и запускаешь.

Quoted text here. Click to load it

Завершить текушую задачу, пойти к программисту и изложить требования к
следующей. Он поработает, создаст исполнимый файл и передаст для запуска на
твоей машине и так каждый раз!?
О циклах отладки я помолчу...

                                              АртемКАД




Re: _Loader_
11-Oct-03 08:06 Alex Kouznetsov wrote to Vladimir Vassilevsky:

AK> Из отрицательных - в основном психологические факторы. Многие из тех,
AK> кто
AK> привык работать на сях, изучать Форт не желают. Приводят любые доводы и
AK> отговорки, вплоть до самых глупых.

 С одной стороны -- неопровержимо.

 С другой...
 Было недавно на телесистемах обсуждение вопроса "почему к avreal нет GUI".
 В числе прочих на полном серьёзе было высказано мнение, что либо мне лень
писать такую оболочку, либо я этого не в состоянии сделать. А все аргументы,
которые я привожу за то, что программатор должен быть командной строкой --
это подведение идеологической базы под это дело.

wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: _Loader_
11-Oct-03 08:06 Alex Kouznetsov wrote to Vladimir Vassilevsky:

AK> стека не менее 200 байт, не говоря уж об остальных ресурсах. Еле-еле все
AK> вместе влезло на H8S. Узнай разницу в цене между ПИКом и H8S, и спроси
AK> себя - на что эти деньги потрачены?

 Кстати, хотел уже когда-то спросить, но всё не решался...
А сейчас вот под шумок спрошу.

 Артём объяснил, почему он пишет для однокристалок на асме,
а не на форте.

7-Oct-03 06:59 Artem Kamburov wrote to Oleksandr Redchuk:

AK> вроде как указал - средняя задача и выше. Вот в 8515 или Мега8 уже можно
AK> развернуться, а в 2313, Тини12, Тини15, Тини26 необходим полный контроль
AK> за кодом и любой отсебятины со стороны компилятора допускать нельзя.

Т.е. для него просто не имеет смысла для тех мелких кристаллов,
которые он применяет, использовать форт (хотя и тут есть что пообсуждать).

А почему тобой для H8S пишется не на форте? Кристалл ведь достаточно
толстый, даже небольшая RTOS, AFAIR, влезла. Можно было бы
зарядить в ПЗУ ядро форта, в ОЗУ складывать только свежеотлаживаемые
слова, по мере отладки переписывать в ПЗУ.

Я что-то не понял?

wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Re: _Loader_
Sun Oct 12 2003 03:52, Oleksandr Redchuk wrote to "Alex Kouznetsov":

 OR> А почему тобой для H8S пишется не на форте?

Велено было писать на це, "для совместимости" и пр. Я дисциплинированный
человек, подчиняюсь приказам. Даже глупым.

 OR> Кристалл ведь достаточно
 OR> толстый, даже небольшая RTOS, AFAIR, влезла.

Небольшая самодельная влезла, на це написал.

 OR> Можно было бы зарядить в ПЗУ ядро форта,
 OR> в ОЗУ складывать только свежеотлаживаемые
 OR> слова, по мере отладки переписывать в ПЗУ.

Это было бы правильнее во всех смыслах. И свое мнение по этому поводу я не
скрывал. Если начальство желает выбрасывать деньги на ветер - это его дело, не
мое.

Пока,       Алексей


Re: _Loader_
Всем привет.

Quoted text here. Click to load it
пробелам).

Ма-аленькое дополнение - по пробельным символам. А ими могут быть весьма разные
элементы - например, всем известные по Си { } или известные по ДОСу слеши или
известные по математике скобки. Если учесть, что набор можно динамически менять,
вот Вам и инструмент для разбора почти любой строки. Причем этот инструмент
доступен не только компилятору, но и пользовательской программе.

Quoted text here. Click to load it

Последнее совсем не понял :(.

Quoted text here. Click to load it

М-да. Описанное Вами и есть тот цирковой велосипед, о котором говорил Орлов.

Современные Форт-системы (кстати этим современным уже лет по 10) смахивают на
описанное Вами только процентов на 5.

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

Quoted text here. Click to load it

Действительно, таких компиляторов мало (смесь Бейсика (режим исполнения), асма
(низкий уровень) и СУБД (контексты) в одном флаконе), а компиляторов
предоставляющих ВСЕ свои инструменты для конечной программы вообще нет.

А по поводу того, что Алголоподобных языков много, а Форт один - так диалектов
Форта то-же много. Причем многие из них отличаются друг от друга  как Си от
Паскаля или Модулы.

                                АртемКАД




_Loader_
Fri Oct 10 2003 22:39, Roman Khvatov wrote to Ilia Tarasov:

 RK> Тебе не кажется подозрительным, что Algol'о подобных языков целый
 RK> выводок, в Форт такой один?

Форт не один. Например, я уже несколько раз упоминал ДССП, есть и другие
языки, в чем-то похожие на Форт.
Во многих смыслах Лисп тоже похож на Форт, только вместо обратной польской
записи Лисп использует прямую (и, как следствие этого, кучу скобок).

Пока,       Алексей


Re: _Loader_
Hi Ilia!

В четвеpг, 09 октябpя 2003 21:56:53, Ilia Tarasov писал to Yuriy K:

 IT> Hе скажу про NASA, но слышал, как зам. главного конструктора "Энергии"
 IT> клятвенно обещал академикам, что больше никакого западного софта на
 IT> МКС не будет - только собственной российской разработки, включая ОС и
 IT> все компиляторы.

У меня возникает только один вопрос: причём здесь академики?

                                                                Sincerely,
                                                                       Vadim.

_Loader_
Fri Oct 10 2003 22:42, Vadim Rumyantsev wrote to Ilia Tarasov:

 IT>> Hе скажу про NASA, но слышал, как зам. главного конструктора "Энергии"
 IT>> клятвенно обещал академикам, что больше никакого западного софта на
 IT>> МКС не будет - только собственной российской разработки, включая ОС и
 IT>> все компиляторы.

 VR> У меня возникает только один вопрос: причём здесь академики?

Слово красивое. Внушает...

WBR, Юрий.


_Loader_
Fri Oct 10 2003 22:42, Vadim Rumyantsev wrote to Ilia Tarasov:

 IT>> Hе скажу про NASA, но слышал, как зам. главного конструктора "Энергии"
 IT>> клятвенно обещал академикам, что больше никакого западного софта на
 IT>> МКС не будет - только собственной российской разработки, включая ОС и
 IT>> все компиляторы.

 VR> У меня возникает только один вопрос: причём здесь академики?

Дело было на семинаре соответствующей секции РАН....


Re: _Loader_
Привет Ilia!

Friday October 10 2003 02:01, Ilia Tarasov wrote to Yuriy K:

 IT>>> Видишь ли, я не embedded инженер... я главный инженер ;)
 IT>
 YK>> Это достоинство или недостаток? :)
 IT>
 IT> Правильный ответ :) А Орлов с Торресом дали неправильные - полезли в
 IT> бутылку и начали размахивать своими достижениями... Срабатывает
 IT> безотказно... :)

Hикто тебе достижениями не размахивал, лично я тебе пытался сказать что
должность главного инженера - ни о чем не говорит, совершенно, как и твои
"переговоры с Интелом".

 IT> размышлений, а отчасти для того, чтобы те, кто пока не получает зарплату в
 IT> тысячах долларов и не имеет возможности покупать внутрисхемные эмуляторы,
 IT> отладчики и кросс-компиляторы,

Ты что, думаешь они из зарплаты покупаются?

 IT>  все же имели возможность обсудить более
 IT> дешевые и дающие больше стимулов для изучения самых разных сторон
 IT> программирования подходы. Иди и объясни аспиранту, который работает как
 IT> лошадь, чтобы иметь возможность заниматься наукой, что при создании
 IT> экспериментальной установки он должен использовать внутрисхемный эмулятор.
 IT> Он тебе скажет большое человеческое спасибо за ценный, но неприменимый к
 IT> российской действительности совет.

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

 IT> Кстати, насколько я вижу, ты тоже пишешь из-за границы? Если так, то мне
 IT> все понятно. Можешь и дальше получать свою зарплату, я только рад за тебя,

А я вот не за границей - получал в относительном исчислении больше.....

 IT> как и за всех, кто обеспечил себе нормальную жизнь.

А кто Юрию К. ее обеспечил?  Большевики?

    Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28
    aka snipped-for-privacy@yahoo.com
    http://www.altor.tk , http://altor.sytes.net , ftp://altor.sytes.net



Re: _Loader_
Всем привет.

Quoted text here. Click to load it
то
Quoted text here. Click to load it
параллель.
Quoted text here. Click to load it
JIT)
Quoted text here. Click to load it

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

Quoted text here. Click to load it
Java VM
данным, и
Quoted text here. Click to load it

Ну да, взяли архитектуру оптимизированную под Си и натянули на нее стековую
машину. Я бы удивился если бы результат был другой.

Quoted text here. Click to load it
лишь
Quoted text here. Click to load it
Сделать
Quoted text here. Click to load it
той
Quoted text here. Click to load it

Я могу Вам предложить более простое решение - т.к. сам форт-процессор
достаточно прост, засуньте в ресурсы этого "обычного" RISC SuperScalar
несколько маленьких форт-процессоров (возможно частичное перекрытие
ресурсов) - каждый с собственным потоком команд. Получите реальную
многозадачность и реальное быстродействие :).

             АртемКАД



Re: _Loader_
Fri Oct 03 2003 23:14, Artem Kamburov wrote to Roman Khvatov:

 AK> Hу да, взяли архитектуру оптимизированную под Си и натянули на нее
 AK> стековую машину. Я бы удивился если бы результат был другой.

"Под Си"... хммм... не знаю, есть регистровые архитектуры и есть стековые.
"Под Си", имхо, понятие несколько другого уровня.

 AK> Я могу Вам предложить более простое решение - т.к. сам форт-процессор
 AK> достаточно прост, засуньте в ресурсы этого "обычного" RISC SuperScalar
 AK> несколько маленьких форт-процессоров (возможно частичное перекрытие
 AK> ресурсов) - каждый с собственным потоком команд. Получите реальную
 AK> многозадачность и реальное быстродействие :).

В ПЛИС - уже :) Суперскаляру там делать явно нечего - не те ресурсы. А вот
форт-процессор(ы) там чувствуют себя прекрасно.


Re: _Loader_
Всем привет.

Quoted text here. Click to load it

Это я "подсмотрел" у Microchip-а :). Очень удивился когда они начали всю
линейку PIC18 под таким лозунгом толкать. А если серьезно, если процессор
чувствителен к порядку потока комманд, то без очень умного компилятора
(читай С++, Си, Делфи...) эффективно его использовать нельзя. Вот и
получается - оптимизация под Си :).

                               АртемКАД



_Loader_
Hi Roman,

Fri Oct 03 2003 20:53, Roman Khvatov wrote to All:

 RK> Кстати, по поводу современных процессоров и Форт процессоров есть одно
 RK> любопытное наблюдение:

 RK> Есть такая фирма, Sun называется, и пыталась она сделать Java процессор
 RK> (что бы байткод от Java VM был ее машинным кодом), и сделала - PicoJava
 RK> назывался. Делался он на той же технологии, что и UltraSparc II. В
 RK> результате, один и тот же Java байткод на PicoJave исполнялся в несколько
 RK> раз _медленнее_, чем тот же код на UltraSparc II на JIT'е :(

Ссылочку не дашь, где про это можно прочитать?

 RK> Разбор полетов выявил причину - UltraSparc II супер скалярный процессор,
 RK> то есть он пытается загрузить сразу несколько команд и исполнять их в
 RK> параллель. Очевидно это можно сделать только для независимых команд, в

На http://www.sun.com/processors/UltraSPARC-II/details.html я почему-то нигде
не нашел прямого указания на то, что он суперскалярный проц. Они его называют
CMT:  These chip multithreading (CMT) processors are designed to execute tens
of threads simultaneously, a sharp contrast to the single thread processed at
a time by todays typical processors.
Это концепция существенно отличается от суперскалярных VLIW пней, которые
"нахапывают" сразу много команд в одном треде, а потом "распихивают" эти
команды для параллельного исполнения в независимые блоки своего ЦПУ.

 RK> частности тех, которые не связаны по используемым регистрам. Компиляторы
 RK> (в том числе и JIT) об этом знают, и стараются расположить команды так,
 RK> что бы процессор мог загрузить максимальное количество команд.

 RK> PicoJava тоже суперскаляр, но в ней все обстоит гораздо хуже - так как
 RK> Java VM это стековая машина (как и Форт, кстати), и все операции
 RK> выполняются над верхушкой стека, то практически _все_ команды оказались
 RK> зависимы по данным, и число одновременно исполняемых команд упало
 RK> практически до 1 (то есть вся суперскалярность работать перестала).

Странно что Sun смогла наступить на такие грабли. Вроде не чайники, а подобная
проблема должна быть достаточно очевидна задолго до того, как сделали железо,
на ранних этапах проектирования.

Ты ничего не путаешь, разве PicoJava - это суперскаляр, расходующий столько же
кремния как UltraSparc II (5.4 млн транзисторов, если не ошибаюсь)? Насколько
я знаю, это сравнительно маленький проц (примерно такого же класса как ARM),
заточенный на встраиваемые применения:
http://www.sun.com/microelectronics/picoJava/overview.html
picoJava I and II are licensable cores, which can be integrated with the
application specific I/O functions to design a complete embedded processor
that is ideally suited for Internet Information Appliances such as:
-- Digital set-top boxes
-- Internet TVs
-- Internet screen phones
-- Automotive communications devices

Поэтому сравнивать его производительность с UltraSparc II, предназначенным для
WorkStations, по крайней мере странно, это примерно то же что AVR сравнивать с
пнем. Еще более странно делать какие-то выводы на основе такого сравнения.

 RK> Это не значит, что нельзя аппаратно распараллелить операции со стеком,
 RK> это лишь значит, что затраты аппаратуры на такое распараллеливание
 RK> превысят затраты аппаратуры на само ядро процессора - спрашивается,
 RK> нафига это надо? Сделать обычный RISC SuperScalar будет гораздо проще, а
 RK> производительность будет той же.

Твое утверждение, что "затраты аппаратуры на такое распараллеливание превысят
затраты аппаратуры на само ядро процессора" - совершенно безосновательно.

Есть такие чипы Нейрон, выпускаемые уже десятка полтора лет. Они являются
основой сети LonWorks фирмы Echelon. Так вот, они сделаны именно так: это
8-битный стековый процессор, который за полный цикл (6 тактов) исполняет 3
независимых команды, по 2 такта на каждую. Сделано это было именно с той же
целью, к которой сейчас стремится Sun: Нейрон исполняет 3  совершенно
независимых задачи одновременно, в каждом командном цикле исполняя по одной
команде для каждой из трех задач.

Эшелон с понтом вешает лапшу на уши, что внутри Нейрона 3 процессора, на на
самом деле процессор один, за полный цикл просто 3 раза переключаются
указатели
стеков. Поскольку стековому процессору не надо сохранять контекст, то такое
переключение не требует времени. Затраты аппаратуры на 3 набора указателей
стеков и мультиплексоры для их переключения мизерны и даже просто смехотворны
на фоне остальной аппаратуры ЦПУ. Так что не надо пургу гнать ;-)

Пока,       Алексей


Re: _Loader_
Hi Ilia!

В понедельник, 06 октябpя 2003 23:44:14, Ilia Tarasov писал to Vadim
Rumyantsev:

 IT>>> Hу вот была система, в которой входной поток интерпретатора
 IT>>> грузился прямо через COM. Соответственно, шли через него свертки
 IT>>> слов Форта из библиотеки, и не надо было придумывать какой-то
 IT>>> дополнительный протокол обмена между хостом и embedded-системой.
 VR>> При искажении в передаче данных -- конец устройству?

 IT> (Кстати, а чем контрольная сумма плоха? И прочие методы контроля за
 IT> передаваемой информацией? Эхо там, мажорирование...)

Hе ты ли двумя строчками выше писал об отсутствии дополнительного протокола?

                                                                Sincerely,
                                                                       Vadim.

_Loader_
Tue Oct 07 2003 08:03, Vadim Rumyantsev wrote to Ilia Tarasov:

 IT>>>> Hу вот была система, в которой входной поток интерпретатора
 IT>>>> грузился прямо через COM. Соответственно, шли через него свертки
 IT>>>> слов Форта из библиотеки, и не надо было придумывать какой-то
 IT>>>> дополнительный протокол обмена между хостом и embedded-системой.
 VR>>> При искажении в передаче данных -- конец устройству?

 IT>> (Кстати, а чем контрольная сумма плоха? И прочие методы контроля за
 IT>> передаваемой информацией? Эхо там, мажорирование...)

 VR> Hе ты ли двумя строчками выше писал об отсутствии дополнительного
 VR> протокола?

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


Re: _Loader_
Hello Artem.

11 Oct 03 16:55, you wrote to me:

 >>
 >> Лексический анализатор практически отсутствует (все слова режутся по
 AK> пробелам).

 AK> Ма-аленькое дополнение - по пробельным символам. А ими могут быть
 AK> весьма разные элементы - например, всем известные по Си { }

В Си {} - не пробельные символы, а элементы синтаксиса. Попробуйте в Си
написать вместо одной скобки десять - что вам компилятор скажет.

 AK> или известные по ДОСу слеши или известные по математике скобки. Если
 AK> учесть, что набор можно динамически менять, вот Вам и инструмент для
 AK> разбора почти любой строки.

Это мало отличается от простых пробелов, хоть меняй хоть не меняй.

 >> Семантический анализатор отсутствует полностью - все что набрал
 >> лексический анализатор немедленно исполняется. Hа Форте любая
 >> последовательность слов что нибудь да сгенерирует :)

 AK> Последнее совсем не понял :(.

Отсуствует контроль за семантикой. Даже в асме более строгий контроль - там
есть понятие синтаксиса.

 >> Единственные ошибки, которые могут возникнуть -
 >> отсутствие слова в словаре и исчерпание стека.
 >>
 >> Кодогенератор самый простейший - так называемая template'ная
 >> генерация. Каждая инструкция преобразуется в некоторый набор команд,
 >> который и помещается в выходной код, без какого либо учета соседних
 >> команд.

 AK> М-да. Описанное Вами и есть тот цирковой велосипед, о котором говорил
 AK> Орлов.

Hет, это и есть, то что вы дальше расписываете.

 AK> Современные Форт-системы (кстати этим современным уже лет по 10)
 AK> смахивают на описанное Вами только процентов на 5.

Hа все 100, увы :(

 AK>   Hапример: Форт-система имеет два состояния - режим исполнения и
 AK> режим компиляции.

Это состояния интерпретатора, слова всеравно читаются и исполняются
интерпретатором.

 AK>    В режиме исполнения действительно все что пришло из входного
 AK> потока, если оно есть в текущем контексте, исполняется.

Исполняет интерпретатор.

 AK>    В процессе исполнения слово имеет возможность использовать входной
 AK> поток (т.е. последующий текст после этого слова) по своему
 AK> усмотрению, что и обеспечивает семантический анализ в этом режиме (в
 AK> т.ч. и остальные сообщения об ошибках).

Это должны делать _сами_ слова. То есть для контроля его необходимо добавлять
во _все_ слова. Кроме того, есть вещи, которые вообще невозможно
проконтролировать, так как все слова (за исключением тех самых IMMEDIATE)
исполняются без всякой связи с соседними словами, то есть абсолютно
обособленно, что сразу ставит крест на любой попытке проверить семантику, так
как семантика - это именно правила связи между элементами языка.

 AK>    В режиме компиляции все, что пришло из входного потока
 AK> компилируется (если это число или обычное слово присутствующее в
 AK> текущем контексте),

Опять же это делает интерпретатор. Вместо запуска слов он складывает их адреса
в тело создаваемого слова.
В любом случае, все что было введено в Форт систему было немедленно исполненно
интерпретатором Форта, а полученная программа - побочный эффект этого
исполнения.
Компиляторы _так_ не делаются.

 AK> А по поводу того, что Алголоподобных языков много, а Форт один - так
 AK> диалектов Форта то-же много. Причем многие из них отличаются друг от
 AK> друга  как Си от Паскаля или Модулы.

Да? Hасколько мне известно, они все же очень друг на друга похожи. И кроме
того, диалекты это разновидности одного и того же языка, а производных от Форта
языков все же нет. Ведь никто не будет спорить, что С это не диалект Паскаля?

Roman


_Loader_
Sat Oct 11 2003 23:28, Roman Khvatov wrote to Artem Kamburov:

 RK> так как семантика - это именно правила связи между элементами языка.

Ты путаешь семантику с синтаксисом, или с чем-то еще.

http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=semantics&action=Search

semantics
The meaning of a string in some language, as opposed to syntax which describes
how symbols may be combined independent of their meaning.

The semantics of a programming language is a function from programs to
answers. A program is a closed term and, in practical languages, an answer is
a member of the syntactic category of values. The two main kinds are
denotational semantics and operational semantics

http://www.wikipedia.org/wiki/Semantics
In general, Semantics always refers to some kind of meaning (of something that
is written) and is thus usually opposed to syntax, which refers to the formal
way in which something is written.

Пока,       Алексей


Re: _Loader_
Всем привет.

Quoted text here. Click to load it

Форт тоже скажет. В SPF4 различают 248 ошибок - этого мало?

Quoted text here. Click to load it

Выделяешь конструкцию разделенную пробелами, в ней конструкцию разделенную ....
и т.д. Вот тебе и разбор формул, и разбор командной строки и разбор много еще
чего.

Quoted text here. Click to load it


Угу, и компиляция тоже? И после компиляции тоже?  Или Вы о адресном
интерпретаторе, так это вообще структура кода и к Форту имеет не самое прямое
отношение.

Quoted text here. Click to load it

: INTERPRET_ ( -> ) \ интерпретировать входной поток
  BEGIN
    NextWord DUP     \ тут выделяем слово
  WHILE
    SFIND ?DUP        \ тут его находим
    IF
         STATE @ =       \ здесь проверка компилировать/исполнить
         IF COMPILE, ELSE EXECUTE THEN
    ELSE
         S" NOTFOUND" SFIND
         IF EXECUTE      \ здесь разбор конструкций
         ELSE 2DROP ?SLITERAL THEN   \ здесь работа с числами
    THEN
    ?STACK
  REPEAT 2DROP
;

Это вот это Вы называете интерпретатором? Как видите исполняет не интерпретатор,
а EXECUTE :). И компилирует не интерпретатор, а COMPILE, :).

Quoted text here. Click to load it

Нет, только в слова обеспечивающие семантику (IF THEN REPEAT BEGIN). Эти слова
изначально предоставлены Фортом и можете их считать частью интерпретатора :).
 Кстати, если бы Си открыло свои процедуры обеспечивающие семантический анализ,
Вы бы не перестали их считать частью компилятора Си :).

Quoted text here. Click to load it

Например?

Quoted text here. Click to load it

  Попробуйте в примере слово WHILE поместить на две стоки ниже (после IF) и
посмотрите как Форт начнет ругаться. Попробуйте пропустить THEN или не закончить
цикл. Так где здесь нет связи с соседними словами? В Форте есть конструкция
CODE имя ..... END-CODE
 Вместо многоточия почти обычный асм-текст только синтаксис более жесткий.
Попробуйте использовать асм в стандартной конструкции определения Форт-слова - у
Вас просто не выйдет (сообщение типа "слово не найдено в словаре") - чем это не
семантический анализ?
 Да, в Форте нет одной процедуры выполняющей семантический анализ текста. В
Форте этим занимаются множество слов которые в конечном итоге полностью
выполняют эту задачу не хуже любого другого компилятора. Мало того, Форт
позволяет использовать эти средства в конечной программе (в Си Вам для создания
этого блока необходимо написать его с нуля).

Quoted text here. Click to load it

Я думаю что таким способом нельзя создать ни одной управляющей конструкции (те
же IF THEN REPEAT BEGIN CASE \ ( { ." S" .... никак НЕ компилируются). Опять
повторяю, компилирует (складывает адрес) слово COMPILE, и оно встречается далеко
не только в интерпретаторе. Многие управляющие конструкции имеют его или его
аналог. И это предоставлено Форт-системой изначально. Т.е. по сути это часть
компилятора, но предоставленная Вам в пользование.

Quoted text here. Click to load it

Звучит так же как - все, что введено в программу стало побочным эффектом
исполнения компилятора Си :).

Quoted text here. Click to load it
Форта
Quoted text here. Click to load it

 Можно поспорить, что оба диалекты Алгола :). Основные их отличия - синтаксис и
порядок передачи (очистки) параметров на стеке, причем последнее для
программиста прозрачно.  Возьмите тот-же nnCron(планировщик) или Eserv(Web
сервер) оба производные от SPF и предоставляют все его средства (торчат "уши
Форта" :) ) но тем не менее каждый из них стал самостоятельным продуктом со
своим синтаксисом и задачами.

                                 АртемКАД



Re: _Loader_
4-Oct-03 03:37 Alex Kouznetsov wrote to Roman Khvatov:

AK> Есть такие чипы Нейрон, выпускаемые уже десятка полтора лет. Они являются
AK> основой сети LonWorks фирмы Echelon. Так вот, они сделаны именно так:
AK> это
AK> 8-битный стековый процессор, который за полный цикл (6 тактов) исполняет
AK> 3 независимых команды, по 2 такта на каждую.
[...]

AK> Эшелон с понтом вешает лапшу на уши, что внутри Нейрона 3 процессора, на
 Угу, причём старательно обходит вопрос о том, как же они
в общую память лазят :-)

AK> на самом деле процессор один, за полный цикл просто 3 раза переключаются
AK> указатели
AK> стеков. Поскольку стековому процессору не надо сохранять контекст, то
AK> такое

И пишут прикладной софт под этот процессор на языке Нейрон-C,
в "обычный" C включены необходимые расширения, в том числе
оформление реакции "прикладного" "процессора" на события в "системных" ....


wbr,
--
/* Oleksandr Redchuk, Brovary, Ukraine */
/* real '\x40' real '\x2E' kiev '\x2E' ua     */


Site Timeline