_Loader_

Sat Oct 04 2003 23:41, Vladimir Vassilevsky wrote to Ilia Tarasov:

IT>>>> Представим, что действительно все (ну или почти все) команды в IT>>>> исходном алгоритме зависимы по данным. RK>>> Так практически не бывает. IT>> y=sin(sqrt(abs(2*x))) Что здесь независимого?

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

Согласен, пример не совсем удачный ввиду особенностей технической реализации. Давай иначе: даны события (функции) f1 f2 f3 ... fn , переводящие некоторый конечный автомат в состояния S1 S2 S3 ... Sn соответственно. Пусть также дан граф, задающий порядок переходов вида:

S1 -> S2 -> S3 -> ... Sn

Вопрос (с очевидным ответом): можно ли выполнить редукцию такого графа?

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

VV> Запись/чтение памяти, продвижение указателей, проверку границ и условий.

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

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

Sat Oct 04 2003 23:41, Lev Serebryakov wrote to Dima Orlov:

LS> "10'000'000 не могут быть не правы". Я _не_ "за форт", я против "против LS> форта".

Поддерживаю! "Против форта" почему-то встречается чуть ли не чаще, чем "за форт по-фанатски".

Не менее очевидно, что затраты на разработку Форта по сравнению с затратами на разработку Си - также капля в море. Затраты на покупку Форта по сравнению с затратами на покупку Си - также обычно капля в море (трансляторы Форта бесплатны).

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

LS> Hо грамотный _программист_ должен обладать кругозором и постоянно его LS> поддерживать, а лучше расширять. Иначе это ремесленник. Почему-то никого LS> не удивляет, что надо читать кнута и Дийкстру, для тутошних тем -- LS> Хорвица и Хилла, но мало кто задумывается, что надо уметь и писать на LS> Лиспе, Форте, понимать про лямбда=-исчисление и грамматики, пусть и не LS> пользоватся этим постоянно.

Воистину! Кстати, помню флеймы по поводу Форта в su.softw и в ru.programming.languages. Там почему-то фортеров отсылали сюда, дескать, в эмбеддед Форту самое место :) Интересные были аргументы (кстати, многие из su.forth прилично расширили свой кругозор благодаря им), но почему-то подтекст был на уровне "у меня же нет Форта, чтобы было красиво, с оболочкой, объектно-ориентированного, .... , и чтобы в окошке можно было поставить галочку "оптимизировать"." Нечто похожее и сейчас проскальзывает - есть привычки, старые наработки, стереотипы. А тут какой-то Форт, который хоть тресни, а есть... :)))

Hi Roman,

Sat Oct 04 2003 21:36, Roman Khvatov wrote to Alex Kouznetsov:

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

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

А, ты вон про что, я сначала не понял.

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

Предположим, на определенном кол-ве вентилей можно сделать проц, реализующий тот или иной подход. Одна реализация - ПикоЖаба, другая - суперскалярный RISC. Померяли производительность, оказалось что ПикоЖаба отстает. Возникает законный вопрос - а лучше суперскалярного РИСКа ничего нельзя сделать на этих же вентилях? Второй вопрос - если вместо того чтобы пытаться сделать "суперскалярный стековый проц", я эти вентили потрачу на много маленьких Форт-процессоров, как это сделал Чак Мур в своем х25, проиграю я суперскалярному РИСКу, или наоборот?

AK>> Есть такие чипы Hейрон, выпускаемые уже десятка полтора лет. Они

RK> Ага. И за эти полтора десятка лет они не изменились? Или прогресс уже RK> остановился?

Как ни удивительно, не изменились. По крайней мере, я не в курсе изменений, по-моему сейчас они выпускаются Сайпрессом и Тошибой точно такими, какими выпускались когда-то Моторолой. Для меня это хороший знак: значит, они настолько добротно были сделаны изначально, что продолжают оставаться конкурентноспособными. В чем не последнюю роль сыграла их стековая архитектура, имхо.

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

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)

-- скорость (мои интерпретаторы работают быстрее)

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

Шитый код генерился DEC-овским Фортран-4 компилятором под RT-11 и RSX-11, так что все серьезные ПДП-исты с ним были вполне себе знакомы. Да и ФИГ-Форт на PDP-11 появился сильно до выхода Б-Н.

Аркадий

Любой, компилятор которого сделан, чтобы генерить шитый код. Шитый код не самоцель - это просто способ добиться какого то результата - например уменьшить объем объектной программы.

Аркадий

Нет - например втыканием дополнительной ПЗУ.

Передергиваешь. Это имеет отношение к новой виртуальной машине полученной перезагрузкой микрокода. Новые примитивы НЕ БУДУТ являться нативным кодом СТАРОЙ МАШИНЫ. В то же время старый нативный код будет частью данной новой машины. А мы сравниваем именно нативный код ИСХОДНОЙ машины с выполнением форт-программы на новой (полученной возможно на средствами форта). Если ты скажешь что это теперь тоже стало нативным кодом и .... - см. ниже.

Потому что на форт-машине "нативный код" ЭКВИВАЛЕНТЕН "форт-коду". Свойство такое.

Аркадий

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

Аркадий

Ты мне ссылочку кинь на разработанный тобой язык, проживший 30 лет и стандартизованный, тогда может я поверю что так делать НЕ НАДО.

Аркадий

Hi Artem,

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

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

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

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