_Loader_

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

Translate This Thread From Russian to

Threaded View
Было дело,Alex Kouznetsov писал в эхе "RU.EMBEDDED"письмо для Power User, тема
была "_Loader_"а было это:25-Sep-2003, 15:28:14

[...]
AK>>>> Читай внимательнее, и не говори что это "тривиальнейшая задача" ;-)
YK>>> А, да, действительно, питание придется передергивать, убедил.

PU>> Это не так.При входе в бутлоадер по "RESET+проверка условия входа"
PU>> придется максимум дернуть ресетом[...](если у камня есть NMI то
PU>> можно альтернативно юзать его вместо reset'а).
AK> Я не делаю разницы между ресетом, NMI и сбросом по питанию.
Дело хозяйское.Но reset\NMI часто дернуть проще питания...

AK> Общее у них то, что проц сбрасывается внешним воздействием. В контексте
AK> разница между ними слишком незначительна, чтобы тратить время на описание
AK> деталей.
Дык апдейт фирмвары проца вообще тоже делается внешним воздействием.
Или откуда проц берет новую фирмвару?Сам ее и генерит чтоли? Ж8-))
Это ж вроде не вырусс-полиморфик, чтобы самому мутировать? :\
А раз так,не вижу криминала в использовании факта того что
апдейт сам по себе - тоже внешнее воздействие.

AK> [...]
PU>> Если же защищаться от именно такой (довольно маловероятной,
PU>> т.к.зачем мы будем сами себе гадить?) бяки,а ресетом рулить
PU>> через интерфейс через который идет апдейт не судьба[...]
PU>> - Внешний вачдог может сбрасываться по активности интерфейса
[...]
PU>> зато всегда можно загнать девайс в нужное нам состояние и
PU>>  перешить его).
AK> В принципе при помощи внешней аппаратуры проблему можно как-то решить.
Да.Поэтому не все так мрачно как может показаться.Под конкрентую
ситуацию обычно вполне можно найти съедобное решение.

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

AK> Интерпретатор решает эту задачу проще,
ИМХО - это из области "хум хау".Кроме того,делать дуракоустойчивым
придется и интерпретатор и апдейт его "апплета".Иначе см.выше,верно
то же что и для бутеров,т.к.случайно\неслучайно залитый "левый" апплет
может и не повесит девайс насовсем,но девайс который вытворяет х.з.что
энное время(пока это не обнаружат и не перешьют)тоже врядли кого-то
обрадует(спятивший или хакнутый выключатель-это весело...).Так что
насчет простоты хез.Btw,у той же java как я помню проблемы
с безопасностью вроде были.

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

AK> и дешевле.
Это если запас по скорости есть,etc.Иначе - более мощный проц ессно и
более дорогой при прочих равных :)

[...]
YK>>> Для _такой_ задачи интерпретатор даже может быть полезным.
PU>> Если скорость пофигу - возможно что да.
AK> Скорость зависит от того как сделан интерпретатор.
Но она никогда не переплюнет скорость работы native кода?! Ж8-)
В случае "бутера" - main firmware написано в native кодах проца,так
что скорость его работы - соответствующая(особенно если асмовыми
вставками и т.п. в узких местах не пренебрегать).В случае интерпретатора
оно будет медленнее.При том имхо как минимум весьма ощутимо чем native
код.

AK> Hапример, если ставить Жабу - да, будет медленно. Если же ставить FVM - то
AK> бабушка надвое сказала.
Как-надвое?Быстрее Java-пожалуй,да:).Медленнее native кода проца?
Разумеется.Интерпретатор же тоже должен когда-то выполняться,
кроме собственно,задуманных нами действий.Допускаю что можно
навернуть что-то типа предварительной компиляции в native код
проца,etc,а уже его потом резво выполнять,но просто это уже
не будет,быстрее-тоже имхо врядли(особенно на старте).

YK>>> Hо с другой стороны закладываться на _необходимость_ частого
YK>>> дистанционного апгрейда софта выключателя питания... Как-то
YK>>> неаккуратно.
AK> Это зависит от задачи.
Дык... но вход в режим апдейта без физических действий с девайсом
требует весьма продуманного алгоритма апдейта вообще.Необходимость
скажем,дернуть ресет девайса в нужное время-это и некоторая защита
от дурака(случайно подобрать момент сложновато) и некоторое
ограничение возможностей хакеров.Можно и без этого,но сложнее.

Good Bye, Alex.See you later.
... Фидолук-штука хорошая.А Fidolook SL стал еще лучше:)



Re: _Loader_
Hello, Alex Kouznetsov !

 >  YK>>>> Для _такой_ задачи интерпретатор даже может быть полезным.
 >  PU>>> Если скорость пофигу - возможно что да.
 >  AK>> Скорость зависит от того как сделан интерпретатор.

 >  PU> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)

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

Это абсурд.

 > http://talk.mail.ru/article-26762867.html Чтобы было понятнее,
 > SPF4 - это Форт с оптимизацией.

Да мало ли кто и что на форумах пишет? Процессор выполняет нативный код,
выбирает из памяти команд команду и выполняет ее. От того что вокруг этого
процесса ты навернешь интерпретатор, быстрее команды выполняться не будут. Это,
повторяю, абсурд. Кроме того, сам форт крайне неудобный инструмент просто как
язык, хотя это конечно дело вкуса.

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


_Loader_
Tue Sep 30 2003 15:43, Dima Orlov wrote to Alex Kouznetsov:

 >>  YK>>>> Для _такой_ задачи интерпретатор даже может быть полезным.
 >>  PU>>> Если скорость пофигу - возможно что да.
 >>  AK>> Скорость зависит от того как сделан интерпретатор.

 >>  PU> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)

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

 DO> Это абсурд.

Hу почему же. Обычно можно подобрать пример, чтобы компилятор [А] был быстрее
компилятора [Б].
Особенно если для компилятора [А] написать библиотеку именно под этот пример.
:-)

Практическая польза от таких сравнений - это уже совсем другой вопрос...

WBR, Юрий.


_Loader_
Hello, Yuriy K !

 >>>  YK>>>> Для _такой_ задачи интерпретатор даже может быть полезным.
 >>>  PU>>> Если скорость пофигу - возможно что да.
 >>>  AK>> Скорость зависит от того как сделан интерпретатор.

 >>>  PU> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)

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

 >  DO> Это абсурд.

 > Hу почему же. Обычно можно подобрать пример, чтобы компилятор [А]
 > был быстрее компилятора [Б].

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


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


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

Quoted text here. Click to load it

Хмм.... Судя по опыту работы с программами написанными явно не на Форте
утверждение в абсурдности очень сомнительно. С некоторых пор, ярлык "тормоз"
приклеился к очень многим програмным продуктам не смотря на появление
оптимизации в очень многих компиляторах. И я очень сильно сомневаюсь, что
они все писались малограмотными программистами на Бейсике. Так не кажется-ли
Вам, что оптимизируется что-то не то?

Quoted text here. Click to load it
полный
Quoted text here. Click to load it

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

             АртемКАД





_Loader_
Hi Power User,

Tue Sep 30 2003 07:08, Power User wrote to Alex Kouznetsov:
[...]
 YK>>>> Для _такой_ задачи интерпретатор даже может быть полезным.
 PU>>> Если скорость пофигу - возможно что да.
 AK>> Скорость зависит от того как сделан интерпретатор.

 PU> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)

Встречались сообщения, что вполне может переплюнуть,
http://talk.mail.ru/article-26762867.html Чтобы было понятнее, SPF4 - это Форт
с оптимизацией.

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


Re: _Loader_
Hello, Artem Kamburov !

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

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

А можно тоже самое по-русски? Что сказать-то хотел, причем тут память вообще и
виртуальная в частности?

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

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

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

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

Зачем для форт-процессора (кстати массового распространения они не получили)
писать в стиле PIC?

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

Я вообще-то начну с того, что не выберу процессор, для которого на форте
получается код лучше, чем на С. Я много всяких извращений видел, С - далеко не
идеал, С++ - тоже не без странностей, но такого извращения как форт я не
припоминаю с момента моего с ним знакомства году так 89 на 8080...

 >> Если он быстрее (во что я не верю), то асм в руки - и пиши себе шитый код.

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

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

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

 > Вы не совсем понимаете, что есть Форт.

Совсем понимаю. Если алгоритм влазит в кеш на форте, его можно запихать туда и
на родном ассемблере и еще и место останется.

 >  Форт состоит как минимум из:

Да пофигу из чего он состоит.

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

И сброс конвеера и прочие потери при каждом вызове...

 >  А что делают современные компиляторы - они инлайнят процедуры все

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


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


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

Надеюсь тогда (в 89-м) на 8080 Вы и с С и С++ познакомились. Иначе как-то
странно сравнивать.

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

А про прочие не уточните? Особенно по сравнению с загрузкой кеша из
оперативки. Кеш и прочее оптимизировано под многократное выполнение одного
кода, а Си и компания создают практически линейный код или код с вызовом
левых процедур (а-ля DLL).

Quoted text here. Click to load it

 А я думаю они дают удачную стимуляцию спроса на ежегодное обновление железа
(старое-то со старыми задачами на новых программных продуктах не справляется
:-().

                      АртемКАД



Re: _Loader_
Hi Artem,

Fri Oct 03 2003 23:55, Artem Kamburov wrote to Dima Orlov:

 AK> Я их уже реально видел в автомобилях и (по фотографии) в мобилке. Кстати,
 AK> Атмел свою линейку Форт-однокристалок сейчас обновляет - к чему-бы это

Можно упомянуть STM с новой линейкой стековых процессоров STfive. Правда, у
меня лично сложилось впечатление, что его разработчики ничего не знали о
Форте, и потому "изобрели велосипед" немного кривоватый... Это, кстати, дает
редкий пример стекового процессора, который довольно трудно назвать
Форт-процессором. Тем не менее, остаюсь при своем, для меня стековый процессор
и Форт-процессор - синонимы.

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


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

30 сентября 2003 года в 16:04 ты написал к Power User вот что:

 AK>>> Скорость зависит от того как сделан интерпретатор.
 PU>> Hо она никогда не переплюнет скорость работы native кода?! Ж8-)
 AK> Встречались сообщения, что вполне может переплюнуть,
 AK> http://talk.mail.ru/article-26762867.html Чтобы было понятнее, SPF4 -
 AK> это Форт с оптимизацией.

Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм
cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy - как до
Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода бyдет навешано
некотоpое количеcтво телодвижений интеpпpетатоpа. А напиcать нативный код так,
чтобы он выполнялcя дольше, чем такой же алгоpитм в интеpпpетатоpе - это надо
веcьма поcтаpатьcя...

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

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

_Loader_
Hello Eugene!

30 Sep 31 17:44, Eugene Romanov wrote to Alex Kouznetsov:

 ER> Меня теpзают cмyтные cомнения, что это пpоcто иcходный алгоpитм
 ER> cоптимизиpовалcя гpамотно. А до нативного кода любомy интеpпpетатоpy -
 ER> как до Лyны пешком. Ибо на какой-нибyдь "add r0, #15" нативного кода
 ER> бyдет навешано некотоpое количеcтво телодвижений интеpпpетатоpа. А
 ER> напиcать нативный код так, чтобы он выполнялcя дольше, чем такой же
 ER> алгоpитм в интеpпpетатоpе - это надо веcьма поcтаpатьcя...

В свое вpемя я упpажнялся с ОС ДЕМОС на СМ-1420. Был некий бенчмаpк на
пpоизводительность на фоpтpане. Так вот. Компилятоp Фоpтpана-77 давал нативный
код, компилятоp Фоpтpана-4 от Unix v6 - интеpпpетиpуемый. Один и тот же
бенчмаpк фоpтpан-77 компилил в тpи pаза дольше и давал в pезультате загpузочный
модуль в тpи pаза длиннее. Скоpость исполнения у фоpтpана-4 была на единицы
пpоцентов выше. Пpи этом, машина имела сопpоцессоp и оба комилятоpа выдавали
код под сопpоцессоp.

В чем дело?

Anatoly


_Loader_
Привет тебе, Anatoly!

[...]

 AM> Один и тот же бенчмаpк фоpтpан-77 компилил в тpи pаза дольше и давал
 AM> в pезультате загpузочный модуль в тpи pаза длиннее. Скоpость
 AM> исполнения у фоpтpана-4 была на единицы пpоцентов выше. Пpи
 AM> этом, машина имела сопpоцессоp и оба комилятоpа выдавали код под
 AM> сопpоцессоp.

 AM> В чем дело?

Хpеновая оптимизация в компилятоpе. Помнитcя, в cеpедине 90-х пpовели cpавнение
наиболее попyляpных тогда компилятоpов С по оптимальноcти выдаваемого кода.
Один из теcтов был типа:

 a = 1;
 b = a + 1;
 c = a + b;

Borland C выдал пpимеpно такой код:

 mov [sp+4], 1
 mov ax, [sp+4]
 add ax, 1
 mov [sp+6], ax
 add ax, [sp+4]
 mov [sp+8], ax

А дpyгой (TopSpeed С, кажетcя):

 mov ax, 1
 mov bx, 2
 mov cx, 3

Так что вcе завиcит от того, как напиcан нативный код.

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

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

Re: _Loader_
Hi Yuriy,

Sat Oct 04 2003 05:37, Yuriy K wrote to Dima Orlov:

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

 YK> Именно! Программа должна быть сопровождаемой. Причем через два года и
 YK> другим программистом.

Не надо смешивать разные понятия в одну кучу. До сих пор в треде шла речь об
эффективности работы интерпретатора. Было показано, что т.н. "внутренний
интерпретатор", используемый Фортом (т.е. виртуальный Форт-процессор, или FVM,
или стековый процессор), обладает интересными свойствами. В частности, один из
способов его реализации - подпрограммный шитый код - не уступает по
производительности коду, сгенерированному (неплохим) компилятором Си, или
написанному не особо старательным программистом на ассемблере.

Этот факт к языку программирования никак не относится. Каким образом будет
создаваться код для такого интерпретатора - не имеет значения. Если написать
просто ассемблер для FVM, это будет ассемблер FVM. Если этот ассемблер
улучшить, причесать, и превратить в ЯВУ - будет Форт, или ДССП, или что-то
похожее. Если приделать соответствующий бэк-энд к gcc - будет Си. И т.д.

Например, стековый процессор Нейрон, о котором я упоминал, в качестве
фронт-энда использует компилятор Си. Тем не менее, сгенерированный им код
исполняется Форт-процессором.

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


_Loader_
Sat Oct 04 2003 08:12, Alex Kouznetsov wrote to Yuriy K:

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

 YK>> Именно! Программа должна быть сопровождаемой. Причем через два года и
 YK>> другим программистом.

 AK> Hе надо смешивать разные понятия в одну кучу. До сих пор в треде шла речь
 AK> об эффективности работы интерпретатора.

Hе надо смешивать разные понятия в одну кучу. _Интерпретатор_ отличается тем,
что сам исполняемый код не исполняется. А начался тред с того, что
интерпретатор лучше защищен от зависаний программы.

 AK> Было показано, что т.н.
 AK> "внутренний интерпретатор", используемый Фортом (т.е. виртуальный
 AK> Форт-процессор, или FVM, или стековый процессор), обладает интересными
 AK> свойствами. В частности, один из способов его реализации - подпрограммный
 AK> шитый код - не уступает по производительности коду, сгенерированному
 AK> (неплохим) компилятором Си, или написанному не особо старательным
 AK> программистом на ассемблере.

Это уже не интерпретатор, а компилятор.  См. выше.

 AK> Этот факт к языку программирования никак не относится.

Именно.

Итого:
1) Форт в качестве языка написания программ плох ибо программы на нем
нечитаемы и неподдерживаемы.
2) Чистый форт-_интерпретатор_, как и любой другой интерпретатор будет
гораздо медленнее (приличного) _компилятора_ с любого языка.

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

О чем спорим? Ж:-)

WBR, Юрий.


_Loader_
Hi Yuriy K,

Sat Oct 04 2003 11:25, Yuriy K wrote to Alex Kouznetsov:

 YK>>> Именно! Программа должна быть сопровождаемой. Причем через два года и
 YK>>> другим программистом.

 AK>> Hе надо смешивать разные понятия в одну кучу. До сих пор в треде шла
 AK>> речь  об эффективности работы интерпретатора.

 YK> Hе надо смешивать разные понятия в одну кучу. _Интерпретатор_ отличается
 YK> тем,  что сам исполняемый код не исполняется. А начался тред с того, что
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  :-)
Определение, что такое интерпретатор, знаешь? Похоже, не знаешь... :(
Определение FOLDOC: INTERPRETER - A program which executes other programs.

 YK> интерпретатор лучше защищен от зависаний программы.

Ессно, защищен.

 AK>> Было показано, что т.н.
 AK>> "внутренний интерпретатор", используемый Фортом (т.е. виртуальный
 AK>> Форт-процессор, или FVM, или стековый процессор), обладает интересными
 AK>> свойствами. В частности, один из способов его реализации -
 AK>> подпрограммный  шитый код - не уступает по производительности коду,
 AK>> сгенерированному  (неплохим) компилятором Си, или написанному не особо
 AK>> старательным  программистом на ассемблере.

 YK> Это уже не интерпретатор, а компилятор.  См. выше.

Не употребляй красивых слов, смысл которых тебе непонятен ;-) Определение, что
такое компилятор, знаешь? Тоже, похоже, не знаешь... Подпрограммный шитый код
_ничего_не_компилирует_. Читай А.Ахо, Р.Сети, Д.Ульман, "Компиляторы.
Принципы, технологии, инструменты", изд.Вильямс 2001:
Компилятор - это программа, которая считывает текст программы, написанной на
одном языке - исходном, и транслирует (переводит) его в эквивалентный текст на
другом языке - целевом.

 YK> 2) Чистый форт-_интерпретатор_, как и любой другой интерпретатор будет
 YK> гораздо медленнее (приличного) _компилятора_ с любого языка.

Тебе внятно показали, что интерпретатор подпрограммного шитого кода работает
не медленнее, чем нативная программа, скомпилированная VC7. И долго
разжевывали, объясняя, за счет чего это происходит.

 YK> Остается (с твоих слов) использовать приличный язык для написания
 YK> программ, затем компилятор в форт и подпрограммный шитый код, но тогда

На языке Форт писать, или на этот язык транслировать - тебя никто не
заставляет. Да и транслятор С-Форт ты вряд ли найдешь.

 YK> теряется та  самая возможность запретить написание завешиваемых программ,
 YK> с которой все и началось.

Если в интерпретаторе нет операторов, которые позволят "завесить" программу,
то завесить ее нельзя. Для начала, нет операторов, которые запрещают
прерывание. В том самом подпрограммном шитом коде (иными словами - в
библиотеке, которая _уже_ находится в памяти, так что ее ее ни компилировать,
ни грузить больше не надо).

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


_Loader_
Sat Oct 04 2003 12:38, Alex Kouznetsov wrote to Yuriy K:

 YK>>>> Именно! Программа должна быть сопровождаемой. Причем через два года и
 YK>>>> другим программистом.

 AK>>> Hе надо смешивать разные понятия в одну кучу. До сих пор в треде шла
 AK>>> речь  об эффективности работы интерпретатора.

 YK>> Hе надо смешивать разные понятия в одну кучу. _Интерпретатор_ отличается
 YK>> тем,  что сам исполняемый код не исполняется. А начался тред с того, что

 AK>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  :-)

Да, действительно, я имел в виду "source code",

 AK> Определение, что такое интерпретатор, знаешь? Похоже, не знаешь... :(

Я-то знаю...

 AK> Определение FOLDOC: INTERPRETER - A program which executes other
 AK> programs.

Hе надо заниматься художественным цитированием.

Definition:         

A program which executes other programs. This is in contrast to a compiler
which does not execute its input program (the "source code") but translates
it into executable "machine code" (also called "object code") which is output
to a file for later execution. It may be possible to execute the same source
code either directly by an interpreter or by compiling it and then executing
the machine code produced.

Программист будет писать непосредственно шитым кодом?
Передавай ему мои соболезнования.

 YK>> интерпретатор лучше защищен от зависаний программы.

 AK> Ессно, защищен.

 AK>>> Было показано, что т.н.
 AK>>> "внутренний интерпретатор", используемый Фортом (т.е. виртуальный
 AK>>> Форт-процессор, или FVM, или стековый процессор), обладает интересными
 AK>>> свойствами. В частности, один из способов его реализации -
 AK>>> подпрограммный  шитый код - не уступает по производительности коду,
 AK>>> сгенерированному  (неплохим) компилятором Си, или написанному не особо
 AK>>> старательным  программистом на ассемблере.

Hе было показано.

 YK>> Это уже не интерпретатор, а компилятор.  См. выше.

 AK> Hе употребляй красивых слов, смысл которых тебе непонятен ;-)
 AK> Определение, что такое компилятор, знаешь? Тоже, похоже, не знаешь...

Hу-ну...

 AK> Подпрограммный шитый код _ничего_не_компилирует_.

Естественно. Только кто-то должен этот "шитый код" создать. Кто?

 AK> Компилятор - это программа, которая считывает текст программы, написанной
 AK> на одном языке - исходном, и транслирует (переводит) его в эквивалентный
 AK> текст на другом языке - целевом.

И?

 YK>> Остается (с твоих слов) использовать приличный язык для написания
 YK>> программ, затем компилятор в форт и подпрограммный шитый код, но тогда

 AK> Hа языке Форт писать, или на этот язык транслировать - тебя никто не
 AK> заставляет. Да и транслятор С-Форт ты вряд ли найдешь.

Это радует, значит здравый смысл еще не потерян.
Так все-же на каком языке будет писать программист?

 YK>> теряется та  самая возможность запретить написание завешиваемых
 YK>> программ,  с которой все и началось.

 AK> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK> программу, то завесить ее нельзя.

Выделение временной памяти под переменные/массивы на стеке есть?
Проверка глубины стека производится при каждом создании переменной/массива?

Если да, то прощай эффективность.
Если нет, то завесить становится несложно.

 AK> Для начала, нет операторов, которые запрещают прерывание.

Прекрасно. Работу с железом как писать будешь (см. название эхи)?

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

?? Память она все равно занимает, времени на выполнение требует.

Те самые подпрограммы откуда берутся?
Кто и на каком языке пишет расширения библиотек?

Если только с использованием имеющихся слов, то исходные слова должны
позволять низкоуровневый доступ к ресурсам - прощай защищенность.

Если можно писать новые слова в машинном коде, то как?

Hет в жизни счастья...


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

WBR, Юрий.


_Loader_
Sat Oct 04 2003 13:15, Yuriy K wrote to Alex Kouznetsov:

 YK> Программист будет писать непосредственно шитым кодом?
 YK> Передавай ему мои соболезнования.

С чего это ты взял? Никто такого не говорил.

 AK>> Подпрограммный шитый код _ничего_не_компилирует_.

 YK> Естественно. Только кто-то должен этот "шитый код" создать. Кто?

Компилятор, ессно. Кроссовый.
Только зачем ты в одну кучу мешаешь компилятор и интерпретатор? Если таким
образом ("все в одном флаконе") устроен классический Форт, это еще не повод
все и каждую систему делать именно таким образом.

 AK>> Компилятор - это программа, которая считывает текст программы,
 AK>> написанной  на одном языке - исходном, и транслирует (переводит) его в
 AK>> эквивалентный  текст на другом языке - целевом.

 YK> И?

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

 YK>>> Остается (с твоих слов) использовать приличный язык для написания
 YK>>> программ, затем компилятор в форт и подпрограммный шитый код, но тогда

 AK>> Hа языке Форт писать, или на этот язык транслировать - тебя никто не
 AK>> заставляет. Да и транслятор С-Форт ты вряд ли найдешь.

 YK> Это радует, значит здравый смысл еще не потерян.
 YK> Так все-же на каком языке будет писать программист?

Я лично пишу на языке, похожем на язык Форт. Потому что у меня к нему
идиосинкразии нет. И еще потому, что написать транслятор с этого языка в
байт-код для моего интерпретатора для меня труда не представляет.
Другие пусть пишут на чем хотят, на том, что смогут найти, или создать сами.

 YK>>> теряется та  самая возможность запретить написание завешиваемых
 YK>>> программ,  с которой все и началось.

 AK>> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK>> программу, то завесить ее нельзя.

 YK> Выделение временной памяти под переменные/массивы на стеке есть?
 YK> Проверка глубины стека производится при каждом создании
 YK> переменной/массива?
 YK> Если да, то прощай эффективность.
 YK> Если нет, то завесить становится несложно.

А это от тебя зависит. Надо больше скорости - поступайся надежностью, и
наоборот.

 AK>> Для начала, нет операторов, которые запрещают прерывание.
Добавлю - также нет операторов, обслуживающих WDT

 YK> Прекрасно. Работу с железом как писать будешь (см. название эхи)?

Тебе лень подумать, или ты правда не понимаешь? Для работы с железом
исползуются низкоуровневые слова=операторы=подпрограммы=функции. Но, скажем,
нет таких слов, которые могли бы запретить прерывания или обслужить WDT.

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

 YK> ?? Память она все равно занимает, времени на выполнение требует.
 YK> Те самые подпрограммы откуда берутся?
 YK> Кто и на каком языке пишет расширения библиотек?

На любом языке. Я лично пишу на С или на ассемблере.

 YK> Если только с использованием имеющихся слов, то исходные слова должны
 YK> позволять низкоуровневый доступ к ресурсам - прощай защищенность.
 YK> Если можно писать новые слова в машинном коде, то как?

"Новые слова" - это последовательности вызовов "старых слов".

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


_Loader_
Sat Oct 04 2003 16:35, Alex Kouznetsov wrote to Yuriy K:

 YK>> Программист будет писать непосредственно шитым кодом?
 YK>> Передавай ему мои соболезнования.

 AK> С чего это ты взял? Hикто такого не говорил.

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

 AK>>> Подпрограммный шитый код _ничего_не_компилирует_.
 YK>> Естественно. Только кто-то должен этот "шитый код" создать. Кто?
 AK> Компилятор, ессно. Кроссовый.

Hу слава богу, договорились. :))

 AK> Только зачем ты в одну кучу мешаешь компилятор и интерпретатор? Если
 AK> таким образом ("все в одном флаконе") устроен классический Форт, это еще
 AK> не повод все и каждую систему делать именно таким образом.

Какой еще язык генерит шитый код, кроме Бейсика?

 AK> А целевой код, странслированный кросс-компилятором, грузится в память
 AK> целевого проца и исполняется интерпретатором. Интерпретатор к моменту
 AK> загрузки целевого кода уже находится в памяти, так что компилировать его
 AK> тем же компилятором не надо.

Зато его придется загружать в столь подробно обсуждаемый здесь кэш.

 YK>> Это радует, значит здравый смысл еще не потерян.
 YK>> Так все-же на каком языке будет писать программист?

 AK> Я лично пишу на языке, похожем на язык Форт. Потому что у меня к нему
 AK> идиосинкразии нет. И еще потому, что написать транслятор с этого языка в
 AK> байт-код для моего интерпретатора для меня труда не представляет.

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

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

"Опора только на собственные силы". Это подходит только для небольших
задач, где не более одного человека на проект.

 YK>>>> теряется та  самая возможность запретить написание завешиваемых
 YK>>>> программ,  с которой все и началось.

 AK>>> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK>>> программу, то завесить ее нельзя.

Правда такой интерпретатор будет _очень_ медленным...

 YK>> Выделение временной памяти под переменные/массивы на стеке есть?
 YK>> Проверка глубины стека производится при каждом создании
 YK>> переменной/массива?
 YK>> Если да, то прощай эффективность.
 YK>> Если нет, то завесить становится несложно.

 AK> А это от тебя зависит. Hадо больше скорости - поступайся надежностью, и
 AK> наоборот.

Вот-вот, начинаем находить общую точку зрения.
Эффективный "форт" - не более защищен, чем тот же С/С++/whatever.
Защищенный "форт" - страшно медленный и неэффективный, так же как и все
остальные способы защиты программ от ошибок.
Где преимущества?

 AK>>> Для начала, нет операторов, которые запрещают прерывание.
 AK> Добавлю - также нет операторов, обслуживающих WDT

Соболезную. В embedded системах чаще всего должны быть.

 YK>> Прекрасно. Работу с железом как писать будешь (см. название эхи)?

 AK> Тебе лень подумать, или ты правда не понимаешь?

Мне интересно, что _ты_ можешь сказать.

 AK> Для работы с железом
 AK> исползуются низкоуровневые слова=операторы=подпрограммы=функции.

Кто их пишет и на каком языке?

 AK> Hо,
 AK> скажем, нет таких слов, которые могли бы запретить прерывания или
 AK> обслужить WDT.

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

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

 YK>> ?? Память она все равно занимает, времени на выполнение требует.
 YK>> Те самые подпрограммы откуда берутся?
 YK>> Кто и на каком языке пишет расширения библиотек?

 AK> Hа любом языке. Я лично пишу на С или на ассемблере.

Прощай защищенность. Кстати это противоречит твоим же словам о замечательном
быстродействии "форта"...

 YK>> Если только с использованием имеющихся слов, то исходные слова должны
 YK>> позволять низкоуровневый доступ к ресурсам - прощай защищенность.
 YK>> Если можно писать новые слова в машинном коде, то как?

 AK> "Hовые слова" - это последовательности вызовов "старых слов".

Если старые слова не обеспечивают доступ к железу? См. выше.

WBR, Юрий.


_Loader_
Sat Oct 04 2003 18:55, Yuriy K wrote to Alex Kouznetsov:

 YK>>> Программист будет писать непосредственно шитым кодом?
 YK>>> Передавай ему мои соболезнования.

 AK>> С чего это ты взял? Hикто такого не говорил.

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

А я именно так сразу и говорил, следить надо за тредом, и переспрашивать, если
непонятно:

--- start quote ---
Thu Oct 02 2003 13:48, Alex Kouznetsov wrote to Eugene Romanov:
 AK> Для информациии: в состав Форта обычно входят два интерпретатора
 AK> ("наружный" и "внутренний") и компилятор.
--- end quote ---

Это пояснение было дано специально, на тот случай, если кто-то не знаком с
Фортом, и не знает что находится "внутри" SPF.

 AK>> Только зачем ты в одну кучу мешаешь компилятор и интерпретатор? Если
 AK>> таким образом ("все в одном флаконе") устроен классический Форт, это еще
 AK>> не повод все и каждую систему делать именно таким образом.

 YK> Какой еще язык генерит шитый код, кроме Бейсика?

Вынужден повторить, к языку это не имеет никакого отношения. Шитый код может
генерироваться компилятором любого языка.

 AK>> А целевой код, странслированный кросс-компилятором, грузится в память
 AK>> целевого проца и исполняется интерпретатором. Интерпретатор к моменту
 AK>> загрузки целевого кода уже находится в памяти, так что компилировать его
 AK>> тем же компилятором не надо.

 YK> Зато его придется загружать в столь подробно обсуждаемый здесь кэш.

В честь чего? Откуда это у тебя такая идея взялась? Если в моем проце вообще
нет кэша, куда мне его _придется_ загружать?

 YK>>> Так все-же на каком языке будет писать программист?

 AK>> Я лично пишу на языке, похожем на язык Форт. Потому что у меня к нему
 AK>> идиосинкразии нет. И еще потому, что написать транслятор с этого языка в
 AK>> байт-код для моего интерпретатора для меня труда не представляет.

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

Точно таким же образом, как и любые другие.

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

 YK> "Опора только на собственные силы". Это подходит только для небольших
 YK> задач, где не более одного человека на проект.

Большие проекты, например, можешь писать на Форте. Или на Java. Или на С#,
если сможешь сделать транслятор из MSIL (или как его там?) в свой байт-код.

 YK>>>>> теряется та  самая возможность запретить написание завешиваемых
 YK>>>>> программ,  с которой все и началось.

 AK>>>> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK>>>> программу, то завесить ее нельзя.

 YK> Правда такой интерпретатор будет _очень_ медленным...

Представь, перед тобой два почти идентичных интерпретатора. Но в первом есть
операторы обслуживания WDT и запрещения прерываний, а во втором - нету. Ты
будешь продолжать утверждать, что второй "будет _очень_ медленным"? Тогда
обоснуй - почему, в честь чего отсутствие этих операторов замедлит второй
интерпретатор?

 AK>> Hа любом языке. Я лично пишу на С или на ассемблере.

 AK>> А это от тебя зависит. Hадо больше скорости - поступайся надежностью, и
 AK>> наоборот.

 YK> Вот-вот, начинаем находить общую точку зрения.
 YK> Эффективный "форт" - не более защищен, чем тот же С/С++/whatever.
 YK> Защищенный "форт" - страшно медленный и неэффективный, так же как и все
 YK> остальные способы защиты программ от ошибок.
 YK> Где преимущества?

 AK>>>> Для начала, нет операторов, которые запрещают прерывание.
 AK>> Добавлю - также нет операторов, обслуживающих WDT

 YK> Соболезную. В embedded системах чаще всего должны быть.

 YK>>> Прекрасно. Работу с железом как писать будешь (см. название эхи)?

 AK>> Тебе лень подумать, или ты правда не понимаешь?

 YK> Мне интересно, что _ты_ можешь сказать.

 AK>> Для работы с железом
 AK>> исползуются низкоуровневые слова=операторы=подпрограммы=функции.

 YK> Кто их пишет и на каком языке?

 AK>> Hо,
 AK>> скажем, нет таких слов, которые могли бы запретить прерывания или
 AK>> обслужить WDT.

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

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

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

 YK>>> Если только с использованием имеющихся слов, то исходные слова должны
 YK>>> позволять низкоуровневый доступ к ресурсам - прощай защищенность.
 YK>>> Если можно писать новые слова в машинном коде, то как?

 AK>> "Hовые слова" - это последовательности вызовов "старых слов".

 YK> Если старые слова не обеспечивают доступ к железу? См. выше.

Нет, ты явно "не въезжаешь". Похоже, у тебя в голове представление о том, что
все приложение, с начала до конца, обязательно должно интерпретироваться? Я
уже писал, воспринимай (удаленно) загружаемый байт-код как "Java апплет". Это
лишь часть общей системы, и на нее накладываются серьезные ограничения, в том
числе в целях обеспечения безопасности, чтобы проц не завесить.
Сама Java в чистом виде меня не устраивает по следующим причинам:
-- громоздкость (даже для Embedded Java)
-- скорость (мои интерпретаторы работают быстрее)

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


_Loader_
Sun Oct 05 2003 04:26, Alex Kouznetsov wrote to Yuriy K:

 YK>>>> Так все-же на каком языке будет писать программист?

 AK>>> Я лично пишу на языке, похожем на язык Форт. Потому что у меня к нему
 AK>>> идиосинкразии нет. И еще потому, что написать транслятор с этого языка
 AK>>> в  байт-код для моего интерпретатора для меня труда не представляет.

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

 AK> Точно таким же образом, как и любые другие.

И будут продолжать писать трансляторы.
Мои соболезнования твоим работодателям, когда они это поймут на собственной
шкуре.

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

 YK>> "Опора только на собственные силы". Это подходит только для небольших
 YK>> задач, где не более одного человека на проект.

 AK> Большие проекты, например, можешь писать на Форте. Или на Java. Или на
 AK> С#, если сможешь сделать транслятор из MSIL (или как его там?) в свой
 AK> байт-код.

Я _компиляторы_ не писал, не пишу и не собираюсь писать. Для этого есть
другие люди в других конторах.


 YK>>>>>> теряется та  самая возможность запретить написание завешиваемых
 YK>>>>>> программ,  с которой все и началось.

 AK>>>>> Если в интерпретаторе нет операторов, которые позволят "завесить"
 AK>>>>> программу, то завесить ее нельзя.

 YK>> Правда такой интерпретатор будет _очень_ медленным...

 AK> Представь, перед тобой два почти идентичных интерпретатора. Hо в первом
 AK> есть операторы обслуживания WDT и запрещения прерываний, а во втором -
 AK> нету. Ты будешь продолжать утверждать, что второй "будет _очень_
 AK> медленным"?

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

 YK>> Вот-вот, начинаем находить общую точку зрения.
 YK>> Эффективный "форт" - не более защищен, чем тот же С/С++/whatever.
 YK>> Защищенный "форт" - страшно медленный и неэффективный, так же как и все
 YK>> остальные способы защиты программ от ошибок.

Где преимущества?

 AK>>> Для работы с железом
 AK>>> исползуются низкоуровневые слова=операторы=подпрограммы=функции.

Кто их пишет и на каком языке?

 AK>>> Hо,
 AK>>> скажем, нет таких слов, которые могли бы запретить прерывания или
 AK>>> обслужить WDT.

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

 YK>>>> Если только с использованием имеющихся слов, то исходные слова должны
 YK>>>> позволять низкоуровневый доступ к ресурсам - прощай защищенность.
 YK>>>> Если можно писать новые слова в машинном коде, то как?

 AK>>> "Hовые слова" - это последовательности вызовов "старых слов".

Если старые слова не обеспечивают доступ к железу? См. выше.

WBR, Юрий.


Site Timeline