_Loader_ - Page 9

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

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

Quoted text here. Click to load it

ЧИТАЙ - на нем НЕЛЬЗЯ написать вирус. Он БЕЗОПАСЕН! Обычная игра словами для
обычных пользователей, для которых программа (или скрипт) в текстовом документе
ассоциируется с ВИРУСОМ (MS постарался :-\).

Quoted text here. Click to load it

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

                      АртемКАД



Re: _Loader_
  Привет!

Sun, 19 Oct 2003 21:01:52 +0000 (UTC), Artem Kamburov писал:

...

Quoted text here. Click to load it

Нет, читай то, что написано, без фантазий. На нём нельзя писать
программы. Это не язык программирования с точки зрения его
разработчика.

Quoted text here. Click to load it

А это и есть единственное и неповторимие его отличия от оных -- он не
язык программирования. PDF может быть получем из PS лишь одним
способом: исполнением программы на PS и сборкой результирующих команд
вывода.

Quoted text here. Click to load it

Ищи. Наверняка найдёшь функции Type 4 и будешь кричать: "Вот
арифметика, да ещё основанная на стековой модели...". Но лично я, даже
абстрактно от прямого указания разработчика, не могу признать языком
программирования средство имеющее статическую модель данных и лишённую
управляющих конструкций. Если же принять за истину, что любой список
является программой, значит программой является и простой ASCII-файл,
а писатель -- программист на языке ASCII.

Quoted text here. Click to load it

Остальное -- PDF не производное от Форт никоим боком.

Александр Голов, Москва, Alex.Nippel@mtu-net.ru

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

Quoted text here. Click to load it

А как твой текстовый редактор покажет графику 8-? И что с того, что там стоит не
ссылка на картинку, а она сама?

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Открываю толковый словарь (давно пора)

Алгоритмический язык- знаковая система для представления алгоритмов.

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

Язык программирования - искусственный язык для представления программ

Программа - план действий, подлежащих выполнению некоторым исполнителем -
человеком или автоматом. 2. см. АЛГОРИТМ. 3. Алгоритм, записанный на некотором
алгоритмическом языке....


И что не позволяет назвать текст, записанный в PDF программой, а сам язык
алгоритмическим?

                                АртемКАД



_Loader_
Sat Oct 18 2003 19:03, Vladislav Baliasov wrote to Dima Orlov:


 >>> Мне лень перебивать в голдед несколько страниц текста, посвященной
 >>> описанию набора символов языка описания страниц PDF, но в

 DO>> И не надо, достаточно открыть pdf любым текстовым вьювером, чтобы
 DO>> увидеть, что это не текст,

 VB> В самом деле ? А, между прочим, немало .pdf - самый натуральный текст,
 VB> директивы и включения данных в ASCII85. Идиотский какой-то аргумент...

 Лирическое отступление:

 Когда человеку 10 лет, то очень ценным качеством кажется умение
 громко свистеть. Позднее к списку воображаемых достоинств добавляются
 умения пить, курить, программировать на Форте и.т.д.
 И лишь в зрелости доходит (да и то не до всех), что значение имеют
 достигнутые результаты, а не мелкие технические детали.
 В результате идиотский спор ни о чем уехавших и оставшихся неудачников,
 у которых в жизни ничего нет, не было и не будет кроме ремесла, и которые
 пытаются доказать сами себе, что жизнь прошла недаром.
 Какая на хрен разница, что на чем написано и как работает, если оно
 работает.
 
 VLV

  

"Oпасно отнимать у человека его заблуждения" (c) Шерлок Холмс


_Loader_
Hello Dima.

18 Oct 03 15:24, you wrote to me:

 >>  DO> И какой у этого "языка" набор символов?
 >> Мне лень перебивать в голдед несколько страниц текста, посвященной
 >> описанию набора символов языка описания страниц PDF, но в
 DO> И не надо, достаточно открыть pdf любым текстовым вьювером, чтобы
 DO> увидеть, что это не текст, а значит и не программа на языке
 DO> программирования в общепринятом понимании этого.

Только потому, что PDF допускает сжатие текста. Любой нечитаемый в текстовом
редакторе PDF можно распаковать в обычный текст.

PDF, конечно, не язык програмирования, а язык описания страниц. Так его и Adobe
называет. В нем, насколько я помню, уже нет стековой машины, но тем не менее
это
язык, со своим синтаксисом и правилами.

Alexey


_Loader_
Hello, Alexey Boyko !

 >>>  DO> И какой у этого "языка" набор символов?
 >>> Мне лень перебивать в голдед несколько страниц текста, посвященной
 >>> описанию набора символов языка описания страниц PDF, но в

 >  DO> И не надо, достаточно открыть pdf любым текстовым вьювером, чтобы
 >  DO> увидеть, что это не текст, а значит и не программа на языке
 >  DO> программирования в общепринятом понимании этого.

 > Только потому, что PDF допускает сжатие текста. Любой нечитаемый в
 > текстовом редакторе PDF можно распаковать в обычный текст.

Да не важно только или не только. Важно, что это не текст на языке, а двоичные
данные.

 > PDF, конечно, не язык програмирования, а язык описания страниц.

Это формат.

 > Так его и Adobe называет.

Adobe его называет форматом. Вот HTML - язык разметки страниц.


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


Re: _Loader_
Hello, Arcady Schekochikhin !

 >>  >>  Hаиболее удобно - когда программатор умеет и так и так.
 >>
 >>  > Так нехай желающие напишут самый распрекрасный ГУЙ - что может
 >>
 >> А если желающие не умеют писать ГУЙ?

 > Как ты любишь говорить - пусть они ценят свое многотысячебаксовое
 > рабочее время и
 > ОПЛАТЯТ умеющему человеку его написание. Hу или пусть научатся

Они скорее купят готовый программатор с уже написанным ГУЙем


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


Re: _Loader_
Hello, Artem Kamburov !

 >  Единственная загвоздка в том, что эмулятор купленный  за ....
 > баксов этот параметр указанный в datasheet-ах не эмулирует :(.

Можно конкретики по-больше? Какой именно эмулятор чего именно не эмулрует?

 > Так, что мой совет - проводите отладку на реальных деталях.
 > Кстати, в последних моделях процессоров появился встроенный отладчик :).

Твой совет - это то, как не надо делать. Устройство должно не работать на
_реальных_ деталях, а работать со всем возможным расбросом (плюс запас) их
параметров.

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


Re: _Loader_
Hello, Artem Kamburov !
 > А по поводу того, что Алголоподобных языков много, а Форт один -
 > так диалектов Форта то-же много.

И все они - дерьмо.

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


Re: _Loader_
Hello Ilia.

11 Oct 03 01:13, you wrote to me:

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

 IT> Кстати, JCXZ ведь прилично способствует уменьшению числа тактов? А
 IT> более мощные варианты аппаратной реализации команд цикла?

Угу, только у компиляторов начинаются проблемы с восстановлением структур
циклов _задолго_ до выхода на уровень кодогенерации.
Разложить уже оптимизированный цикл в команды типа JCXZ проблем не представляет
:)

 IT>  Что касается простоты/сложности оптимизации, то тут очень много
 IT> привходящих факторов. Hапример, что можно сказать о системе команд,
 IT> которая наиболее полно "прилегает" к типичным операциям абстрактной
 IT> вычислительной машины, решающей задачу?

Система команд тут не при чем - эти оптимизации делаются на уровне
промежуточного представления front-end'а и оптимизатора. А он обычно очень
далек от системы команд целевого процессора.

 RK>> Какие например? Даже на Форт процессор можно поставить нормальный
 RK>> С компилятор, с точки зрения сопровождаемости и читаемости
 RK>> программ это будет лучше, чем Форт (кстати, возможно и
 RK>> эффективность будет больше - за счет большего количества
 RK>> оптимизаций, которые сможет сделать компилятор С)

 IT> Hу слава богу, добрались наконец-то до такого вывода!!! :)))) Да,
 IT> полностью согласен. Именно так и работаем сейчас. Только Си - это
 IT> частный случай... хотя почему бы и не он?

Я имел в виду любой класический процедурный язык, так что 'почему бы и не С' :)

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

 IT> Абсолютно не кажется! :) Их именно потому и целый выводок, что отличия
 IT> косметические - в синтаксисе конструкций.

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

 IT> Обобщая Си, паскаль, ну и фортран с бейсиком, можно поставить им в
 IT> соответствие одну (практически) БHФ. У пролога и лиспа (у каждого),
 IT> очевидно, грамматика другая...

Однако, диалектов и производных того же лиспа не меньше, чем С с сотоварищами
:)

 RK>> Да ну? Я до сих пор считал, что это язык описания логических
 RK>> систем. К математике он некоторое отношение имеет, но не большее,
 RK>> чем например С

 IT> HDL вобщем-то собирательное название для "Hardware Description
 IT> Languages". Так что это все же "язык описания аппаратуры". Причем
 IT> конкретные трансляторы, скажем, VHDL, позволяют описывать
 IT> электрические соединения на уровне обычных переменных и взаимосвязей
 IT> между ними.

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

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

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

Вполне нормальный подход.

 RK>> 2 такта, для 1го такта нужна 3х портовая память. Кстати, а как
 RK>> этот вопрос рещается для стека - ему же тоже надо прочесть 2
 RK>> значения и записать одно и все в одном такте?

 IT> Тут много схемотехнических решений, специфичных для конкретных
 IT> архитектур ПЛИС. Вкратце могу сказать, что это делается,

Интересно, а как?

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

 IT> Синтаксический анализатор - слова FIND и NUMBER (или есть в словаре,
 IT> или нет, но это число).

Это не синтаксический анализатор - это всего навсего управление таблицей
символов (оно есть и в обычных компиляторах)

 IT> Семантический есть, например, у "закрывающих" слов из конструкций
 IT> управления. THEN без IF - тоже возможная ошибка, прекрасно
 IT> отслеживаемая анализатором.

Это отслеживает не анализатор (которого нет), а сами слова. Так что
контролируемая часть довольно мала :(

 RK>> Вывод: использовать Форт как пособие по построению компиляторов
 RK>> не стоит - компиляторы так не строятся.

 IT> Компиляторы Си-подобных языков действительно так не строятся :)

Hикакие (кроме самого Форта) так не строятся.

 IT> Форт имеет смысл использовать лишь как пособие по построению
 IT> _какого-нибудь_ компилятора,

_какого-нибудь_, а одного, вполне конкретного :)

 IT> поскольку самостоятельные поделки
 IT> интерпретаторов байт-кода и самопальных целевых языков частенько
 IT> имеют некорректности просто в грамматике.

Hу не настолько все плохо :)

 IT> Форт по крайней мере является завершенным языком для стековой машины,
 IT> и многие вещи в нем не вполне тривиальны.

Ага, и не вполне понятны стороннему наблюдателю :)

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

Можно, можно на С написать Форт, но надо ли? Если нужен интерпретатор, то есть
довольно много готовых.

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

Так просили интерпретатор - вот вам интерпретатор :)

Roman


_Loader_
Sat Oct 11 2003 23:03, Roman Khvatov wrote to Ilia Tarasov:

 IT>> Кстати, JCXZ ведь прилично способствует уменьшению числа тактов? А
 IT>> более мощные варианты аппаратной реализации команд цикла?

 RK> Угу, только у компиляторов начинаются проблемы с восстановлением структур
 RK> циклов _задолго_ до выхода на уровень кодогенерации.
 RK> Разложить уже оптимизированный цикл в команды типа JCXZ проблем не
 RK> представляет :)

А прямое соответствие конструкций высокого уровня машинному коду не лучше?
Зачем все-таки мучаться с ассемблером, далеким от потребностей прикладного
программиста?

 RK> Система команд тут не при чем - эти оптимизации делаются на уровне
 RK> промежуточного представления front-end'а и оптимизатора. А он обычно
 RK> очень далек от системы команд целевого процессора.

...... !!!!!!!!! (См. выше)

 IT>> Hу слава богу, добрались наконец-то до такого вывода!!! :)))) Да,
 IT>> полностью согласен. Именно так и работаем сейчас. Только Си - это
 IT>> частный случай... хотя почему бы и не он?

 RK> Я имел в виду любой класический процедурный язык, так что 'почему бы и не
 RK> С' :)

Именно о "любом классическом процедурном языке" и речь! :) Возможно, также и о
чем-нибудь функциональном, в некоторых пределах. Вобщем, с грамматикой-то
можно обращаться уже довольно свободно, гораздо свободнее, чем при наличии
ассемблера или Си.

 IT>> Абсолютно не кажется! :) Их именно потому и целый выводок, что отличия
 IT>> косметические - в синтаксисе конструкций.

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

Почему не построили? Были производные, надо на forth.org.ru архивы новостей
посмотреть. Впрочем, новая реализация Форта вполне может рассматриваться как
производная. Стековая машина и есть стековая машина - от нее много производных
не построишь. А производные от процедурных языков различаются в основном
синтаксисом и иногда системой типов.

 IT>> HDL вобщем-то собирательное название для "Hardware Description
 IT>> Languages". Так что это все же "язык описания аппаратуры". Причем
 IT>> конкретные трансляторы, скажем, VHDL, позволяют описывать
 IT>> электрические соединения на уровне обычных переменных и взаимосвязей
 IT>> между ними.

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

А что там особенно специфичного? Что переменные привязываются к аппаратным
ресурсам? Выражения-то все равно математические. И управляющие конструкции
очень схожи с конструкциями ЯВУ.

 IT>> Тут много схемотехнических решений, специфичных для конкретных
 IT>> архитектур ПЛИС. Вкратце могу сказать, что это делается,

 RK> Интересно, а как?

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

 IT>> Синтаксический анализатор - слова FIND и NUMBER (или есть в словаре,
 IT>> или нет, но это число).

 RK> Это не синтаксический анализатор - это всего навсего управление таблицей
 RK> символов (оно есть и в обычных компиляторах)

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

 IT>> Семантический есть, например, у "закрывающих" слов из конструкций
 IT>> управления. THEN без IF - тоже возможная ошибка, прекрасно
 IT>> отслеживаемая анализатором.

 RK> Это отслеживает не анализатор (которого нет), а сами слова. Так что
 RK> контролируемая часть довольно мала :(

Хотя у этой собачки и коротенькие лапки, до пола они все же достают... :)))
Это действительно не анализатор, но то, что _исполняет его функцию_. Разве не
изящно - не просматривать весь текст в поисках закрывающего then для этого if,
а дать возможность конструкции самой проконтролировать себя на корректность.
case , например, пишется на самом Форте (800 байт текста), причем его
поддержка в базовом словаре не требуется!

 IT>> поскольку самостоятельные поделки
 IT>> интерпретаторов байт-кода и самопальных целевых языков частенько
 IT>> имеют некорректности просто в грамматике.

 RK> Hу не настолько все плохо :)

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

 IT>> Форт по крайней мере является завершенным языком для стековой машины,
 IT>> и многие вещи в нем не вполне тривиальны.

 RK> Ага, и не вполне понятны стороннему наблюдателю :)

Например?

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

 RK> Можно, можно на С написать Форт, но надо ли? Если нужен интерпретатор, то
 RK> есть довольно много готовых.

Просто для интереса - сколько работают в DPMI в нулевом кольце? И сколько из
них позволяют делать ассемблерные вставки в нативном 32-битном коде, а также
пользоваться SVGA-графикой и делать POSIX-овые вызовы? Когда я начал писать
свой транслятор, требования были именно такие. Тогда я ничего не нашел, хотя и
спрашивал. А сейчас что-то вдруг все заохали...

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

 RK> Так просили интерпретатор - вот вам интерпретатор :)

Так почему он по своим свойствам так похож на Форт? :) Причем люди обычно были
свято убеждены, что все эти подходы они вот прямо тут в результате дискуссии и
открыли, интуитивно! :))))
Имеющиеся наработки по Форту, кстати, позволяют достаточно аккуратно обойти
некоторые тонкие подводные камни. Наконец, Форт компилирует!!! А на что может
быть похоже поделие на Си, у которого да хотя бы таблица символов обычно либо
маленькая и статическая, либо динамические выделяемая и дико медленная? Это я
пытался давать людям попробовать, потом плюнул, написал руководство по Форту и
распечатал в нескольких экземплярах. Ничего, работают люди...


_Loader_
Sat Oct 11 2003 23:03, Roman Khvatov wrote to Ilia Tarasov:

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

Возможно, ты просто не в курсе, однако могу уверенно предположить, что сам ты
постоянно пользуешься ими, или, вернее, продуктами на основе "Форт-подобных
языков":
-- PostScript
-- PDF

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


Re: _Loader_
Hello, Ilia Tarasov !

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

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

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

Причем тут embedded?

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


Re: _Loader_
Hello, Ilia Tarasov !
 > процессору, который будет поставлен в экспериментальную установку
 > (которая в единичном экземпляре и не на продажу, так что деньги
 > не вернутся).

 > генерации кода? Потому что эмбедщикам, ждущим, пока им принесут
 > Evaluation Kit с компилятором, будет обидно, что их не позвали?

Hет, не будет. Зачем тратить силы на то, деньги за что не вернутся?

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


Re: _Loader_

Quoted text here. Click to load it

ВСЕ персоналки работающие под свежим FreeBSD имеют внутри себя форт-часть - а
именно -
вторичный загрузчик.

Аркадий

Re: _Loader_
3-Oct-03 22:41 Dima Orlov wrote to Artem Kamburov:

Quoted text here. Click to load it

DO> Вообще-то тут обсуждаются преимущественно микроконтролеры, а не персоналки.
DO> Для
DO> персоналок писать на форте в голову никому не приходит слава богу.
 Ну почему.
 Как минимум Eserv и Edial или как там его. Впрочем, их автор не замечен
мной в фоРРРРРРРРРРРРРРРРРтерстве в дургих эхах.

Quoted text here. Click to load it

2AK
 Если кто-то узнал о шитом коде только при чтении книг по форту,
то это ещё не означает, что шитый код появился после появления форта
и что любоё шитый код есть "эмуляция поведения форта".

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


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

Quoted text here. Click to load it

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

Quoted text here. Click to load it
Для
Quoted text here. Click to load it

Я пишу (иногда надо заставить Win нечто сделать, а вести позиционную войну с
С++ - нет времени). Для МК использую асм (целевой Форт могу сделать, но руки не
доходят :-)).

Quoted text here. Click to load it

Фотография платы мобилки с T48C894, что он там делал сказать не могу. В машине -
держал в руках плату управления (система "комфорт" - управление светом,
стеклоподъемниками, приводами дверей...) с М44С510 в качестве процессора.

Quoted text here. Click to load it
может
Quoted text here. Click to load it

Странная какая-то массовость. Микроконтроллеров ST и Моторолы я в Украине вообще
не видел, а Микрочип кристаллы с теми-же ресурсами предлагает в полтора-два раза
дороже.

Quoted text here. Click to load it
значение.

Дык сравниваете современный Си с тогдашним Фортом.

Quoted text here. Click to load it

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

                                 АртемКАД






Re: _Loader_
5-Oct-03 10:40 Artem Kamburov wrote to Dima Orlov:

Quoted text here. Click to load it

AK> Я пишу (иногда надо заставить Win нечто сделать, а вести позиционную
AK> войну с
AK> С++ - нет времени). Для МК использую асм (целевой Форт могу сделать, но
AK> руки не доходят :-)).
 Вот именно!!! Отличный контраргумент на тему "им просто лень разобраться
в форте, вот они и жуют свой С".

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

- недоходимость рук на освоение форта до состояния "могущести сделать
 целевой компилятор".

- право для всех однокристалок "безо всех этих хлопот" писать на С

Так что

AAR> Date: Sat, 12 Feb 2000 11:42:09 +0200 (UKR)
AAR> Newsgroups: fido7.ru.algorithms
AAR> Subject: Re: срочно!!!

AP>> Hарод, вот тyт такая задачка: нyжно определить вес байта (количество
AP>> единичных битов)!
AAR> Достаточно реальная задача.
[...]
AAR> ===
AAR> Украинский, Русский, С - свободно, Английский, Pascal - читаю и
AAR> с трудом изъясняюсь, Forth -- читаю и перевожу СО СЛОВАРЕМ.

И так оно и будет.
  Тарасову проще напихать в ПЛИС кучку форт-процессоров (в том числе
на правах программируемых автоматов) и загрузить каждого своей задачей,
имея опыт построения целевых компиляторов ему проще и дешевле для MB90
или там чего ещё сделать целевой компилятор форта.
  Мне проще и дешевле поставить рядом с ПЛИС MCS51 или AVR-ку для общего
управления, а внутри напихать обычных автоматов (даже микропрограммные
пока не были нужны, жёстких хватает).
  Он кормится со своих решений, я -- со своих.
  Надеюсь (практически уверен), он никогда не скажет, что я "слишком туп
или ленив, чтобы освоить форт" (а от фоРРРтеров такие фразы
в адрес "обобщённого меня" я слышал, как и от c00l хацкеров про
необходимость всё писать на ассемблере). Я никогда не скажу, что он
маньяк с вывихнутыми мозгами или что ему нужен форт только для того,
чтобы выделиться, иметь возможность считать себя "круче" остальных.

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


Re: _Loader_
Sun Oct 05 2003 23:39, Oleksandr Redchuk wrote to "Artem Kamburov":

 OR>   Тарасову проще напихать в ПЛИС кучку форт-процессоров (в том числе
 OR> на правах программируемых автоматов) и загрузить каждого своей задачей,
 OR> имея опыт построения целевых компиляторов ему проще и дешевле для MB90
 OR> или там чего ещё сделать целевой компилятор форта.
 OR>   Мне проще и дешевле поставить рядом с ПЛИС MCS51 или AVR-ку для общего
 OR> управления, а внутри напихать обычных автоматов (даже микропрограммные
 OR> пока не были нужны, жёстких хватает).
 OR>   Он кормится со своих решений, я -- со своих.

Абсолютно согласен с изложенным подходом. Если речь о задачах, ложащихся на 51
или AVR, то и применяемые средства должны соответствовать. И незачем возиться
еще и с программным ядром, если задача настолько проста, что выписывается в
один process на VHDL. MB90 (16 бит + 16 МГц + 256 кб флеша) для моих задач -
система начального уровня... со всеми вытекающими. Я уже писал цифры: 16-32
разряда, 20-40 МГц, добавлю еще 25-50$ за ПЛИС. Вот сюда уже можно ставить
программное ядро, а 8-16 битные контроллеры и так прекрасно справляются с
возлагаемыми на них задачами, и писать можно хоть на асме, хоть на Си, хоть на
Паскале (и даже лучше - быстрее получится результат на основе библиотек из
стандартной поставки компилятора, с которым выпускается уже n-цатое изделие).

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

Разумеется, никогда не скажу. :) Каждому свое, и более того, умение выбрать
для изучения подходящий предмет - очень хорошее качество. Т.е.: изучать, если
надо... и не изучать, если не надо!

Жму руку... Редко попадается нормальная реакция.


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

Quoted text here. Click to load it

В принципе работаю на асме. Форт, Си - для ПК - побочная обязанность.

Quoted text here. Click to load it

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

Quoted text here. Click to load it


 Да пожалуйста. Я собственно тем и живу, что Вы (ну или "обобщённым Вы") пишите
на С. Иначе я не смог бы тягаться по себестоимости с Вашим массовым
производством :).

                        АртемКАД



Site Timeline