Ассемблер PowerPC

Mishka> Человеческий мозг не справляется с оптимизациями на машином уровне.

В рамках большой программы в целом - да. На узкой частной задаче - нет. Компиляторы до сих пор нередко генерируют весьма посредственный код. Другое дело, что написать его на высокоуровневом языке с той же производительностью будет на пару порядков быстрее. Но если требуется экстремальная эффективность - тут любой компилятор пока ещё курит в сторонке. И, боюсь, ещё доолго будут курить. По крайней мере принципиальных подвижек в последние лет 10 я не вижу. Последние большие скачки эффективности компиляторов были где-то во времена Watcom 10 / MSVC4 А когда это было...

...

И, кстати, для RISC'ов сегодня ситуация с компиляторами даже хуже, чем с CISC. Очень уж много регистров Неоптимально обычно используются.

Mishka> Ау, перестань. Человеческий мозг не справляется с оптимизациями на машином уровне. Даже полного понимания работы системы нет ни у кого. Только у большой команды. Можешь поверить человеку, который эти процессоры разбирал по кирпичикам. У тебя каждая модификация процессора работает по разному! И настолько по разному, что любое сочетание команд может начать работать медленнее или быстрее на порядки. IBM само предлагает решать только конкретные небольшие проблемки, а не огромные проблемы.

Перестань что? Это не мой текст. Системы не падают с неба, их строят. Если их накрутили (как обычно), что никто не знает как они работают, то пинать можно только себя. То что автор сказал — просто и доходчиво: когда ты пишешь для машины, ты знаешь буквально что она будет делать. А когда пишешь virtual void far, то никто не знает чем это кончится для машины. Компиляторы вроде мысли не читают, и задача у них скомпилировать чтобы работало. Я знаю что разные процессоры работают по разному. Применительно к себе скажу, что запущенные архитектуры я вообще не рассматриваю. Этот клубок пусть распутывают те, для кого он был спутан. Что касается больших проблем и больших команд, есть проверенные методы и опыт как надо и как не надо. Любая самая сложная проблема раскладывается на самые простые — процессор именно с такими и работает: отнять, разделить, и т.п. Если кто-то делает иначе, и получается иначе, то это чужие проблемы. На фоне моря разных решений всегда можно найти правильные. Как свежий пример, помню одну из машин в гонке через пустыню. Народ там решил сделать всё руками, у них мощный DSP программировался на ассемблере, разбирал видеосигнал и пытался рулить машиной. Ещё был пример на eeTimes, когда небольшая фирма за год слепила какую-то сложную диагностическую систему для трансокеанского волокна. Они поступили грамотно и неординарно: в их системе десятки процев, каждый работает с небольшой задачей (задачи все разные). Они сдали систему через год, в разы раньше чем положено для такой задачи, и потом их некоторые пинали за этот подход, типа "да шо ж это деется, ты ж понимаш, полсотни разных процев с разными прогами, да ещё всё работает".

Dem_anywhere> Вопрос в том, на что рассчитан встроенный в проц оптимизатор исполнения - на "посредственный код" компилера или "эффективный" ручной...

Вопрос не с той стороны задан Ибо и компилятор, и "эффективный ручной" метод - оба будут ориентироваться на тот оптимизатор, что есть

Balancer> В рамках большой программы в целом - да. На узкой частной задаче - нет.

И на узкой задаче — тоже. У человеческого мозга уж очень узки эти рамки.

Balancer> Компиляторы до сих пор нередко генерируют весьма посредственный код.

Какие компиляторы? Сейчас оптимизирующих очень мало. Хочешь хороший — купи у интела для x86.

Balancer> Другое дело, что написать его на высокоуровневом языке с той же производительностью будет на пару порядков быстрее. Но если требуется экстремальная эффективность - тут любой компилятор пока ещё курит в сторонке. И, боюсь, ещё доолго будут курить.

Только если кода не более нескольких десятков тысяч ассемблерных команд. Это будет пару тысяч строк кода на АЯВУ. Дальше — тапки.

Balancer> По крайней мере принципиальных подвижек в последние лет 10 я не вижу. Последние большие скачки эффективности компиляторов были где-то во времена Watcom 10 / MSVC4 А когда это было...

Посмотри на Интел, посмотри на французов. Не знаю, есть ли ещё люди в Новосибирске.

Balancer> ...
Balancer> И, кстати, для RISC'ов сегодня ситуация с компиляторами даже хуже, чем с CISC. Очень уж много регистров Неоптимально обычно используются.

В точности наоборот. Наличие большого количества регистров одного типа позволяет такие оптимизации заворачивать. Подсчёт использования глобальных переменных ведётся намного проще. Индуктивные переменные — на ура. Размещение локальных переменных на регистрах — милое дело.

au> Перестань что?

Тащить всякую каку в рот.

au> Это не мой текст. Системы не падают с неба, их строят. Если их накрутили (как обычно), что никто не знает как они работают, то пинать можно только себя. То что автор сказал — просто и доходчиво: когда ты пишешь для машины, ты знаешь буквально что она будет делать.

Не надо читать между строк. Поговори с автором. Почитай другие его работы или их отдела. Ты никогда буквально не знаешь, что она будет делать. Этого не знает никто. Есть некоторая модель, которая весьма далека от действительности очень часто.

au> А когда пишешь virtual void far, то никто не знает чем это кончится для машины. Компиляторы вроде мысли не читают, и задача у них скомпилировать чтобы работало.

Ещё как читают. В оптимизирующих системах смотрится то, как это будет использоваться. С++ не очень хорош для этого, а вот всякие Модулы-2 и Алголы 68 с Адами — очень часто даже способствуют. Там чичтемы программирования хранят в качестве заголовка процедуры, пакета, яйца и набор регистров, которые она использует — для дальнейшей оптимизации на шаге линковки.

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

Поговори, хотя бы с Серокоем, чтобы убедится, что ты не прав на сегодняшний день.

au> отнять, разделить, и т.п. Если кто-то делает иначе, и получается иначе, то это чужие проблемы. На фоне моря разных решений всегда можно найти правильные. Как свежий пример, помню одну из машин в гонке через пустыню. Народ там решил сделать всё руками, у них мощный DSP программировался на ассемблере, разбирал видеосигнал и пытался рулить машиной. Ещё был пример на eeTimes, когда небольшая фирма за год слепила какую-то сложную диагностическую систему для трансокеанского волокна. Они поступили грамотно и неординарно: в их системе десятки процев, каждый работает с небольшой задачей (задачи все разные). Они сдали систему через год, в разы раньше чем положено для такой задачи, и потом их некоторые пинали за этот подход, типа "да шо ж это деется, ты ж понимаш, полсотни разных процев с разными прогами, да ещё всё работает".

Да там не всё работало. И любое изменение у них занимало тот же год.

Mishka> Только если кода не более нескольких десятков тысяч ассемблерных команд. Это будет пару тысяч строк кода на АЯВУ. Дальше — тапки.

Я же писал про временнЫе затраты, которые различаются на пару порядков. Можно на ассемблере написать оптимальный большой код. Целый проект. Но времени на его написание уйдёт столько, что - тапки

Mishka> Тащить всякую каку в рот.

Я говорю о том что знаю.

Mishka> Не надо читать между строк. Поговори с автором. Почитай другие его работы или их отдела. Ты никогда буквально не знаешь, что она будет делать. Этого не знает никто. Есть некоторая модель, которая весьма далека от действительности очень часто.

Я читал одного гуру по встроенному софту. Читал просто в удовольствие. Железно нужно знать и понимать (от транзисторов до вычислительных архитектур), и тогда оно будет интуитивно понятно при программировании.

Mishka> Ещё как читают. В оптимизирующих системах смотрится то, как это будет использоваться. С++ не очень хорош для этого, а вот всякие Модулы-2 и Алголы 68 с Адами — очень часто даже способствуют. Там чичтемы программирования хранят в качестве заголовка процедуры, пакета, яйца и набор регистров, которые она использует — для дальнейшей оптимизации на шаге линковки.

Это конечно хорошо, но это же пшик на фоне С++. Почти незаметный пшик. Я написал что всегда есть что-то сделанное руками, хотя в основном всё делается ногами и копытами.

Mishka> Поговори, хотя бы с Серокоем, чтобы убедится, что ты не прав на сегодняшний день.

Да ладно, чего там спорить — скорее всего о разных вещах говорим.

Mishka> Да там не всё работало. И любое изменение у них занимало тот же год.

Я написал про два конкретных проекта. Один отъездил в срок, другой был сдан в срок. О чём ты, какой ещё "год"?
Ссылок сейчас не найду уже.

Balancer> Я же писал про временнЫе затраты, которые различаются на пару порядков. Можно на ассемблере написать оптимальный большой код. Целый проект. Но времени на его написание уйдёт столько, что - тапки

Гораздо хужее. Я читал код, который из той школы, что ау привёл статью. Есть у IBM некоторые OS, которые написаны на ассемблере, включая OS/360 и VM/SP и некоторые другие. Скажем, VM/SP написана именно грамотными ребятами. И оптимизация там для CP сделана очень знатная. Местами. Но это маленький кусочек в ней. А всё остальное по жёской дисциплине — оформление стека вызова, локальных переменных, обязательные регистры при передаче данных, обязательные регистры при возврате. В общем, всё то, что делает компилятор. Цель единственная — выдать и не наплутать в коде. Можешь себе представить, что компилятор эти вещи делает лучше.

Добрый день.Мне нужно написать программу на assembler для ppc405gpr.Подскажите пожалуйста как это сделать ( в каком
редакторе) и как можно прочесть уже готовый код.Заранее благодарен тем кто мне сможет помочь.

Dima71> Добрый день.Мне нужно написать программу на assembler для ppc405gpr.Подскажите пожалуйста как это сделать ( в каком

В любом текстовом.

Dima71> редакторе) и как можно прочесть уже готовый код.Заранее благодарен тем кто мне сможет помочь.

Тем же редактором. Т.е. вопрос не очень понятен. Программка на ассемблере — это обычный текст.

Dima71>> редакторе) и как можно прочесть уже готовый код.Заранее благодарен тем кто мне сможет помочь.
Mishka> Тем же редактором. Т.е. вопрос не очень понятен. Программка на ассемблере — это обычный текст.

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

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


Спасибо за ответ.Вы совершенно правильно меня поняли.Мне нужен редактор в котором бы я мог писать программы на ассемблер и читать уже готовые (дизассемблировать).
Спасибо.

Dima71> Спасибо за ответ.Вы совершенно правильно меня поняли.Мне нужен редактор в котором бы я мог писать программы на ассемблер и читать уже готовые (дизассемблировать).
Так редактор тут абсолютно не причём.
Вам нужен сам (кросс-)ассемблер.

См. "cross tools powerpc", "powerpc assembler tools" или нечто подобное в гугле.
Интегрированые среды разработки именно для ассемблера ППЦ вряд ли существуют.

Татарин> Интегрированые среды разработки именно для ассемблера ППЦ вряд ли существуют.

Eclipse в качестве редактора и binutils собрать под PPC? Я так поступал для ARM, нормально работало.

Серокой> Eclipse в качестве редактора и binutils собрать под PPC? Я так поступал для ARM, нормально работало.

Интересно, а где этот PPC расположен? И что там за ОС? Т.е. не всегда эти ребята там будут работать...



КоординаторDima71> Спасибо за ответ.Вы совершенно правильно меня поняли.Мне нужен редактор в котором бы я мог писать программы на ассемблер и читать уже готовые (дизассемблировать).


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

Поэтому следующий вопрос — а на фига это всё надо?

Mishka> Интересно, а где этот PPC расположен? И что там за ОС? Т.е. не всегда эти ребята там будут работать...

Этот РРС 405 расположен на разных платах которые мне приходится ремонтировать.ОС на даном этапе не имеет значение.Ассемблер мне нужен чтобы написать простые тесты-например для памяти с которой работает РРС.РРС должен загружаться именно с этой тестовой программы которую я хочу написать.Так что если кто-то знает где можно скачать ассемблер для даного РРС пусть ответит мне.Заранее благодарен.

Dima71> Этот РРС 405 расположен на разных платах которые мне приходится ремонтировать.ОС на даном этапе не имеет значение.Ассемблер мне нужен чтобы написать простые тесты-например для памяти с которой работает РРС.РРС должен загружаться именно с этой тестовой программы которую я хочу написать.Так что если кто-то знает где можно скачать ассемблер для даного РРС пусть ответит мне.Заранее благодарен.

То что вы хотите нужно искать в разделе инструментов для разработки у контор, которые это ядро используют. У вас модель разработки firmware как для типичного микроконтроллера. Такие ядра стоят в некоторых ФПГА Xilinx, и стоит посмотреть у IBM.

Вот тут в левом нижнем углу предлагают 60 дней бесплатно погонять то что вам нужно (похоже).


Вот тут тоже что-то такое предлагают. Смотрите.

Mishka> Ау, перестань. Человеческий мозг не справляется с оптимизациями на машином уровне. Даже полного понимания работы системы нет ни у кого. Только у большой команды.

Вообще то, насколько я знаю, грамотно работают примерно так:
-пишется программа на языке высокого уровня
-прогоняется и смотриться ГДЕ программа НЕ удовлетворяет исходной задаче - по скорости, по объему памяти, по точности.
-совершается попытка (не всегда удачная ) оптимизировать эти кусочки снова на ЯВУ - путем замены алгоритмов, настройки компилятора и т.д.
-снова проверяется
-если опять, что то не устраивает - производиться попытка оптимизации участков кода при помощи ЯНУ...

...У попа была собака...

...пока не приходит начпроекта и говорит: "Да ну их нахрен! Мы по срокам и бюджету не укладываемся - давайте на бетта-тестирование последний вариант, авось не заметят"

Ник

Dima71> Этот РРС 405 расположен на разных платах которые мне приходится ремонтировать.ОС на даном этапе не имеет значение.

Au уже ответил. Есть только ещё пара вопросос — на платах эти процы расположены и там же должны и работать, правильно? Или же ты желаешь их переткнуть на свою платку?


Dima71> Ассемблер мне нужен чтобы написать простые тесты-например для памяти с которой работает РРС.РРС должен загружаться именно с этой тестовой программы которую я хочу написать.Так что если кто-то знает где можно скачать ассемблер для даного РРС пусть ответит мне.Заранее благодарен.


Тут уже становится понятным, что с платы ты проц снимать не будешь. В принципе, есть то, что описал au, а можно и свои кросс-компиляторы построить. GNU в качестве backend-а подойдёт вполне. Его надо скрестить с fron-end-ом. Последний может быть простейши редактором текста, а может быть и чем-то вроде Эклипса. Привлекательность варианта в том, что всё бесплатно.

Вкратце, если у тебя есть связь между платкой и твоим нормальным компом (скажем, ХРюша на нём), то

1. На ХРюшу ставим GNU gas (GNU Assembler — The GNU Operating System) в режиме кросс-ассемблера для PowerPC.
2. Берём любой редактор — тот же notepad и пишем программку на ассемблере и сохраняем в файл.
3. Из досовского окна запускаем gas и ассемблируем.
4. Вот тут важна была бы ОС, но на платке нет — надо средактировать в исполняемый код без ОС.
5. Переносим получившийся бинарник на платку и выполняем там.

Если поставишь Eclipse (404 File not found, то gas можно в него интергрировать. O, есть даже такая интеграция — Eclipse Plugins, Bundles and Products - Eclipse Marketplace — смотри сюда — Macraigor Systems - Eclipse Tools

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