_Loader_ - Page 3

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

Нет конечно. Если говорить ПО-РУССКИ, то скорость "интерпретатора" к скорости
"компилятора" не имеет никакого отношения. Если интерпретировать твое
высказывание так,
как ты сам надеялся оно будет проинтерпретировано - то есть, "скорость
выполнения программ
интерпретатором ФОРТа медленнее скорости выполнения программ откомпилированных
компиляторами с другого языка", то это тоже не правда. Все зависит от того, во
что именно
производится компиляция. "Компилирование" не подразумевает получение на выходе
двоичной
объектной программы на машинном языке! Не даром Орлов говорил все время о
НАТИВНОМ КОДЕ. И
естественно скорость интерпретирования не будет "гораздо" медленнее - она будет
всего лишь
"несколько" медленнее.

Quoted text here. Click to load it

Учите русскава языка, оне рулез!

Аркадий

ЗЫ ФОРТ это несомненная жемчужина среди языков программирования, знание его
основ и идей
несомненно полезно любому программисту. Использовать его широко в реальной жизни
- ну это
врятли.

Re: _Loader_
Hello, Alex Kouznetsov !

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

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

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

Было это только сказано, показано этого не было.

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

С программистом на ассемблере тут и вовсе смешно сравнивать.

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

Это пока что не факт, а только малоправдоподобное допущение.

 > образом будет создаваться код для такого интерпретатора - не имеет значения.
 > Если написать просто ассемблер для FVM, это будет ассемблер FVM.

Это и будет собственно форт.

 > Если этот ассемблер
 > улучшить, причесать, и превратить в ЯВУ - будет Форт, или ДССП,
 > или что-то
 > похожее. Если приделать соответствующий бэк-энд к gcc - будет Си.

Для нормальных процессоров это бессмысленно и так никто не делает.

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

Hе форт-процессором, а стековой машиной.


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


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

Что-то письмо кажется не дошло до фидо:(
Попытка 2 (кто нибудь киньте ACK если оно дошло в эху?:)

[...]
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 !

 > ЗЫ: в предыдущем постинге забыл упомянуть...
 > Hасколько Окамл способен (надеюсь) создавать код, написать который
 > просто не придет в голову обычному эмбедеру, настолько же и Форт-система

А что это за Окамл такой?

 > организована в определенном смысле необычно и во многих смыслах эффективно.

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

 > Поэтому человеку,
 > незнакомому с принципами работы Форта, тоже в голову не придет
 > писать на ассемблере так, как написан Форт. Хотя вообще говоря его, казалось

Hадеюсь, что не прийдет.

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

:) По твоему плохо относиться можно только к тому, чего не знаешь?


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


_Loader_
What do you think about sharp blades, Dima?

[Answer on] [Dima Orlov wrote to Alex Kouznetsov at [04 Oct 03 09:48]]:

 >> ЗЫ: в предыдущем постинге забыл упомянуть...
 >> Hасколько Окамл способен (надеюсь) создавать код, написать который
 >> просто не придет в голову обычному эмбедеру, настолько же и
 >> Форт-система
 DO> А что это за Окамл такой?
  Object CaML. ML-подобный функциональный язык.
  Дмитрий, быть хорошим программистом и не знать основных течений в _науке_
программирования, IMHO, все-таки нельзя. Hе знать форта, лиспа и его
последователей (ML хотя бы), не слышать об O'Caml и при этом быть
программистом, а не кодером-обезъянкой... Nothing personal, конечно, но это как
Кнута и Дийкстру не читать...

    Remember, pain is part of pleasure, Dima.
... Hормальное состояние - скрип зубов за стеной...

_Loader_
Hello, Lev Serebryakov !

 >>> ЗЫ: в предыдущем постинге забыл упомянуть...
 >>> Hасколько Окамл способен (надеюсь) создавать код, написать который
 >>> просто не придет в голову обычному эмбедеру, настолько же и
 >>> Форт-система
 >  DO> А что это за Окамл такой?
 >   Object CaML. ML-подобный функциональный язык.

 >   Дмитрий, быть хорошим программистом и не знать основных течений
 > в _науке_ программирования, IMHO, все-таки нельзя. Hе знать форта,

Может быть и нельзя. А вот инженером, разрабатывающими и железо и софт к нему -
можно. Для моих задач С и ассемблера более чем достаточно, даже С++ перебор. С
фортом я в свое время знакомился, пробовал на нем писать для 8080, но быстро
пришел к тому, что лучше уж на ассемблере чем на этом изврате. И в плане
последующего сопровождения в том числе. Hо если бы форт прошел совсем мимо
меня, я бы тоже ничего не потерял.

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


Re: _Loader_

        Haile ande faile Dima!

Quoted text here. Click to load it

DO> А что это за Окамл такой?

===
OVERVIEW:

Objective Caml is an implementation of the ML language, based on the Caml
Light dialect extended with a complete class-based object system and a
powerful module system in the style of Standard ML.

Objective Caml comprises two compilers. One generates bytecode which is then
interpreted by a C program. This compiler runs quickly, generates compact code
with moderate memory requirements, and is portable to essentially any 32 or 64
bit Unix platform. Performance of generated programs is quite good for a
bytecoded implementation: almost twice as fast as Caml Light 0.7. This
compiler can be used either as a standalone, batch-oriented compiler that
produces standalone programs, or as an interactive, toplevel-based system.

The other compiler generates high-performance native code for a number
of processors. Compilation takes longer and generates bigger code, but
the generated programs deliver excellent performance, while retaining
the moderate memory requirements of the bytecode compiler. The
native-code compiler currently runs on the following platforms:

    Intel/AMD Pentium processors: PCs under Linux, FreeBSD, NetBSD,
      OpenBSD, Windows, NextStep, Solaris 2, BeOS.
    PowerPC processors: PowerMacintosh under MacOS X and LinuxPPC,
      IBM RS6000 and PowerPC workstations under AIX 4.3
    AMD64 (Opteron) processors: PCs under Linux.
    Alpha processors: Digital/Compaq/HP Alpha machines under
      Digital Unix/Compaq Tru64, Linux, NetBSD and OpenBSD.
    Sparc processors: Sun Sparc machines under Solaris 2, NetBSD, Linux
    Mips processors: SGI workstations and mainframes under IRIX 6
    Intel IA64 processors: HP stations under Linux
    HP PA-RISC processors: HP 9000/700 under HPUX 10
    Strong ARM processors: Corel Netwinder under Linux

Other operating systems for the processors above have not been tested, but the
compiler may work under other operating systems with little work.

Before the introduction of objects, Objective Caml was known as Caml Special
Light. Objective Caml is almost upwards compatible with Caml Special Light,
except for a few additional reserved keywords that have forced some renaming
of standard library functions.
===
(c)README

Живёт на caml.inria.fr

--
С уважением, Алексей Шапошников.


Re: _Loader_
Hello everybody.

03 Oct 03 00:05, Oleksandr Redchuk wrote to "Alex Kouznetsov":

 OR>   Это отдельнй разговор.
 OR>  "Это" - это то, что для современных процессоров с несколькими исп.
 OR> устройствами, переименованием регистров, out of order исполнением и
 OR> т.п. на асме ручками тяжело всё учесть и _хороший_ компилятор ЯВУ

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

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

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

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

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

Roman


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

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

Java - все же несколько не то. Форт <> байткод.

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

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

Абсолютно верно!

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

Представим, что действительно все (ну или почти все) команды в исходном
алгоритме зависимы по данным. Уже стало гораздо лучше. Естественно, не нужно
пихать стековые машины куда попало, тем более решать с их помощью явно не
предназначенные для этого задачи. Стек есть стек, он имеет свои особенности
просто по определению. В частности, операции с ним не параллелятся. А вот
компилировать код для стековой машины обычно гораздо проще. Для сравнения
рассмотрим 4 симметричных регистра, и добавим к ним пятый. Можно ли навскидку
сказать, каким будет повышение производительности кода от такого добавления,
как именно нужно изменить компилятор и для каких задач добавление пятого
регистра вообще актуально?


Re: _Loader_
Привет Artem!

Monday October 06 2003 19:37, Artem Kamburov wrote to Alexander Torres:

 >> тогда и процессор не АВР и ему подобный нужен), а может и лучше.
 AK>
 AK> У AVR с АЦП алгоритм даже проще чем с компаратором. Естественно без ДПФ-а
 AK> :).

А с чем? Обрабатывать-то все равно надо, а АВР не ДСП, МАС операции у него ёк.

 AK> Единственная проблема - каждые 100мкс дергает прерывание - спать не
 AK> получается :(.

Ты хочешь сказать, что у тебя 10кгц оцифровка? И АВР успевает за 100мкс сделать
выделение шести частот не ХОРом восьми однобитных отсчетов с массивами?
Чудеса.....

Впрочем, году в 87-м я познакомился с одним человеком, Славой Губановым,
автором микро-ЭВМ "Энерго" (плата с 8080, 55-м, светодиоднымой АЛС-кой и
кнопками от калькулятора), так он тоже утверждал что "программа на Форте
работает быстрее чем на ассемблере" :-))

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



_Loader_
Mon Oct 06 2003 18:29, Alexander Torres wrote to Artem Kamburov:


 AT> А с чем? Обрабатывать-то все равно надо, а АВР не ДСП, МАС операции у
 AT> него ёк.

 AK>> Единственная проблема - каждые 100мкс дергает прерывание - спать не
 AK>> получается :(.

 AT> Ты хочешь сказать, что у тебя 10кгц оцифровка? И АВР успевает за 100мкс
 AT> сделать выделение шести частот не ХОРом восьми однобитных отсчетов с
 AT> массивами? Чудеса.....

 Hикаких чудес. Hа x51 получалось сделать честную работу с 4-битной входной
 отцифровкой и умножением на sin/cos при частоте дискретизации ~4.8kHz.
 Hе вижу особых проблем сделать ~8bit/8kHz на быстром AVR с умножением.

 VLV

"There is no business other than show business" (c)


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

Quoted text here. Click to load it
ёк.

Сложение/вычитание есть - и на том спасибо :). Есть еще умножение, но это
уже совсем для ленивых :).

Quoted text here. Click to load it
сделать
Quoted text here. Click to load it

 И я говорю - чудеса..... Примерно за 10 милисекунд (предварительное
решение) и не шести, а семи частот.
 100мкс - 800 тактов при 8 Мег - не смешите меня - это море времени. Метод
смотрите в разделе квазиоптимального обнаружения. ХОР-ами там и не пахнет.

Quoted text here. Click to load it

У меня общение с аппаратом на нем написано (почти на нем :)).

                    АртемКАД




Re: _Loader_
Hi Artem!

В понедельник, 06 октябpя 2003 02:05:50, Artem Kamburov писал to Roman Khvatov:

 AK> Hе верно. Посмотрите на MS WINWORD - это приложение занимает в памяти
 AK> больше 10 метров. И где там код, выполняющийся многократно (не думаю,
 AK> что это опрос клавиатуры :)) из-за которого все приложение тормоз?

Вывод на экран, последовательный просмотр документа и ядро интерпретатора
Бейсика.

                                                                Sincerely,
                                                                       Vadim.

Re: _Loader_
Hello Artem.

06 Oct 03 02:05, you wrote to me:

 >> Hет. Код, выполняемый однократно, вообще не влияет на
 >> производительность, именоо из за того, что выполняется однократно.

 AK> Hе верно.

Верно верно.

 AK> Посмотрите на MS WINWORD - это приложение занимает в памяти
 AK> больше 10 метров.

Я не расматриваю приложение которое _вообще_ не работает. Весь WINWORD сидит на
ожидании нажатия клавиатуры, и у него _вообще_ нет кусков, которые работают
чаще других - в среднем они все не работают.

 AK> И где там код, выполняющийся многократно (не думаю,
 AK> что это опрос клавиатуры :)) из-за которого все приложение тормоз?

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

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

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

 AK> Вообще-то тут важен только объем, при многократности повторения объем
 AK> занимаемый в кеше не увеличивается :).

Как раз не объем. Если у нас есть один кусок кода на 10М, выполняющийся один
раз, то сколько бы кэша он не занял, 'горячий' цикл, размером в 1К все равно в
конце концов уляжется в кэш, вытеснив оттуда кусочек из 10М первого куска. И
это 'в конце концов' произойдет весьма быстро - на нескольких первых итерациях.

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

Вы путаете производительность программы и скорость ее реакции на внешние
события - это вполне независимые вещи. Первое определяется в основном
исполняемым кодом, второе - построением ОС.

 >>  AK> А без билдера написание Win-приложения на С за 30 минут с
 >>  AK> нормальным интерфейсом почти нереальная задача.
 >>
 >> Самый нормальный интерфейс - это командная строка :) Для нее можно
 >> писать под Win и быстрее, чем за 30 минут.

 AK> Если бы командной строки было-бы достаточно, я бы вообще для ПК не
 AK> писал. Писать приходится при автоматизации рабочего места для полного
 AK> чайника в ЭВМ (от командной строки у него глаза на лоб лезут 8-D).

Хм. Я по наивности думал, что вам приходится писать мелкие тулзы для облегчения
своей работы, писание для юзеров (особенно если они полные чайники) это совсем
другая песня, и обычно она плохо сочетается с програмированием МК/ваянием
железа - для этого нужны совершенно другие знания. Обычно это делают разные
люди. (Я не утверждаю, что нет людей, которые не могут это эффективно сочетать,
но они _очень_ редко встречаются)

Roman


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
итерациях.

Скорее всего в первой :).
 Так вот я и веду речь о языке полностью построенном на принципе "горячего
цикла". Он создает код, который состоит из набора примитивов и остальной
части. Остальная часть работает методом постоянных вызовов этих примитивов
(по сути не отпуская их из кеша). Объем примитивов мал (теоретически меньше
64к на очень сложное приложение) и с очень большой вероятностью требуемый
примитив окажется в кеше. Кроме того, при использовании косвенного шитого
кода остальная часть будет вообще грузиться в кеш данных. Цена такого
построения - больше 4 тактов + сброс конвеера на каждый вызов.
 Что будет быстрее выполнятся в различных условиях - нативный код или такой,
однозначно сказать не могу, но ИМХО возможны оба варианта.

Quoted text here. Click to load it

У меня в трее весит nnCron (то-же Форт и то-же реакция на событие). Так у
него одна из больших проблем, что он реагирует и обрабатывает события
системы намного быстрее, чем приложения за которыми он следит (приходится
ставить приличные задержки). Т.е. события ОС раздает одновременно, а
тормозит уже их обработка (производительность приложения) :(.

                   АртемКАД



Re: _Loader_
Привет Ilia!

Monday October 06 2003 23:44, Ilia Tarasov wrote to Dima Orlov:

 IT>
 IT> Sun Oct 05 2003 22:43, Dima Orlov wrote to Ilia Tarasov:
 IT>
 >>> Hу, кому как. Согласен, для подавляющего большинства разработчиков
 >>> разработка собственного компилятора - далеко не первоочередная задача.
 IT>
 DO>> Это вообще не его задача. Подавляющее большинство разработчиков в
 DO>> один день окажется на улице, если руководство узнает что вместо
 DO>> решения своих задач он самодельные компиляторы пишет.
 IT>
 IT> Hекоторые разработчики окажутся на улице, если _я_ узнаю, что они HЕ пишут
 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



_Loader_
Mon Oct 06 2003 22:00, Alexander Torres wrote to Ilia Tarasov:

 IT>> Hекоторые разработчики окажутся на улице, если _я_ узнаю, что они HЕ
 IT>> пишут  самодельные компиляторы, несмотря на явно поставленную задачу...
 IT>> ;)

 AT> Т.е. ты и они не сабжем занимаетесь, а написанием компиляторов?

Мы занимаемся проектированием и выпуском изделий с embedded-контроллерами. Ты
хочешь сказать, что разработка специализированных инструментов в принципе не
нужна? Из 10 человеко-часов вполне можно выделить 1 на нечто, не относящееся
непосредственно к пайке и кодированию (а в действительности и больше). Почему
этот 1 час нельзя потратить на практическое применение методик, нарабатываемых
больше 30 лет во всем мире, и около 7-8 лет непосредственно у нас?


Re: _Loader_
Hello Alex!

06 Oct 03 05:28, Alex Kouznetsov wrote to Power User:


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

Ага: на асме пишет человек, криво, а компилятор пишет сам по себе,
оптимизирующе. Человеконезависимо, машинный разум.

[...]
 AK> То есть, "самопал на асме", скорей всего, будет "большой каракатицей"
 AK> и "кривым угробищем".

А можно уточнить критерий "достаточна большая" и источник аргументации данного
высказывания? Типа "это сказали Вася и Петя, а Маша их поддержала" не
представляет практического интереса. И, попутно, расшифровку "каракатиц" и
"угробищ". А то ведь почитаешь подобное, и слегка прифигеешь...



73 & Cheerio!   Andy.

_Loader_
Mon Oct 06 2003 23:19, Andy Chernyshenko wrote to Alex Kouznetsov:

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

 AC> Ага: на асме пишет человек, криво, а компилятор пишет сам по себе,
 AC> оптимизирующе. Человеконезависимо, машинный разум.

Здесь АК прав. Человек не в состоянии держать слишком много сущностей
в голове одновременно, в отличие от компилятора. Hапример, какие переменные
где на стеке аллокированы, у каких переменных области видимости
не перекрываются, экзотические виды адресации и т.п. Hо в любом случае это
будут не разы.

WBR, Юрий.


_Loader_
Hello Yuriy!

07 Oct 03 01:39, Yuriy K wrote to Andy Chernyshenko:

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

 AC>> Ага: на асме пишет человек, криво, а компилятор пишет сам по
 AC>> себе, оптимизирующе. Человеконезависимо, машинный разум.

 YK> Здесь АК прав. Человек не в состоянии держать слишком много сущностей
 YK> в голове одновременно, в отличие от компилятора. Hапример, какие
 YK> переменные где на стеке аллокированы, у каких переменных области
 YK> видимости не перекрываются, экзотические виды адресации и т.п. Hо в
 YK> любом случае это будут не разы.

С какого момента становится предпочтительным ЯВУ - решать только и
исключительно автору проекта (случай дерективного назначения не рассматриваем).
И тем не менее высказывания "не сможет" и "не в состоянии" - ваши фантазии.
Сможет и в состоянии, вопрос только во времени и целесообразности. Иными
словами, крайности типа "обязательно" рекомендуется заменить на "желательно" -
так будет гораздо правдоподобнее, IMHO.



73 & Cheerio!   Andy.

Site Timeline