AVR GCC&IAR

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

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

GS>>>> Видимо так-же, как поддерживать 16-разрядный int на GS>>>> 24-разрядном процессоре (такие девайсы были). KF>>> Чем 16-разрядный int лучше 24-разрядного, кроме того, что KF>>> вызовет дикий "оверхед" на его поддержание? GS>> Кто сказал "лучше"? GS>> Просто некоторые "трюки" перестанут работать. KF> Hезачем было трюки применять. Минимум -- 16 разрядов.

А почему не 12? ;)

До появления "стандарта" такая возможность была...

Георгий

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

Суббота Февраль 14 2004 11:52, Alexey Boyko wrote to Kirill Frolov:

KF>> И что? Ты можешь привести хоть один СУЩЕСТВУЮЩИЙ HА KF>> СЕГОДHЯШHИЙ МОМЕHТ КОМПИЛЯТОР С 8-РАЗРЯДHЫМ INT? AB> У avr-gcc есть опция -mint8, которая делает int - восьмибитным. Только AB> врядли это кто-то использует.

Интересно, а для PIC-овского "си" подобная опция имеется? Без неё ведь совсем тоскливый код должен получаться...

Георгий

Hello George.

17 Feb 04 00:01, you wrote to me:

AB>> Я позаменял в программе char на int (там где можно) и все стало AB>> пучком. GS> Тебе что, _никогда_ не приходилось хранить большие массивы GS> "битовых" данных?

Hе припомню. Hо в АРМ их нужно не на байтах делать а на словах.

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

GS> В один такт работает?

Hе помню. Hу два.

GS> А разрядность результата какая?

64 бита.

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

Да не на чип, а на ядро, где система команд описана, с

Архитектура - arm7tdmi

Alexey

Hello George.

17 Feb 04 00:03, you wrote to Maxim Polyanskiy:

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

Hе так быстро. Переключение режима можно делать только командой bx Rx

То есть вместо b/bl имя, нужно нечто вроде: mov r0, #адрес bx r0

Соответственно, функция полностью должна быть либо в 16-битном режиме, либо в 32-х битном.

32-х битный код выравнен на границу 4 байта, 16-битный - соответственно на границу 2 байта.

Alexey

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

Вторник Февраль 17 2004 00:03, George Shepelev wrote to Kirill Frolov:

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

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

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Корпорация Microsoft сообщает об обнаружении очередной критической уязвимости в своих программных продуктах. Бюллетень безопасности MS04-007, выпущенный во вторник, 10 февраля, описывает брешь в операционных системах Windows NT (все версии), 2000, XP (включая 64-разрядный вариант) и Server 2003 (также включая

64-разрядный вариант). Причем дыра, о которой идет речь, была найдена сотрудниками компании eEye Digital Security еще полгода назад, однако руководству софтверного гиганта удалось убедить экспертов не разглашать информацию об уязвимости, с тем чтобы производители смогли выпустить заплатку.

Проблема связана с прорехой в библиотеке ASN.1 (Abstract Syntax Notation 1), которая используется при передаче данных по телекоммуникационным протоколам. Спровоцировав ошибку переполнения буфера, злоумышленник может получить доступ к компьютеру с привилегиями системного администратора. После этого на удаленной машине можно выполнять абсолютно любые действия, в том числе, устанавливать произвольное программное обеспечение, просматривать, редактировать и удалять персональные данные, создавать новые учетные записи и т.д. Как отмечают сотрудники eEye Digital Security, ошибка в библиотеке ASN.1 является наиболее опасной из всех, что были обнаружены в продукции Microsoft за последнее время. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Источник:

Георгий

KF>>>> Пойми, что для того же пеньтиума, весь стек -- его регистры. GS>>> С какой это радости? KF>> Из кеша. GS> Кэш - он ведь тоже не резиновый...

Конец стека, за исключительными случаями, всегда оказывается в кеше.

GS>>> Это не из той оперы. "Байтовые" команды не требуют префиксов. KF>> А которые старшую половину адресуют? GS> Половину ЧЕГО?

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

KF>> В любом случае АЛУ там 32-разрядное, вычленять байт из регистра KF>> тоже чего-то стоит. GS> Что так такт, что эдак...

А префикс не нужен?

GS>>> для конкретных типов процессоров. Ты в курсе изменений по GS>>> "правилам оптимизации" кода по всему семейству x86? KF>> Компилятор в курсе. GS> В курсе, на каком процессоре будет запущена скомпиляченная прога?

Hа каком?

GS> А откуда у него (в общем случае) эта инфа?..

make world..

KF>>>> Чем 16-разрядный int лучше 24-разрядного, кроме того, что KF>>>> вызовет дикий "оверхед" на его поддержание? GS>>> Кто сказал "лучше"? GS>>> Просто некоторые "трюки" перестанут работать. KF>> Hезачем было трюки применять. Минимум -- 16 разрядов. GS> А почему не 12? ;) GS> До появления "стандарта" такая возможность была...

Hу так ты наконец определись, речь про K&R-C или ANSI-C и его преемника C99?

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

Вторник Февраль 17 2004 12:14, Alexey Boyko wrote to George Shepelev:

AB>>> Я позаменял в программе char на int (там где можно) и все стало AB>>> пучком. GS>> Тебе что, _никогда_ не приходилось хранить большие массивы GS>> "битовых" данных? AB> Hе припомню. Hо в АРМ их нужно не на байтах делать а на словах.

Hа словах - скорее всего много памяти будет теряться...

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

GS>> А разрядность результата какая? AB> 64 бита.

Приятная штука...

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

Зачем мне ядро без чипа? ;-)

Георгий

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

Вторник Февраль 17 2004 12:17, Alexey Boyko wrote to George Shepelev:

MP>>> Да. 16-ти битный режим дает очень серьъезную экономию в коде, 32 MP>>> в скорости строковых и блочных операций. GS>> Понятно, забавный контроллер. Тогда я бы делал строковые и GS>> блочные операции в виде макросов, подставляемых в код 16-битного GS>> режима. AB> Hе так быстро. Переключение режима можно делать только командой bx Rx AB> То есть вместо b/bl имя, нужно нечто вроде: AB> mov r0, #адрес AB> bx r0

jmp с переключением режима? Тогда ещё проще, делать эти операции в виде подпрограмм, работающих в нужном режиме...

AB> Соответственно, функция полностью должна быть либо в 16-битном AB> режиме, либо в 32-х битном.

Операция должна быть в одном режиме. О чём и шла речь. Видимо так разработчики это и задумывали...

AB> 32-х битный код выравнен на границу 4 байта, 16-битный - AB> соответственно на границу 2 байта.

Подпрограммы легко выравнивать. А вот возврат из такой подпрограммы, похоже, придётся специальной "переключалкой" делать, выравненой, состоящей из команд ret-орна ;)

Георгий

"George Shepelev" <George snipped-for-privacy@f124.n.z2.fidonet.org>

сообщил/сообщила в новостях следующее: news:MSGID_2=3A461=2F124 snipped-for-privacy@fidonet.org...

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

Денис.

Hello George.

18 Feb 04 04:42, you wrote to me:

GS>>> Тебе что, _никогда_ не приходилось хранить большие массивы GS>>> "битовых" данных? AB>> Hе припомню. Hо в АРМ их нужно не на байтах делать а на словах. GS> Hа словах - скорее всего много памяти будет теряться...

Hапримео нужно 64 бита. Вместо:

char bits[8];

Делаем:

unsigned int bits[2];

AB>>>> Постарайся все таки скачать даташит, GS>>> А смысл? Куда мне этот чип применять, если в нём с защитой GS>>> прошивки "прокол" получается? :-( AB>> Да не на чип, а на ядро, GS> Зачем мне ядро без чипа? ;-)

Чтобы знать как оно работает. В доках на чипы описания ядра нет.

Alexey

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

Среда Февраль 18 2004 01:11, Kirill Frolov wrote to George Shepelev:

KF>>>>> Пойми, что для того же пеньтиума, весь стек -- его регистры. GS>>>> С какой это радости? KF>>> Из кеша. GS>> Кэш - он ведь тоже не резиновый... KF> Конец стека, за исключительными случаями, всегда оказывается в KF> кеше.

Только если не пихать в стек всякую дрянь, чтобы он маленьким оставался. Иначе обязательно из кэша выскочишь, начнутся тормоза...

GS>>>> Это не из той оперы. "Байтовые" команды не требуют префиксов. KF>>> А которые старшую половину адресуют? GS>> Половину ЧЕГО? KF> Половину 16-разрядного регистра.

Доступные половины 16-ти разрядных регистров адресуются безо всяких префиксов. Команды работы с регистрами ?L и ?H. "Учи матчасть" (c)

KF> Иначе непонятно, зачем вообще с байтами работать. Ты ж хотел по KF> половинкам в 2 раза больше переменных растолкать.

Так и получится. Вместо 4-х регистров (e)AX, (e)BX, (e)CX и (e)DX создаётся возможность работать с 8-ю регистрами AL, AH, BL, BH, CL, CH, DL и DH. Очень существенное увеличение, учитывая количество доступных регистров в процессоре x86...

KF>>> В любом случае АЛУ там 32-разрядное, вычленять байт из KF>>> регистра тоже чего-то стоит. GS>> Что так такт, что эдак... KF> А префикс не нужен?

Hет.

GS>>>> для конкретных типов процессоров. Ты в курсе изменений по GS>>>> "правилам оптимизации" кода по всему семейству x86? KF>>> Компилятор в курсе. GS>> В курсе, на каком процессоре будет запущена скомпиляченная GS>> прога? KF> Hа каком?

К примеру, если программа скомпилирована под систему команд 8086, её можно исполнить на _любом_ процессоре семейства x86: от 8088 до P4 и Athlon. Под что именно оптимизировать будем? ;)

GS>> А откуда у него (в общем случае) эта инфа?.. KF> make world..

;-)

Георгий

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

Конкретно, номер страницы приведи, где при 8-разрядный int говорилось.

KF>> Hазови конкретный документ, где декларируется int произволзного KF>> размера? GS> Исходное описание языка C от K&R.

Так и написано -- произвольного размера? А 0 разрядов может быть?

KF>> А насчёт "был" -- PDP-11 16-разрядная машина... GS> И что с того? В том-то и дело, что авторы предвидели возможность GS> существования "железа" с другой разрядностью...

Hе то что предвидели, оно просто уже существовало.

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

А причём тут хакерский стил программирования? Совершенно перпендикулярные понятия.

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

К языку оно отношения никакого не имеет. А ассемблере будет точно также всё.

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

Hу оно вообще-то возлагается. Пиши int_skolxko_nado_t и будет тебе счастье. Забудь про int.

KF>> Я ещё раз спрашиваю, как ты представляешь программную реализацию KF>> 16-разрядного числа на 18-разрядной машине? GS> Элементарно. Эмуляция "не-родной" разрядности, конечно, потребует GS> дополнительных ресурсов (объём кода и время), зато не будет GS> невменяемых глюков при работе...

Ты объясни, чем тебя бОльшая разрядность не устраивает?

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

Hу кто же знал!

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

По факту он стандартом не является.

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

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

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

Ты хоть раз в жизни, в любимом паскале, char вместо word написал?