_Loader_ - Page 13

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

Translate This Thread From Russian to

Threaded View
_Loader_
Sat Oct 04 2003 16:37, Roman Khvatov wrote to Artem Kamburov:

 RK> Тогда поделись сокровенным знанием - какая архитектура оптимизированна
 RK> для стековой машины? (И желательно, что бы она была не менее
 RK> производительна, чем суперскаляр, иначе это неинтересно - горбатых
 RK> архитектур и так хватает :)

Суперскаляр, кстати, не самая эффективная архитектура на сегодняшний день. И
регистровый либо стековый подход к понятию "суперскаляр" несколько
ортогональны. Стековый процессор тоже может быть суперскаляром.

 RK> Это всеобщее заблуждение - он сложнее RISC'а, той же производительности.
 RK> RISC выполняет элементарные операции над регистровым файлом, Форт
 RK> процессор - над стеком (точнее двумя стеками). То есть Форт процессору,
 RK> вдобавок к регистровому файлу (который у него будет занят под стек),
 RK> нужно еще 2 указателя стека, блоки для работы с ними, плюс модификация
 RK> всех операций с прямоадресуемых (в регистровый файл) на косвенно
 RK> адресуемые (через указатели стеков). То есть вместо того, что бы прочесть
 RK> 2 регистра, выполнить операцию и записать результат в 3й регистр, Форт
 RK> процессор будет вынужден выполнить чтение указателя стека, чтение
 RK> регистрового файла по полученному адресу, инкремент адреса, чтение 2го
 RK> операнда по полученному адресу, собственно операцию, запись по косвенному
 RK> адресу и декремент указателя стека. Так что, по сравнению с RISC
 RK> процессором, Форт процессор делает много лишнего, а RISC процессор не
 RK> делает ничего, чего бы не делал Форт процессор. Плюс ко всему этому Форт
 RK> процессору понадобится поддержка со стороны ОС, для откачки его стеков в
 RK> память.

www.kc.ru/~tile Там описание стекового процессора в ПЛИС. Форт-процессора,
если угодно. Что интересно, все операции, которые ты перечислил, почему-то
делаются за 1 такт... :)

 RK> Оговорюсь, что тут сравниваются обычный RISC (не супер скаляр) и обычный
 RK> Форт (за бессмысленностью супер скалярного Форт процессора)

Да, такая навороченная архитектура для стековой машины действительно
бессмысленна. Это для набора регистров надо конвейеризовать, переупорядочивать
и следить за зависимостями. Для стека все сводится к последовательному
выполнению элементарных операций, вплоть до 1 операции за такт (и обращаю
внимание, что больше нельзя в принципе; а если будет разговор про
одновременную пересылку в 2 регистра, то давайте тогда уж поставим и 2 стека?)

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

 RK> Hи того ни другого не получите :(

Два процессора на той же площади кристалла - это не две задачи?

 RK> В реальной системе обычно одновременно исполняется одно приложение,
 RK> остальные ждут какого либо ввода/вывода. Имеет смысл ориентироваться
 RK> только на multithreaded приложения - они реально могут использовать
 RK> несколько процессоров одновременно. Hо для этого приложение должно быть
 RK> так написано, компиляторы делать из обычных программ multithreaded не
 RK> умеют (за редким исключением, Форт к таковым не относится :) Кроме того,
 RK> вместо "обычного" RISC SuperScalar уже засовывают много маленьких RISC
 RK> процессоров - VLIW называется, что гораздо эффективнее 'многих маленьких
 RK> Форт процессоров'

А еще есть TTA (H.Corporaal серию работ написал), которая представляет собой
дальнейшее развитие VLIW в сторону контроля над микрокодом (фактически, в TTA
микрокода уже просто нет). А про стековую разновидность TTA можно почитать у
меня на страничке... :)


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

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
процессоров
Quoted text here. Click to load it

Форт относится к языкам штатно поддерживающим нитевую многозадачность.  Т.е. он
позволяет писать приложения которые будут "так написаны".

Quoted text here. Click to load it

Хм...  А Вы с чем сравнивали?

                         АртемКАД





Re: _Loader_
4-Oct-03 15:37 Roman Khvatov wrote to Artem Kamburov:

RK> Кроме того, вместо "обычного" RISC SuperScalar уже засовывают много
RK> маленьких
RK> RISC процессоров - VLIW называется, что гораздо эффективнее 'многих
 Это немного не то. В одном VLI word натолкано несколько независимых
команд из одного потока команд. Он их быстренько выполняет, при
необходимости ОС переключает потоки, сохраняя контекст задачи.
При ветвлении конвейер малость нарушается (если нет branch delay
slot). Затолкать в одно длинное слово команды из разных потоков
невозможно (и не нужно).

 В случае "многопоточного" стекового процессора имеет смысл сделать
его на столько потоков, сколько ступеней в конвейере и выполнять
команды "по кругу" из каждого потока. Естественно, синхронно
с ними переключать указатели стеков, которых должно быть столько же.
При этом на разных стадиях конвейера находятся команды из разных
потоков. Разрушения конвейера нет в принципе. Производительность
ядра делится поровну между потоками, которые в настоящий момент
выполняются, без расходов на переключение. Но если потоков меньше,
чем таких "виртуальных процессоров", то часть производительнсоти
теряется впустую. Впрочем, современным ОС такое малое число
потоков не грозит, а embedded приложение можно сразу писать в рассчёте
на то, что есть возможность задурачить несколько потоков (что и сделано
в том Нейроне, бегает три задачи - системная, коммуникационная и
пользовательская). Если потоков больше, то расходов на переключение
не избежать, и если процессор "быстрый" (т.е. такой, для которого
уже встают вопросы кеш-памяти), то расходы на переключение будут где-то
те же, что и для процессоров с кучей РОН (так как из соображений
производительности у каждого потока верхушки стеков должны быть
выполнены на кристалле и перезагружаться при переключении задач).

 Если я правильно понял, то в этом новом гипертрединговом PIV
что-то отдалённо напоминающее и сделали.

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


Re: _Loader_
Hello, Alex Kouznetsov !

 >  ER> Эти "call" - команды пpоцеccоpа или виpтyальной фоpт-машины? Еcли
 >  ER> пpоцеccоpа, то мы имеем дело c компилиpованной в нативный код
 > пpогpаммой.
 >  ER> Далее идет пpоcто cpавнение качеcтва компилятоpов.

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

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


 > "интерпретатор" - это сам процессор, с его call и ret, а вся Форт-система
 > может быть представлена как определенным образом организованный
 > набор подпрограмм. Тем не менее, Форт традиционно считается
 > интерпретируемым языком.

Да мало ли что чем считается. Почти всегда одно и тоже можно и интерпретатором
и компилятором сделать. Hельзя, если интерпретируемая программа может сама свой
текст менять (или не сама). Hо тогда любая прекомпиляция, даже такая, как в
большинстве бейсиков уже не интерпретация.

 > Изначально ведь речь шла о том, насколько быстрым может быть
 > интерпретатор. Я
 > привел пример - практически он может быть сколь угодно быстрым.

И все равно не быстрее нативного кода, что по-моему совершенно очевидно.

С уважением, Дима Орлов.


Re: _Loader_
Hello, Artem Kamburov !

 >>  >>> Встречались сообщения, что вполне может переплюнуть,
 >>
 >>  >  DO> Это абсурд.

 > Хмм.... Судя по опыту работы с программами написанными явно не на
 > Форте утверждение в абсурдности очень сомнительно. С некоторых пор,

Hа форте процессор может обогнать сам себя?

 >>  Hо говорить, что что-то работает быстрее, чем нативный код -
 >> просто абсурд. В любом случае процессор исполняет нативный код, другому он
 >> просто не обучен. А вот если кто-то на форте пишет код, который работает
 >> быстрее чем им же написанный на ассемблере, я могу лишь констатировать
 > полный съезд крыши у этого программиста ...

 >  Для однокристалок это верно (если это не Форт-процессор), а для

Это верно даже если это форт-процессор для любого процессора.

 > современных
 > х86 (с конвейером, кешами, оперативкой и виртуальной памятью) не
 > обязательно. Связано это с тем, что в х86-х системах процессор

Обязательно.

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

Если он быстрее (во что я не верю), то асм в руки - и пиши себе шитый код. Хотя
если алгоритм (критичный цикл) влазит в кэш в виде шитого кода, то без лишних
call/ret он и подавно влезет.

С уважением, Дима Орлов.


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

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

Нет. Если на Форт-процессоре начнешь писать на асме (которого, кстати
производитель не дает) в стиле PIC, AVR или x86-го, у тебя очень много кода
уйдет на борьбу с "сегментированной" памятью, "дурацкой" архитектурой и
"недостатком" регистров. В конечном итоге тебе придется либо брать другой
проц, либо менять себя (читай - переходить на Форт).

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

Вы не совсем понимаете, что есть Форт.
 Форт состоит как минимум из:
1) набора примитивов (написанных тем самым асмом) с единым стандартом
передачи параметров (через стек)
2) шитого кода, который описывает в конечном счете в какой
последовательности эти примитивы выполняются

Кроме того, там еще есть словарь (база данных по которой примитивы и не
только можно найти в памяти) и VFM - примитив который исполняет шитый код
(время его выполнения от единиц до десятков (обычно 5-15) тактов процессора)

Вид шитого кода может быть разным (байт-код как в Жабе, 2-4 байтный
косвенный (все элементы - адреса), подпрограммный (все элементы - call-ы),
свернутый (все элементы - некие числа связанные с адресами)...), но суть в
том, что вызываемая процедура больше элемента шитого кода.

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

 А что делают современные компиляторы - они инлайнят процедуры все эти сотни
раз (зачем им лишние call/ret). Т.е. на сотню вызовов сотня загрузок !!! А
после пытаются оптимизировать (почти всегда еще увеличить) этот громадный
код. Результат по моему мы все очень хорошо знаем :-(.

С асмом ситуация похожая. На проектах до десятков Кб асм может выигрывать по
скорости, а далее полный облом.

               АртемКАД




Re: _Loader_
Thu Oct 02 2003 23:21, Artem Kamburov wrote to Dima Orlov:

 >> Hа форте процессор может обогнать сам себя?

 AK> А что, сейчас процессоры медленнее памяти? Или о виртуальной памяти уже
 AK> все забыли?

Это неважно.


 AK> Хмм... А Форт это и есть асм (доказать обратное очень сложно).

Для х86?? Ой...

 >>  Хотя если алгоритм (критичный цикл) влазит в кэш в виде шитого кода, то
 >> без лишних call/ret он и подавно влезет.

 AK>  Форт состоит как минимум из:
 AK> 1) набора примитивов (написанных тем самым асмом) с единым стандартом
 AK> передачи параметров (через стек)
 AK> 2) шитого кода, который описывает в конечном счете в какой
 AK> последовательности эти примитивы выполняются

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

Чем это отличается от подпрограмм на ассемблере или функций С?
Тем, что в кеш кроме функций еще надо загружать собственно интепретатор.
Как это может увеличить скорость, интересно?

 AK>  А что делают современные компиляторы - они инлайнят процедуры все эти
 AK> сотни раз (зачем им лишние call/ret). Т.е. на сотню вызовов сотня
 AK> загрузок !!!

Ты не совсем понимаешь как работают компиляторы.


 AK> А после пытаются оптимизировать (почти всегда еще увеличить)
 AK> этот громадный код.

Hет.


 AK> Результат по моему мы все очень хорошо знаем :-(.

Замечательный результат. Меня вполне устраивающий.
В чем _конкретно_ заключается ":-("?


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

Hет. Впрочем пошло уже по второму кругу...

WBR, Юрий.


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

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
эти
Quoted text here. Click to load it

А по-точнее можно - что я упустил?

Quoted text here. Click to load it

Каждый год апгрейт железа без реального увеличения производительности
(просто на старом все становится ну очень медленным).

                            АртемКАД



Re: _Loader_
Sat Oct 04 2003 00:15, Artem Kamburov wrote to Yuriy K:

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

 AK> Глубиной вложения и частотой использования.

В какую сторону?

 AK> А Си со своими функциями
 AK> вообще поступает как ему нравится (чаще инлайнит в место вызова).

Hет. Ознакомься все же с поведением компиляторов С. Кстати, о каком именно
компиляторе С и для какого процессора ты рассказываешь?

 >> Тем, что в кеш кроме функций еще надо загружать собственно интепретатор.
 >> Как это может увеличить скорость, интересно?

 AK> Интерпритатор то же загружается только один раз - при первом вызове :).

И занимает при этом большую часть кеша. Или вообще в него не влазит. И?

 >>  AK>  А что делают современные компиляторы - они инлайнят процедуры все
 AK> эти сотни раз (зачем им лишние call/ret). Т.е. на сотню вызовов сотня
 >>  AK> загрузок !!!
 >>
 >> Ты не совсем понимаешь как работают компиляторы.

 AK> А по-точнее можно - что я упустил?

Ты делаешь совершенно неправильные утверждения.

 >> Замечательный результат. Меня вполне устраивающий.
 >> В чем _конкретно_ заключается ":-("?

 AK> Каждый год апгрейт железа без реального увеличения производительности
 AK> (просто на старом все становится ну очень медленным).

Так бы сразу и говорил. Дальше можно не спорить, неинтересно...



"People who think they know everything really irritate those of us who do"

WBR, Юрий.


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

Quoted text here. Click to load it

MS C/C++ 7.00 для х86.

Quoted text here. Click to load it

Типовой объем - меньше 100 байт.(обычно меньше 32). Время выполнения - 4-20
тактов процессора.

                       АртемКАД





Re: _Loader_
Привет тебе, Oleksandr!

 OR>  Форт с оптимизацией "разворачивает" слова в машкод.
 OR> Пользуясь С-шной терминологией, "инлайнит" все функции и дальше
 OR> оптимизирует машкод.

Угy. Только это yже cкоpее компилятоp полyчаетcя, pаз на выходе нативщина
cплошная.

 OR>  Hо тут два момента:

[...]

 OR> Hу и в любом случае - какой бы оптимизирующий форт мы не
 OR> взяли, если форт-программу ему на вход писал плохой фортер, то он
 OR> (опт.форт) её не вытянет. А все мы знаем, что при большом желании
 OR> сравнить тайд с "другим порошком" можно так, что станет странно,
 OR> почему производители "другого порошка" ещё не повесились.

Во-во. Или еcли алгоpитм выбpан бyдет неyдачный.
Кcтати, на этy темy: "да мой интеpпpетатоp pвет аccемблеp по cкоpоcти" за
поcледний год yже доводилоcь cпоpить. В оффлайне. И как ни cтpанно - c фоpтеpом
же. Похоже, очеpедная "cвященная война" гpядет.

С yважением, Eвгений.
             ewg::cats-online.ru

... котят по осени считают

_Loader_
Hi Eugene,

Thu Oct 02 2003 10:02, Eugene Romanov wrote to Oleksandr Redchuk:

 ER> Только это yже cкоpее компилятоp полyчаетcя, pаз на выходе нативщина
 ER> cплошная.

Для информациии: в состав Форта обычно входят два интерпретатора ("наружный" и
"внутренний") и компилятор. В большинстве современных интерпретирующих систем
исходник сначала компилируется. Интерпретируется же байт-код, т.е.
скомпилированный код.
Форт в этом смысле не исключение, просто у него все в одном флаконе, и
компилятор, и интерпретатор(ы). Кстати, его компилятор исполняется, ессно,
путем интерпретации ;-)

 OR>> Hу и в любом случае - какой бы оптимизирующий форт мы не
 OR>> взяли, если форт-программу ему на вход писал плохой фортер, то он
 OR>> (опт.форт) её не вытянет. А все мы знаем, что при большом желании
 OR>> сравнить тайд с "другим порошком" можно так, что станет странно,
 OR>> почему производители "другого порошка" ещё не повесились.

 ER> Во-во. Или еcли алгоpитм выбpан бyдет неyдачный.
 ER> Кcтати, на этy темy: "да мой интеpпpетатоp pвет аccемблеp по cкоpоcти" за
 ER> поcледний год yже доводилоcь cпоpить. В оффлайне. И как ни cтpанно - c
 ER> фоpтеpом же. Похоже, очеpедная "cвященная война" гpядет.

Хм... Тогда начнем, пожалуй ;-)
Значит, то что проги, скомпилированные O'Caml или VC7, оказались быстрее
ассемблерной - никого не удивило? Это показалось правдоподобным? А то что Форт
"втиснулся" между - все сразу заворчали, что этого не может быть, поскольку
"быстрей ассемблера не напишешь"? Смешная логика...

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


Re: _Loader_
Hello, Ilia Tarasov !

 >  DO> Hичего, кроме собственно фортов и нескольких мелких программок
 > (какой-то
 >  DO> вьювер к interrupt list by Ralf Brown) мне не попадалось, да и те еще
 > во
 >  DO> времена 286 машин. Hе сомневаюсь, что отдельные фанаты что-то пишут, но
 >  DO> дальше это по большей части распространения не получает.

 > Мне попадалось: Eserv (сервер, собственно...), nnCron (планировщик
 > для win), еще была некая САПР, уже не помню, чья. Это из более-менее
 > распространенного, причем только то, что само попалось на глаза в инете.

Как я и говорю, единичные вещи.

 > Там, где я работаю,
 > что-то около 30 проектов на Форте для разнообразных расчетов и
 > управления установками с помощью PC, а в эхотажных разработках _ничего_,
 > кроме Форта, и нет...

Мои соболезнования.

 >  DO> Да и не знать не особо вредно.

 > Hе особо, пока не припечет и грамотный фортер не решит его задачу
 > комплексным подходом, переписав и системное и прикладное ПО.

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

 >  DO> Речь-то шла о marc4 от Атмела, именно для него в качестве средства
 >  DO> программирования Атмел предлагает один из фортовских диалектов.

 > Hе слышал, интересно...

Hе особо, честно говоря.

 >>> (Я даже не касаюсь вопроса поддержки софт-ядер на Си и вообще ЯВУ.
 >>> По оперативности внесения изменений в системный софт Форт вне
 >>> конкуренции)

 >  DO> И по невозможности потом во всем этом разобраться, особенно не автору
 >  DO> этой системы.

 > При нормальном, нефанатском, стиле кодирования Форт читается не
 > хуже других языков.

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

 >>> btw, встроенный в интерпретатор командной строки. Что касается

 >  DO> Да какая командная строка в четырехразрядном embedded процессоре?

 > Я немножко не понял, о чем речь, имел в виду усредненную
 > Форт-систему, где интерпретатор как правило есть.

Что ему вообще в embedded системе делать?

 >>> собственно
 >>> компиляции, то получить код, ПОЛHОСТЬЮ идентичный ассемблерному,

 >  DO> Что такое ассемблерный код?

 > Код, компилируемый ассемблером, надо полагать. :) Однозначное
 > соответствие
 > между мнемонической записью ассемблерных команд и двоичным кодом,

Кстати ассемблер не обязательно дает эту однозначность.

 > располагающимся в памяти программ. Речь об оверхеде, который не делает
 > ассемблер? Компилятор Форта можно скорректировать так, что он тоже
 > не будет его делать.

Кого не будет делать? То, что на форте можно написать ассемблер я в курсе,
вопрос только на кой это надо.

 >>> на Форте довольно просто.

 >  DO> Еще проще ассемблерный код писать на ассемблере.

 > Скажи пожалуйста, как проще:

 > mov bx, offset myvar
 > mov ax, word ptr [bx]
 > mov bx, offset another_var
 > mov cx, word ptr [bx]
 > add ax, cx

 > или

 > get_myvar get_another_var +

Однозначно первый вариант (разумеется учитывая бессмысленную избыточность):

mov ax, myvar
add ax, another_var

Тут понятно что делает программа, в отличие от совершенно бессмысленной строки

get_myvar get_another_var +

Заодно понятно почему программа на форте оказывается сравнимой с ассемблерной.

 >  DO> PS Hо даже если бы все сказки о невероятной эффективности форта были
 >  DO> правдой, я бы все равно выжигал его каленым железом за абсолютную
 >  DO> нечитабельность текстов на нем нормальным человеком. Если о С не без
 >  DO> основания говорят как о write only языке, то к форту это применимо
 >  DO> тысячекратно.

 > А осмысленного русского текста на Форте тебе ни разу не попадалось?

Hет, а зачам писать русский текст на форте?

 > Смотря как писать... можно на чем угодно намазюкать абсолютно нечитаемую и
 > несопровождаемую программу.

Можно, а вот на форте читаемую - врядли. Мне не попадалось.

 > Форт, по крайней мере, не запрещает использовать
 > русские символы, не запрещает обустраивать синтаксис по полной
 > программе и т.п.

Вот именно. Язык, который ничего не запрещает провоцирует писать так, что кроме
автора это никто и никогда не поймет.

 > Вот тебе примерчик, скрипт на Форте. ЭТО нечитаемо????
 > ====================================================
 > ПЛОСКОСТЬ Базовая
 > ПРЯМАЯ Прямая1
 > ПРЯМАЯ Прямая2

 > УГОЛ МЕЖДУ Прямая1 И Прямая2 БАЗА Базовая
 > HОМИHАЛЬHО 18
 > +ДОПУСК 0.1
 > -ДОПУСК -0.1
 > ====================================================

Читаемо, но что делается непонятно совершенно. От того, что оно записано
кирилицей понятней не становится. Hаписана какая-то абракадабра на вроде

 - Петька, прибор!
 - 78!
 - Что 78?

С уважением, Дима Орлов.


_Loader_
What do you think about sharp blades, Dima?

[Answer on] [Dima Orlov wrote to Ilia Tarasov at [04 Oct 03 19:40]]:

 DO> mov ax, myvar
 DO> add ax, another_var
  Таак, ты перемещаешь содержимое памяти по адресу ax в память по адресу
my_var, потом добавляешь содержимое памяти по адресу ax к содержимому
another_var и помещаешь в another_var.
  А что, у тебя не AT&T-синтаксис!?

 DO> Тут понятно что делает программа, в отличие от совершенно
 DO> бессмысленной строки
 DO> get_myvar get_another_var +
  А вот тут -- все понятно как только произнесены слова (ОДИH РАЗ!) "О.П.H."

    Remember, pain is part of pleasure, Dima.
... Ждет, когда небо вспомнит о нем и выйдет на связь...

_Loader_
Hello, Lev Serebryakov !

 >  DO> mov ax, myvar
 >  DO> add ax, another_var

 >   Таак, ты перемещаешь содержимое памяти по адресу ax в память по
 > адресу my_var, потом добавляешь содержимое памяти по адресу ax к
 > содержимому another_var и помещаешь в another_var.

Смешно.

 >   А что, у тебя не AT&T-синтаксис!?

Hет, у меня интеловский (авторский) синтаксис. Очевидно человек, читающий
ассемблерную программу знает его.

 >  DO> Тут понятно что делает программа, в отличие от совершенно
 >  DO> бессмысленной строки

 >  DO> get_myvar get_another_var +

 >   А вот тут -- все понятно как только произнесены слова (ОДИH РАЗ!) "О.П.H."

Hичего непонятно. Hепонятно даже переменные это, функции или что вообще за
объекты такие. По имени вроде функции, по сравнению с предыдущим кодом на асме
- хрен знает. А за обратную польскую нотацию руки надо отрывать.


С уважением, Дима Орлов.


Re: _Loader_
Hello, Artem Kamburov !

 >> Скриптовых языков пруд пруди. Причем с гораздо более внятным чем у форта
 >> синтаксисом и семантикой.

 > А причем здесь скриптовые языки (кстати, как там у них с

При том, что если задача стоит так, как стоит, во внешнее ПЗУ нужно грузить
именно скрипт, причем ориентированный на решаемую задачу, который и будет
исполнять контроллер. Форт позволяет такое создать, но предлагать человеку на
нем что-то писать негуманно.

 > поддержкой МК?) и тем

В MC пишется интерпретатор этого скрипта (точнее байт-кода), в PC - компилятор
скрипта в байт-код. И то и другое - достаточно тривиальные вещи.

 > более их синтаксис и семантика? Задача то конкретнее -

Синтаксис и семантика должны быть дружественны человеку, а не враждебны, как
среда форт-системы с ее извращенной логикой.

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

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

 >> Есть и тулзы типа yacc, bison, etc для генерации
 >> подобных программ.

 >  А подробнее можно?
 > А то у меня есть тоже много тулз с заковыристыми названиями, да
 > вот беда, их мало кто знает ;).

Эти как раз широко известны, в инете ты легко их найдешь.

С уважением, Дима Орлов.


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

Quoted text here. Click to load it

Угу, оно и заметно ;).

Quoted text here. Click to load it

Правильно, и все кто пишит на Форте имеют извращенную логику.... :-\.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

 Нашел Bison-1.35-4 на gnuwin32.sourceforge.net , запустил и полюбовался
надписью "Необходимый файл динамической библиотеки LIBINTL-2.dll не найден" -
весьма  серьезная тулза ;), или за этот (и еще несколько) файл надо платить?
Кстати, если sourceforge.net  это широкая известность, то там-же можете найти и
с десяток Форт-проектов.

                            АртемКАД




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

Quoted text here. Click to load it

М-да... Уже нашел.

                          АртемКАД



Re: _Loader_
Thu Oct 09 2003 00:19, Artem Kamburov wrote to Dima Orlov:

 >> Синтаксис и семантика должны быть дружественны человеку, а не враждебны,
 >> как  среда форт-системы с ее извращенной логикой.

 AK> Правильно, и все кто пишит на Форте имеют извращенную логику.... :-\.

Интересно бы посчитать корреляцию между писателями на Форте и говорящими
виндовс - суксь и маздай. :-))) Как мне кажется она будет заметна...

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

 AK>  Осталось только функциональность обеспечить, а то труп - тоже устойчивое
 AK> состояние.

Кстати, стандартный подход для PLC. И никаких проблем с функциональностью
в пределах требуемого.

 AK>  Ксати, NASA активно использует Форт в спутниках, и там одна из задач -
 AK> дистанционная загрузка кода.

То-то я все не мог понять, почему у них столько проблем с софтом...

WBR, Юрий.


_Loader_
Привет Yuriy!

Thursday October 09 2003 05:56, Yuriy K wrote to Artem Kamburov:

 >>> Синтаксис и семантика должны быть дружественны человеку, а не
 >>> враждебны, как  среда форт-системы с ее извращенной логикой.
 YK>
 AK>> Правильно, и все кто пишит на Форте имеют извращенную логику.... :-\.
 YK>
 YK> Интересно бы посчитать корреляцию между писателями на Форте и говорящими
 YK> виндовс - суксь и маздай. :-))) Как мне кажется она будет заметна...

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

    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



Site Timeline