установка AM в CR0 и AC в EFLAGS включает генерацию #AC (Alignment Check) в случае обращения по невыровненным адресам
но это никак не связано с оптимизацией
обработка исключительной ситуации на уровне процессора куда менее эффективное средство для достижения оптимального результата
 

здесь массив не причем
смысл инструкции - прочитать байт в регистр, размер которого превышает 8 разрядов (с нулевым расширением до полного размера)
это к вопросу о дополнительных манипуляциях

  Почему? Разве эффективнее делать 10 проверок чем одну обработку исключения?

хорошо
а как ты отличишь обращение к элементу массива от, например, обращения к полю структуры?
каждый раз компилятор вынужден будет встявлять куски кода по установке и сбросу AC
это более эффективно?

Это сообщение отредактировал(а) MAKCim - 6.11.2007, 10:58

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

  Думаю он использует для этого разные команды.

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

Дельфи? IIRC, он программно полностью контролирует доступ к памяти(в дебаге).

archimed7592, я сейчас говорю про eVC.

Добавлено @ 11:46
Мы же в разделе С++. С чего бы тут обсуждать компилятор Делфи...
[оффтоп]У делфей такие проблемы возникают намного реже, так как там строки/массивы/интерфейсы это управляемая память. Зря напомнили   , ща как разведу оффтопа[/оффтоп]

  
не в команде дело
если у нее есть адресный операнд, то в любом случае существует возможность исключения
если чтение/запись массива выполняется по выровненным адресам, то тогда требуются дополнительные телодвижения для того, чтобы прочитать/записать данные
а ты вроде сам писал

где оптимизация?   

MAKCim ну с асмом мне работать не приходиться, тем более с его различными спецификами, потому даж не знаю как. Читал, что выравнивание делается в целях оптимизации. А как тут без понятия. Если хош могу показать кусок асма. Ща попробую. 

давай

Не только, особенно, если речь про eVC - многие архитектуры не поддерживают обращение по невыровненому адресу.

Alexeis, 

неизвестно, какое значение в r0 после bl
поэтому неизвестно, какой адрес получается в этом месте (r0 + 1)

и в этом

в не зависимости от базового адреса массива x
из двух адресов x + 1 и x + 2 по определению как минимум один из них - не кратен 4-м
Добавлено @ 12:49
Alexeis, 
ассемблер похож на MIPS
оно?

Это сообщение отредактировал(а) MAKCim - 6.11.2007, 12:54

Как видишь проверка указателя на валидность очень сложная задача. А раз так то постарайтся поступить по простому, постарайся избежать её. Например с помощью такого метода: прими что = 0 (NULL) - это инвалидный указатель, остальные валидные. Тогда получается необходимо всегда писать так:

это неверно, если указатель не равен 0, это не значит что он валидный, указатель может указывать неизвестно куда, например в адресное пространство другого процесса. Я уже писал, что есть функции для проверки, указывает ли указатель на область памяти в куче или хрен знает куда (IsBadWritePtr IsBadReadPtr, итд, смотри MSDN). Но даже если он указывает на объект в куче, это еще не значит что он правильный, так как может указывать на уже удаленный объект.
Обычно указатели инициализируют 0, и после удаления объекта обнуляют указатель, чтобы по значению указателя можно было узнать указывает ли он на объект или нет.

есть решение под Linux (но немного извращенное)