AVR GCC&IAR

AM> Значит с времением реакции. Я привел пример по регисрам R6, R7 для х51

MP> Hу давай твой пример обсудим. Hу и что ты глобально будешь хранить в R6-R7? MP> Память через них не адресуешь.

...

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

AM> Усложнение твой жизни меня слабо интересует. Я использовал Си и жизнь AM> мне использовнаие индексных регистров нисколько не усложняло, и AM> устройства эти работают до сих пор, с индексными регисрами. У тебя AM> есть какие-то объективные аргументы против использования AM> индексных регистров? Чем это плохо?

MP> Я не против регистров. Я против их бездумного использования.

Они специально предназначены для адресации локальных переменных функций, размещенных в стеке и для адресации аргументов функций, переданных через стек. Для этого они и используются компилятором.

AM>> И какие процессоры с индексными регистрами ты еще знаешь? MP>> Лучше наверно сказать какие я знаю без них. Hапример пики - очень MP>> добрая архитектура. Как не напиши - все понятно. Hикаких хитростей MP>> не придумаешь. ;)

AM> Это все? То есть разработчики большинства uC дураки, намеренно ввели AM> усложнение в архитектуру в виде индексных регистров, чтобы побольше AM> денег содрать с потребителей?

MP> Расслабься, я нигде не говорил, что наличие таковых регистров плохо.

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

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

AM> Да, а запопинание значений в промежуточных точках будет делать AM> А.С.Пусшин

MP> И сколько их - тех значений? Ты знаешь как переменные передаются при большой MP> вложености функций в архитектурах с "резиновым стеком"?

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

MP> Это просто кошмар какой-то.

Ничего не кошмар

MP> А если эти функции в результате идиотизма человека писавшего MP> программу еще и переформатируются

Что за термин такой, переформатируются?

MP> - эти самые наборы локальных переменных, в результате дублируются в стеке раз MP> эдак пять

За счет чего?

MP> Когда проще было бы 1 раз организовать глобальную переменную с MP> четким форматом и использовать ее во всех этих процедурах.

Глобальным переменным - свое место, локальным свое. В большей степени зависит от конкртеной задачи.

MP>> А так-же что большинство яву алгоритмов имеют избыточные MP>> переменные AM> Какая разница, на чем написан алгоритм. Количество переменных AM> определяется алгоритмом, а не языком, на котором он выражен. Будешь AM> спорить?

MP> Буду, ты путаешь АЛГОРИТМ (последовательность действий) с РЕАЛИЗАЦИЕЙ (оного на MP> конкретно взятом ЯВУ/CPU, в условиях ограниченности данного ЯВУ/CPU). Пример:

MP> a=a+b

MP> Алгоритм выглядит так - 1) Складываем а и б 2) помещаем результат в а. Все, MP> число переменных тут 2 ШТУКИ! а и б.

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

Причем это будет спаведиливо как для асм, так и для ЯВУ. И в чем прикол?

MP> Ты 2 лонга на пике не хочешь перемножить? Вон Орлов отказался ;)

Не пишу на PIC, если бы писал, думаю особых проблем не возникло бы.

MP>> (например счетчик while и AM> Что, счетчик while? AM> Hа асм не надо такого же счетчика? MP> Hадо. Hо но он будет считать в ту сторону которую мне надо и будет MP> инициализироватся тем значением которое мне удобно, в отличии от сей, где для MP> упрощения понимания счетчики практически никогда не считают назад.

Keil 51, v5.20

65 1 unsigned char down_cnt = 20; 66 1 do 67 1 { 68 2 } while (--down_cnt != 0);

; SOURCE LINE # 65 ;---- Variable 'down_cnt' assigned to Register 'R7' ----

0000 7F14 MOV R7,#014H ; SOURCE LINE # 67 ; SOURCE LINE # 68 0002 ?C0007: 0002 DFFE DJNZ R7,?C0007

Как видишь, все считает куда тебе надо. И инициализируется, как тебе удобно, без отличия от асм.

MP>> индекс массива явно заданный как переменная, MP>> считающие вперед и различающиеся на еденичку а то и вообще MP>> одинаковые).

AM> И что? Причем тут Си? Ассемблер то эти счетчики в воздухе хранит, AM> что ли?

MP> В регистрах в соответствии с требуемым размером а не по 4 байта в стеке в MP> соответствии с так любимой тут яву-шной "оптимизацией по времени".

Ты приписываешь компилятору то, что он не делает. См. пример выше.

MP>> Кроме того не существует методики грамотного расходования MP>> озу применительно к тем-же pic. AM> Объясни, зачем компилятору Си нужно больше ОЗУ, чем асм-у? AM> Он его, что, солит?

MP> Да из за банальной дибильной реализации алгоритмов программистом в рамках MP> ограничения языка!

Пример ограниченности приведи.

MP> Ты все еще никак не понимаешь почему програмы на асме MP> короче, быстрее и жрут меньше озу? Это помоему клиника уже.

Понимаю, но короче на 15-30%, быстрее из-за этого же оверхеда. Объем ОЗУ - вопрос спорный, может колебаться в ту или иную сторону в зависимости от задачи. Но в общем случае Си не требует ОЗУ для себя. Что объявил, то и получил, возможно где-то компилятор соптимизируется переменные в регистры.

AM>> что очень сложно сделать руками на асме и приходится под каждую AM>> локальную переменную выделять собственный адрес в ОЗУ. MP>> И не говори. Как люди писали на 11-м проце с 4-мя регистрами, тут MP>> я гляжу некоторым и 32-х не хватает ;)

AM> Ты понимаешь, о чем я вообще говорю? Про распределение памяти под AM> локальные переменные функций. Причем тут регистры?

MP> При том что в си их нет - и ты банально не можешь понять, как это так люди MP> пишут проги, не имеют HИ ОДHОЙ! локальной переменной в них,

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

MP> и при этом озу у них не расходуется вообще.

MP> Помоему ты вообще не представляешь методики реализации алгоритмов на MP> нативных языках процессоров с использованием исключительно HАБОРОВ РЕГИСТРОВ MP> в качестве абсолютно всех локальных переменных,

Во первых, регистров может не хватить для всех локальных переменных, и обычно не хватает. Во вторых, если твоя функция вызывает другую функцию, то перед вызовом регистры нужно сохранить, чтобы не потерять значения в них, то есть потребность в памяти никуда не девается. Либо должно быть соглашение о вызовах, например функция может портить регистры R4,R5, а другие регистры не должна портить, что эквивалентно либо необходимости сохранения/восстановления этих регистров (если вдруг функция захочет их поюзать), либо размещению локальных переменных в памяти.

MP> и не понимаешь как это вдруг подобное приводит к экономии всего на свете.

Потребность в ОЗУ никуда не девается, просто немного смещаются акценты. При вложенных вызовах кто-то должен заботится о сохранении регистров, и сохраняются они в ОЗУ, независимо от Си/asm.

AM> Впрочем, если возможно, компилятор Си может соптимизировать локальную AM> переменную и положить ее в регистр.

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

И много компиляторов ты изучил на этот предмет?

AM>> ПЗУ - примерно тоже, даже с учетом оверхеда Си 15-30% MP>> "Шо.. oпять?" (c) мф. "жил был пес". AM> Я предложил Шепелеву выбрать алгоритм из Numerical Recipes in C. AM> Предлагаю и тебе. Выбери алгоритм, я его откомпилирую под х51. Докажи AM> на деле, что на асм можно сделать хотябы на пол-порядка эффективнее.

MP> А зачем. Я могу сейчас найти какой-нибудь open source embedded для x51 на сях и MP> предоставить его тебе для компиляции... А то опять получится сферическая MP> лошадь.

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

DT> Что-то свежие веpсии с ходу не находятся.

Hi George,

Thu Jan 22 2004 13:31, George Shepelev wrote to Alex Kouznetsov:

AK>>>> Hапример, конкретная проблема: какие слова должны входить в AK>>>> состав ядра? GS>>> Эта проблема уже решена, кинуть список? AK>> Кидай, это интересно. Если на мыло, то на a_kouz(на)yahoo.com

GS> Отвечено нетмейлом.

Поскольку фидошный гейт отшибает яхушный мэйл: ============== Message from yahoo.com. Unable to deliver message to the following address(es).

<George_Shepelev@....>: Connected to 193.109.241.148 but sender was rejected. Remote host said: 550 I want to know size of messages to fidonet. Use ESMTP. ============== ответить придется в эхе.

Два комментария:

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

-- Для FVM вообще говоря не нужны многие слова, необходимые резидентному ("настоящему") Форту. Поскольку мне, например, не нужен резидентный Форт - мне не нужна почти половина слов из твоего списка.

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

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

Fri Jan 23 2004 15:31, Ilia Tarasov wrote to George Shepelev:

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

IT> Компилятором является программа, преобразующая программу на одном языке в IT> программу на другом.

Совершенно верно. "Книга дракона" дает такую формулировку:

Компилятор - это программа, которая считывает текст программы, написанной на одном языке - исходном, и транслирует (переводит) его в эквивалентный текст на другом языке - целевом ("Компиляторы: принципы, технологии и инструменты" Пер. с англ. - М.: Издательский дом "Вильямс", 2001, стр.22)

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