_Loader_

Hi Oleksandr,

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

OR> Я ещё не слышал, что после хорошего С-компилятора программа для OR> AVR|MCS51|PIC|MSP430 работает быстрее, чем написанная на ассемблере.

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

Граница, на которой человек "сломается", и на "голом" ассемблере уступит хорошему оптимизирующему компилятору, для каждого человека своя, но для каждого она существует, имхо. Поэтому я не стал бы разделять выч. технику по принципу "два мира - две системы", с моей точки зрения, то, что верно для пней (вроде бы все согласились, что для пней это верно?), _вообще_говоря_ не теряет своей силы даже небольших процев. То есть, всегда можно найти человека, который даже сравнительно небольшую программу на ассемблере напишет хуже чем то, что выдаст хороший оптимизирующий компилятор ;-)

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

OR> ассемблерррррррщиков, котороые ведут себя как форррррррррррррррртеры

Я вот все решить не могу, как правильнее называть тех, кто все без исключения пишет на Си: наСильщик или наСильник? ;-)

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

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 симметричных регистра, и добавим к ним пятый. Можно ли навскидку сказать, каким будет повышение производительности кода от такого добавления, как именно нужно изменить компилятор и для каких задач добавление пятого регистра вообще актуально?

Fri Oct 03 2003 23:14, Artem Kamburov wrote to Roman Khvatov:

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

"Под Си"... хммм... не знаю, есть регистровые архитектуры и есть стековые. "Под Си", имхо, понятие несколько другого уровня.

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

В ПЛИС - уже :) Суперскаляру там делать явно нечего - не те ресурсы. А вот форт-процессор(ы) там чувствуют себя прекрасно.

Fri Oct 03 2003 22:41, Dima Orlov wrote to Artem Kamburov:

DO> Вообще-то тут обсуждаются преимущественно микроконтролеры, а не DO> персоналки. Для персоналок писать на форте в голову никому не приходит DO> слава богу.

Приходит. Но это штучные проекты. Говорить о массовости применения Форта нельзя, как, например, о массовости применения Пролога в эхотаге. Но не знать Форт, хотя бы теоретически, вряд ли чересчур полезно для эмбедщика.

DO> Думаю, что ни к чему, да и массовостью Атмелу не приходится хвастаться. DO> Это не Моторола, не Микрочип и даже не ST. Впрочем для четырехбитных DO> процессоров может форт и даст приемлимый результат, говорить о DO> производительности тут явно не приходится.

Не скажу про ASIC, а в ПЛИС Форт-процессору самое место. От 8 до 32 разрядов, производительность вполне приемлемая для эмбеддед.

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

DO> Есть там компилятор с языка Форт.

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

(скипнул многое, с чем в принципе согласен)

Hi Roman,

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

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

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

Ссылочку не дашь, где про это можно прочитать?

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

На

я почему-то нигде не нашел прямого указания на то, что он суперскалярный проц. Они его называют CMT: These chip multithreading (CMT) processors are designed to execute tens of threads simultaneously, a sharp contrast to the single thread processed at a time by todays typical processors. Это концепция существенно отличается от суперскалярных VLIW пней, которые "нахапывают" сразу много команд в одном треде, а потом "распихивают" эти команды для параллельного исполнения в независимые блоки своего ЦПУ.

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

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

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

Ты ничего не путаешь, разве PicoJava - это суперскаляр, расходующий столько же кремния как UltraSparc II (5.4 млн транзисторов, если не ошибаюсь)? Насколько я знаю, это сравнительно маленький проц (примерно такого же класса как ARM), заточенный на встраиваемые применения:

I and II are licensable cores, which can be integrated with the application specific I/O functions to design a complete embedded processor that is ideally suited for Internet Information Appliances such as:

-- Digital set-top boxes

-- Internet TVs

-- Internet screen phones

-- Automotive communications devices

Поэтому сравнивать его производительность с UltraSparc II, предназначенным для WorkStations, по крайней мере странно, это примерно то же что AVR сравнивать с пнем. Еще более странно делать какие-то выводы на основе такого сравнения.

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

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

Есть такие чипы Нейрон, выпускаемые уже десятка полтора лет. Они являются основой сети LonWorks фирмы Echelon. Так вот, они сделаны именно так: это

8-битный стековый процессор, который за полный цикл (6 тактов) исполняет 3 независимых команды, по 2 такта на каждую. Сделано это было именно с той же целью, к которой сейчас стремится Sun: Нейрон исполняет 3 совершенно независимых задачи одновременно, в каждом командном цикле исполняя по одной команде для каждой из трех задач.

Эшелон с понтом вешает лапшу на уши, что внутри Нейрона 3 процессора, на на самом деле процессор один, за полный цикл просто 3 раза переключаются указатели стеков. Поскольку стековому процессору не надо сохранять контекст, то такое переключение не требует времени. Затраты аппаратуры на 3 набора указателей стеков и мультиплексоры для их переключения мизерны и даже просто смехотворны на фоне остальной аппаратуры ЦПУ. Так что не надо пургу гнать ;-)

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

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 - будет Си. И т.д.

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

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