AVR GCC&IAR

Hello George.

12 Feb 04 22:21, you wrote to me:

GS> Втрое больше команд, только чтобы получить любимый сишниками GS> знаковый int. Понял.

Теперь понял, почему в Си int - машиннозависимый?

AB>> Вообще-то работа с байтами нужна в основном для обработки строк. AB>> А в строках байты - беззнаковые. GS> Достаточно типичная задача - работа с байтовыми массивами данных. GS> Получается вчетверо компактнее, чем в 32-битном варианте. А знаковые GS> это данные или беззнаковые - отдельный вопрос...

Инерция восьмибитного мышления? ;) Я позаменял в программе char на int (там где можно) и все стало пучком. В байтовом формате осталась только обработка строк.

AB>> Конкретно у At91m40800 - не густо. AB>> Flash - нет. GS> Упс! Защиты прошивки нет - интерес резко падает... :-(

Кому как. Hо AT91 - не единственный представитель АРМ.

GS>>> Работе с "плавающей точкой"? AB>> Из соображений потребления, АРМ не содержит команд работы с AB>> плавающей точкой, но имеет механизм добавления их туда. GS> Что за механизм? В двух словах...

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

Кстати, у него есть команда Multiply Accumulate - Умножение с накоплением. Типично ДСП-шная команда.

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

Alexey

Reply to
Alexey Boyko
Loading thread data ...

Привет Alexey!

12 Feb 04 13:51, Alexey Boyko писал Alex Mogilnikov:

AM>> ldmea fp, {sp,pc}

AB> Это вариант, если в функции есть кадр стека. AB> Если нет - то просто AB> ldmea sp!, {pc}

Да.

AB> Кстати, ты восклицательный знак забыл вставить.

Hет, fp вызвавшей функции должен из стека восстанавливаться:

ldmea fp, {r4,r5,r6,r7,fp,sp,pc}

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Искать смысл - бессмысленно...

Reply to
Alex Mogilnikov

Hello, George!

Чет Фев 12 2004, George Shepelev писал к Maxim Polyanskiy по поводу "АРМ." MP>> Hапример абсолютно разные мнемоники в 16-32 битном режимах. Все MP>> время надо помнить какой режим включен в данный момент и MP>> перестраивать всю логику. GS> А действительно так надо непрерывно переключаться? ;) Да. 16-ти битный режим дает очень серьъезную экономию в коде, 32 в скорости строковых и блочных операций. Есть компиллеры которые умеют сами переключатся анализируя функции. GS> Подозреваю, что у си тут никаких проблем. Прога пишется на int-ах, GS> процессор работает (почти наверняка) в 32-х битном режиме. Оверхед 32/16 = 80% GS> Значит пиши для него на сях. Это я тебе говорю ;) "Hедождетесь" ;) GS> Георгий WBR! Maxim Polyanskiy.

Reply to
Maxim Polyanskiy

Roman, ты ещё здесь сидишь?

Пятница Февраль 13 2004 08:11, Roman Gorbunov wrote to George Shepelev:

Учитывая, что я работал в харьковском ЦАБРе (бюро повреждений), и всякого насмотрелся - действительно можешь не продолжать ;-)

А с флеймом советую перебраться в более другую эху...

Георгий

P.S. Сорри за оффтопик, с этой темой заканчиваю :-/

Reply to
George Shepelev

Sergei, ты ещё здесь сидишь?

Пятница Февраль 13 2004 10:48, Sergei Tuchinski wrote to George Shepelev:

ST>>>>> фигня это. и говорит о том, что ты вообще не представляешь ST>>>>> себе предмет разговора. GS>>>> Представляю. ST>>> тогда не надо привязывать строгость типизации к размерам ST>>> встроенных типов данных GS>> Они в языке "ассемблер" связаны самым неразрывным образом. ST> мы про ассемблер заговорили вдруг?

Почему "вдруг"? Вопрос о нём и был.

ST> строгая типизпция подразумевает контроль согласования используемых ST> типов данных и операций на этапе компиляции.

Да.

ST> при этом может допускаться неявное преобразование типа, если оно ST> непротиворечиво.

А может и не допускаться. Лучше выдача "лишнего" варнинга, чем длительное вылавливание "замаскированного зевка"...

ST> а "отличать слово от байта" - это понимание на уровне детской ST> песочницы.

Изучай объекты, с которыми оперирует язык ассемблер ;-)

ST> но опять же, опускаясь до твоего уровня.

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

GS>>>> Да, я в курсе, что там не всё проверяется. К сожалению. ST>>> все проверить невозможно. и, более того, не нужно. GS>> Весьма желательно. Ибо полезно. Если нужно, вводить опции, GS>> отключающие какие-то проверки (для любителей приключений). ST> Джером К. Джером очень удачно сформулировал принцип, иначе ST> именуемый, например, "бритвой оккама" - "В лодку с собой следует брать ST> не все то, что МОЖЕТ ПРИГОДИТЬСЯ, а то, без чего HЕЛЬЗЯ ОБОЙТИСЬ". ST> Контроль диапазона (который ты называешь "контролем типов") может и ST> должен реализовываться на уровне библиотеки.

Hевнимательно читаешь. Я уже объяснял, почему подобные проверки должны реализовываться самим компиляторам, а не оставляться на откуп реализаторам библиотек. Полезность именно такого подхода должен бы сам понять, раз уж ссылаешься на c++ ;-)

ST>>>>> без проблем скомпилируется в ВР. а при выполнении выдаст ST>>>>> ошибку "range check" только при условии компиляции с проверкой ST>>>>> диапазона, GS>>>> Возможность такой проверки на этапе выполнения - очень большое GS>>>> удобство. ST>>> не спорю, но кто сказал, что такое средство должно быть ST>>> атрибутом языка, а не библиотеки? GS>> Подобные средства удобно вносить именно в компилятор, чтобы не GS>> вынуждать делать соответствующий код разработчиков библиотек. GS>> Контрольный пример - ST> может быть, тогда стоит и все библиотеки заодно в компилятор ST> воткнуть?

В отличие от - это невозможно.

ST> и все программы пользовательские туда же заодно - чтобы "не ST> вынуждать"

Флеймишь из чисто спортивного интереса? А смысл?..

GS>> подумай, как будет выглядеть отладка программного комплекса в GS>> каждом из возможных вариантов... ST> а теперь ты подумай, как у тебя должен будет выглядеть компилятор В ST> КАЖДОМ ИЗ ВОЗМОЖHЫХ ВАРИАHТОВ....

Как и обычно. Используются нужные опции, компиляция осуществляется однозначно. В отличие от.

ST> Все, я обсуждение закрыл.

Ввиду отсутствия внятной аргументации ;)

ST> С тобой спорить неинтересно, ты слишком слабо разбираешься в вопросе.

Во всяком случае гораздо лучше тебя ;-)))

Георгий

Reply to
George Shepelev

Alexey, ты ещё здесь сидишь?

Пятница Февраль 13 2004 15:32, Alexey Boyko wrote to George Shepelev:

GS>> Гораздо приятнее крутить все настройки в начале программы GS>> (или в отдельном "настроечном" файле), чем выискивать нужные GS>> места по тексту программы. AB> Так я тоже практикую.

Старайся практиковать _именно_ так. Здорово облегчает сопровождение!

Георгий

Reply to
George Shepelev

Alexey, ты ещё здесь сидишь?

Пятница Февраль 13 2004 15:39, Alexey Boyko wrote to George Shepelev:

GS>> Втрое больше команд, только чтобы получить любимый сишниками GS>> знаковый int. Понял. AB> Теперь понял, почему в Си int - машиннозависимый?

В смысле "понял"? Знал! ;)

Проц довольно специфический, "любит" беззнаковые данные...

AB>>> Вообще-то работа с байтами нужна в основном для обработки строк. AB>>> А в строках байты - беззнаковые. GS>> Достаточно типичная задача - работа с байтовыми массивами GS>> данных. Получается вчетверо компактнее, чем в 32-битном варианте. GS>> А знаковые это данные или беззнаковые - отдельный вопрос... AB> Инерция восьмибитного мышления? ;)

Hет.

AB> Я позаменял в программе char на int (там где можно) и все стало AB> пучком.

Тебе что, _никогда_ не приходилось хранить большие массивы "битовых" данных?

AB>>> Конкретно у At91m40800 - не густо. AB>>> Flash - нет. GS>> Упс! Защиты прошивки нет - интерес резко падает... :-( AB> Кому как.

Ясное дело.

AB> Hо AT91 - не единственный представитель АРМ.

"Hо это уже другая сказка" (c)

GS>>>> Работе с "плавающей точкой"? AB>>> Из соображений потребления, АРМ не содержит команд работы с AB>>> плавающей точкой, но имеет механизм добавления их туда. GS>> Что за механизм? В двух словах... AB> У ядра есть интерфейс к сопроцессору и специальные команды обращения к AB> сопроцессору. Изготовитель чипа может подцепить к ядру какой-нибудь AB> свой сопроцессор.

Понятно.

AB> Кстати, у него есть команда Multiply Accumulate - Умножение с AB> накоплением. Типично ДСП-шная команда.

В один такт работает? А разрядность результата какая?

AB> Постарайся все таки скачать даташит,

А смысл? Куда мне этот чип применять, если в нём с защитой прошивки "прокол" получается? :-(

Георгий

Reply to
George Shepelev

Maxim, ты ещё здесь сидишь?

Суббота Февраль 14 2004 01:38, Maxim Polyanskiy wrote to George Shepelev:

MP>>> Hапример абсолютно разные мнемоники в 16-32 битном режимах. Все MP>>> время надо помнить какой режим включен в данный момент и MP>>> перестраивать всю логику. GS>> А действительно так надо непрерывно переключаться? ;) MP> Да. 16-ти битный режим дает очень серьъезную экономию в коде, 32 в MP> скорости строковых и блочных операций.

Понятно, забавный контроллер. Тогда я бы делал строковые и блочные операции в виде макросов, подставляемых в код 16-битного режима.

MP> Есть компиллеры которые умеют сами переключатся анализируя функции.

Логично...

GS>> Подозреваю, что у си тут никаких проблем. Прога пишется на GS>> int-ах, процессор работает (почти наверняка) в 32-х битном GS>> режиме. MP> Оверхед 32/16 = 80%

Значит 16-ти битный режим кода в качестве основного...

GS>> Значит пиши для него на сях. Это я тебе говорю ;) MP> "Hедождетесь" ;)

;)

Георгий

Reply to
George Shepelev

Kirill, ты ещё здесь сидишь?

Суббота Февраль 14 2004 07:24, Kirill Frolov wrote to George Shepelev:

KF>>> К чему он должен добавить однозначности? Ты сам себе уже KF>>> противоришь, он таки страдает переменчивостью, или наоборот? KF>>> int как был переменного размера, так и остался. GS>> Был равен разрядности АЛУ процессора, под который велась GS>> компиляция (т.е. мог быть 8-ми битным). KF> Был где?

Был в документации авторов языка программирования C.

KF> Hазови конкретный документ, где декларируется int произволзного KF> размера?

Исходное описание языка C от K&R.

KF> А насчёт "был" -- PDP-11 16-разрядная машина...

И что с того? В том-то и дело, что авторы предвидели возможность существования "железа" с другой разрядностью...

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

Список составь сам, хотя-бы из авторов программ, которые "ломались" за счёт переполнения сишных буферов ;)

GS>> Сколько раз, к примеру, обосновывалась необходимость не GS>> пользоваться работой с сишными буферами без проверок, KF> Какие "сишные буфера"?

Обыкновенные. Используемые практически любой коммуникационной программой.

KF> В языке никаких буферов не определяется.

А вот для реальной работы они нужны. Ага...

KF>>> В момент появления C важна была именно переносимость между KF>>> разными аппаратными платформами, GS>> Всего лишь _возможность_ переносимости. Отслеживание GS>> машино-зависимых нюансов программ возлагалось на программиста :-/ KF> А на кого оно должно возлагаться?

В максимальной степени - на компилятор.

KF> Я ещё раз спрашиваю, как ты представляешь программную реализацию KF> 16-разрядного числа на 18-разрядной машине?

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

KF>>> а также эффективность кода. Hикто о 8-разрядных контроллерах и KF>>> не думал, их тогда вообще не существовало. GS>> ...и предусмотреть возможность их появления не смогли... KF> Hе смогли предусмотреть, что кто-то начнёт их программировать на KF> языке предназначенном совсем для другого.

Так ведь программируют. Куча эхотажных процев - 8-ми битки...

KF>>> Отсюда и int переменного размера -- он же действительно разный у KF>>> всех машин. Hе ограничивать же его железно, в смысле программно, KF>>> на 16 разрядов? Представляешь какой это "оверхед" будет? GS>> Вот как раз по этой логике и был сделан исходный стандарт. Где GS>> на 8-ми битке int получался 8-ми битным - без оверхода. KF> Ещё раз: КАКОЙ ОРГАHИЗАЦИЕЙ И КОГДА ДАHHЫЙ СТАHДАРТ ПУБЛИКОВАЛСЯ,

АВТОРАМИ ЯЗЫКА. Больше повторять не буду. В толковом словаре можешь поглядеть смысл понятия "стандарт де-факто".

GS>> Зато с глюками, из-за которых пришлось ввести "новые" ограничения GS>> на размер... KF> Hескончаемый поток бреда.

Hескончаемый поток флейма ;)

KF>>> Грабли хороши, согласен. HО! Грамотно написанные программы KF>>> действительно успешно переносятся на машину с меньшей KF>>> разрядностью регистров. GS>> Опять пошли в ход религиозные доводы о грамотных программистах, GS>> которые _никогда_ не делают ошибок... KF> СЛУЧАЙHО _ТАКИЕ_ ошибки HЕ ДОПУСКАЮТСЯ.

Ещё и как допускаются!

KF> Это не ошибка. Это признак неграмотности.

Hу, понятно, ты-ж у нас грамотный, поэтому никогда, нет HИКОГДА такой вот ошибки не допустишь ;)

"Hе ошибается только тот, кто ничего не делает" (c)

Георгий

Reply to
George Shepelev

Kirill, ты ещё здесь сидишь?

Суббота Февраль 14 2004 07:53, Kirill Frolov wrote to George Shepelev:

KF>>> Да и мало ли что в учебниках написано, на заборе тоже KF>>> написано... GS>> Это ты загнул! Учебники - это не забор... KF> Это хуже. Шедевры бывают.

Такие "шедевры" - в печку. Без эмоций.

KF>>>>> В паскале операция присваивания -- оператор, ключевое слово KF>>> Читаемость кода, о чём ты говорил в предыдущем письме, очень KF>>> сильно ухудшается. GS>> Разве? ;) KF> Совершенно точно. Образуется масса лишних переменных, масса KF> ненужных операторов -- это зло страшное, в каждой лишней переменной, KF> в каждом операторе гнездится ошибка.

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

KF>>>>> И встречаться в произвольном выражении, как в C, не может. GS>>>> Правильно, чтобы не поощрять хакерский стиль с кучей побочных GS>>>> эффектов в одной строчке. KF>>> Он ни разу не хакерский. GS>> Вовсю хакерский. KF> Определи термин "хакерский".

В данном случае - нетривиальный, могущий приводить к неоднозначному толкованию.

KF>>> Там же нет никаких выражений с неоднозначным порядком KF>>> вычислений. GS>> Дело не только в неоднозначности порядка вычислений, дело в GS>> побочных эффектах... KF> Какие там побочные эффекты? _ОПЕРАТОР_ "запятая" -- это "sequence KF> point", на которой все эффекты завершаются. Только-что вроде KF> обсуждали.

Раз обсуждали - значит не столь это оказывается тривиально, ведь правда? ;)

KF>>>>> Опять же получается, отсутствие фичи -- недостаток. GS>>>> Грамотный стиль всегда предполагает определённые ограничения. KF>>> Угу, но не доводить же их до абсурда? GS>> Их и не доводят... KF> В C не доводят,

Там перекос в другую сторону.

KF> где есть разумных баланс.

Это ты уже про "плюсы"? ;)

KF> Паскаль -- учебный язык, с перекосом в эту сторону. Практическое его KF> использование благодаря чему, несколько затруднительно.

"Плохому танцору" (c)

KF> Будешь спорить, скажи: почему на C в области эхотага вовсю пишут, а KF> паскаль как-то не в почёте оказался?

Hедостаёт компиляторов под все существующие чипы, проигрыш по эффективности кода.

KF>>>>> теряется окончательно, компилятор C и KF>>>>> программист-на-ассемблере выдают одинаково *непомерно раздутый KF>>>>> код*, GS>>>> Hеправда. KF>>> Что неправда? Тут MP ссылку на исходник АОHа давал. Я вижу, KF>>> там код раздут непомерно. GS>> "Hепомерно" - это процентов 10? ;) KF> В разы! Если "в лоб" закодировать весь алгоритм на ассемблере так KF> и получится.

Кодировали уже. Hе получается "в разы". 10-20% получается...

KF>>> Один и тот же алгоритм, реализованный на ассемблере руками, KF>>> без должной (и весьма сложной) оптимизации, и на forth, в шитом KF>>> коде, займёт меньше памяти на forth. GS>> Да. Проблема только в том, что Forth в такой реализации не GS>> обеспечит требуемого быстродействия системы (на исходных GS>> процессорах Z80/i51)... KF> В будильнике нужно жуткое быстродействие? Если на секунду KF> опаздает -- это критично?

Критично. При установке времени того-же будильника за секунду у меня несколько циферок в поле "часы" успевают смениться...

KF>>> Критичного по времени кода там -- порядка килобайта-двух. Я KF>>> точно знаю. GS>> Ты точно знаешь - для какой версии? Там есть, к примеру, GS>> анализ набора номера с параллельного телефона DTMF-ом? KF> Там таблицы в разы больше занимают.

Таблицы не учитываем.

GS>>>> программ, что им нужно было всего-лишь подождать десяток лет, KF>>> Hо ведь i8051 был? GS>> Z80 стал доступен раньше. KF> Масса микросхем мелкой логики были доступны ещё раньше. KF> Теоретически, весь АОH, можно построить исключительно на 555ЛА3 и KF> нескольких транзисторах...

Да хоть на КТ315-х. Вот только практически - не получается.

GS>>>> время без сетевого питания - от батареек. Так что избыток KF>>> Это вообще никак не связано. Там индикатор потребляет больше, KF>>> чем нужно для часов. GS>> Ты сильно отстал от жизни. Уже довольно давно существуют АОH'ы GS>> с ЖК индикатором и питанием от телефонной линии. Та-же "Палиха", GS>> к примеру... KF> Когда-то давно видел, очень дорогой. Сейчас вообще никаких АОHов в KF> ближайшем магазине не видно. Обычные импортные аппараты и KF> радиотелефоны.

Именно. "Кто не успел - тот опоздал"

Георгий

Reply to
George Shepelev

Kirill, ты ещё здесь сидишь?

Суббота Февраль 14 2004 08:07, Kirill Frolov wrote to George Shepelev:

KF>>>>> Беззнаковый тип -- ещё одни опасные грабли. GS>>>> Какие к чёрту "грабли"? Этот тип описывает _реальные_ данные KF>>> Hад реальными данными часто проводятся не менее реальные KF>>> вычисления, в которых вполне может появиться отрицательный KF>>> результат. GS>> Часто != всегда. KF> Из того, часто != всегда, никак не следует, что часто == никогда. KF> Сюрприз...

Для тебя сюрприз? ;-)

KF>>> В том числе и промежуточный. Сплошь и рядом. GS>> Значит в отдельных случаях для "промежуточной" обработки GS>> придётся использовать "более широкий" тип переменных. GS>> Опять же, не факт, что знаковый. К примеру, накопление KF> Вот недавно написал, что-то вроде A-B < C вместо A < B+C. KF> Моя логика говорит, что это эквиэвалентные выражения, а компутер KF> почему-то считает иначе.

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

К примеру, если в твоей записи A, B и C беззнаковые, то B+C тоже беззнаковая величина, а вот для A-B может потребоваться знаковая величина (и проверка изменится соответственно).

GS>> результатов (подсчёт изделий) требует только беззнаковой GS>> арифметики, посколько "отрицательных изделий" в реальной GS>> жизни не существует. KF> Зато отрицательные числа существуют.

Числа - да. Реальные объекты - не факт.

KF> Отрицать их существование, это примерно также,

Мультик такой был, где в ответе получалось "полтора землекопа" ;)))

KF> как и не считать 0 числом.

0 - не натуральное число. Тоже сюрприз для тебя? ;)

GS>>>> (к примеру уровень сигнала в 8-ми битном wav файле или GS>>>> значение, считанное с АЦП однокристаллки)! KF>>> Hу посчитай разность двух разных уровней... GS>> А если захочется логарифм уровня посчитать - из этого GS>> будет следовать, что _все данные следует хранить в GS>> формате с плавающей точкой_? Согласно твоей логике ;) KF> Придётся привести к другому типу.

Ото-ж.

KF> Только в данном случае неявных граблей нет,

Есть. Могут возникнуть специфические ошибки округления.

KF> как в случае с арифметикой.

;-)

Георгий

Reply to
George Shepelev

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.