Ах, вон оно что! В Keil... А, я то - попробовал в IAR для AVR... И, кстати, - не работает и в таком, упращенном примере.

ARMовый 6-й IAR компили-т без умножения...

Все тут пишут, что умножение указателей не поддерживается... оно то, конечно, верно, но ведь ТС пытается сначала привести адрес к u32, потом выполнить все действия и привести результат к указателю.
Ситуация с константностью выражения более-менее понятна, но вот где тут операции с указателями? Мне пока не ясно.

P.S. придерживаюсь мнения, что ТС должен пректатить все эти извращения и найти более православный способ сделать то, что он хочет.

вот все и пытаются понять, как оно там компилятором поймется и линкером сложится

Ааа, ну да! Вообще-то логично, что считать должен уже линкер, который знает адрес. И он не обязан уметь делить и умножать. Согласен.

не только к Вам, а к общественности - а ведь действительно, линкер ТОЛЬКО собирает?
ни разу не приходилось разбирать obj файлы, линкер собирает из них только то, что уже явно указано в размещении, без каких-либо вычислений?

Конечно же - вычисляет. Вычисления, само-сабой, без наворотов.

я и говорю - относительные размещения
не вычисляет же выражения... компилятору - компиляторово

Хехе, а интересный же вопрос, а! Особенно вариант как у ТС, когда указатель преобразовывается в int и пошло-поехало...
И, судя по отзывам, разные компиляторы по разному ведут себя.. А как правильно?
Ну и интереснее всего тут именно роль линкера.

Сейчас подойдет товарищ из Риги и всем всё объяснит.

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

UPD

Хорош прикалываться. Не дай Бог чего

Да. Я тоже о нём подумал)))))

А что в выражении u32 * b = (u32 *)( (u32)(&a) ) вы считаете извращением? Я таким уже давно пользуюсь и успешно.
Насчет неправильной формулы - это я случайно когда писал тут вставил адрес периферии, для которой, кстати, я также через битбенд флаги всякие юзаю.




Сейчас временно сделал во так:Ну и соответственно на асме это выглядит так:

Куда меньше чем при использовании масок и т.п.

Сообщение отредактировал ISK2010 - Sep 4 2011, 06:58

Лично я всегда думал, что изобилие в коде приведений к типу - есть признак не совсем корректного использования возможностей языка...
Нет сомнений в том, что это работает, однако же не исключено, что смена дизайна позволит существенно упростить какие-то вещи.
Мне сложно предложить что-то конкретное, т.к. я не вижу картину целиком, но мне точно не очень нравится видеть такое Ну точно же можно заставить компилятор всё это сделать автоматически. Например, если у вас в массиве структуры с полем флаг, то почему бы не писать строкой выше вычислить номер структуры, если требуется получить её из общего номера флага, например..
Это всего-лишь догадка, т.к. я пока не совсем понял, что конкретно должен сделать Ваш код. Просто идея в том, чтобы использовать возможности языка, а не просто манипулировать указателями, на всю катушку пользуясь тем, что язык и это позволяет.
Как-то так, в общем ))

P.S. Очень жаль, что не удастся следить за дискуссией дальше Ближайшие пару дней буду трястись в поезде....

Читаете что я пишу? Всякие там вычисления номера структуры и номера флага в ней раньше как-раз и использовались. А используя битбендинг все превратилось в одну строку на С. При этом использую макрос #define MB_FLAG_SET(a) (*(u32*)(MB_Addr_BB_Coils + a*4) = 1). Ну и что тут не нравится? Зря вы так боитесь приведения типов. Язык не то что "позволяет", а обязан такое позволять. Я к примеру ненавижу использовать union.