Как получить Offset поля в классе?
Впринципе это вопрос общего назначения, но для уточнения, я пишу под WinAVR.
При применении ассемблерных вставок в C++ для работы со структурами появляется необходимость взятия переменной относительно какого-то объекта (указателя), например:
LDD R0, Y+OFFSET(T::i)
Написал define:
#define OFFSETT(Type, Item) ((int)(&((Type *)0)->Item))
Что впринципе и возврящает необходимую константу. В С++ такой прикол проканывает, в асме старого компилятора тоже, а в новом начинает через один ворчать, мол не константа это.
Подскажите, может есть какие нибудь иные способы решения?

надо посмотреть как в заголовочных файлах нового компилятора определен макрос offsetof(). Настораживает, что компилятор у вас ругается не на каждое выражение, а через одно. Может неспроста? Приведите пример, на который компилятор ругается.

А чем не устраивает gcc-стандартное указание входных/выходных параметров в ассемблерной вставке



Или в более сложных случаях эффективность падает?

Дефайна offsetof в WinAVR-е вообще нет, наверное его забыли. Но это не суть, впринцыпе я написал его-же.
Все хорошо, все правильно, но компилятор ругается, притом через раз. Вот пример:

Функции LDD, CPI, ... - это есть дефайны ассемблерных вставок, например:

Компилятор выдает ошибки на строки 4 и 8 (именно те две строки, где используются два одинаковых offsetof(TMultiBus, Echo)), остальные строки проходят нормально.
error: impossible constraint in 'asm'

Вот я и хочу спросить, есть ли какие нибудь другие варианты?

Это как сказать

Изучите файлик stddef.h

Какое смещение до поля Echo?

Анатолий.

Вот с этого и надо было начинать. В ошибке ведь все сказано. Идете в c:/WinAVR/DOC/avr-libc/avr-libc-user-manual, находите там руководство по inline-ассемблеру, и в нем видите, что с инструкцией ldd должны использоваться констранты (это как-то переводится?) r и b, а не r и e, как у вас.

Переводится так:
А вот как это выглядит в контексте сообщения ...

"Ограничитель"? Какой бы термин мы ни приняли, это будет наше сугубо внутреннее дело Интересовало, есть ли общепринятый перевод для этого термина. Если нет - придется использовать без перевода.

Переводится как на инструкцию LDD накладываются ограничения dest - r, src - base pointer y, z.

Что кстати весьма странно, ведь эта инструкция может работать и с x регистром.

Не может, нет инструкции LDD Rd, X+q; есть только LD Rd, [-]X[+]



Я не экстрасенс, а автор не привел описание структуры (класа?) TMultiBus но все же рискну погадать.

Скорее всего структура довольно большая и offsetof(TMultiBus, Echo) больше 63, что больше ограничения накладываемого constraint "I" (константа от 0 до 63). На что и ругается компилятор.

Анатолий.

Сообщение отредактировал aesok - Oct 15 2008, 20:09

Огромное спасибо за такую поддержку, но пока это все косвенные причины, каторые можно опровергнуть:
1:
Да я согласен, что я здесь ошибся определив переменную-указатель в e а не в b, но переменная уже лежит в регистре Y, да и другие команды-то компилируются. (Подправлю, но это не то).
2:
Нет структура довольно маленькая и смещение равно 18.

И третье: если закоментарить 8 строку в приведенном отрывке, то и 4 строка компилируется нормально. А если далее по тексту написать
STD(Bus, StatusO, offsetof(TMultiBus, StatusO)); //Bus->StatusO = StatusO;
то компилятор начинает ворчать на 1 строку и на новую.

Ivan
Сорри за нескромный вопрос. Для чего Вы хотите смешать C++ с asm? Ведь от этого только переносимость и читаемость кода пострадает. Выигрышь в производительности весьма сомнительный.

Тем более это странно, после того, как я показал, что макрос offsetof уже есть в stddef.h
Его можно изучить поглядев на stddef.h из MS Visual Studio или C-builder.

Согласен, совместимость и читабельность ухудьшается, а выигрыш довольно большой. Даже если взять текуший отлаженный, вылизанный ассемблерный код и перевести его на С/С++ диву даешься, что компилятор вытваряет, сердце кровью обливается. Я тут такты экономлю, а он такой код раздувает.
Задача, каторую я решаю - это протокол на основе RS485 интерфейса работающий на скорости 115200.
Это давольно умный протокол в катором все устройства являются главными и могут говорить в любой момент кому угодно. Для таких возможностей появляется необходимость выявления занятости линии и определения кализий на линии. Каждый контроллер должен успевать, по приему каждого байта, определять кому, от кого летит пакет, подсчитывать контрольную сумму и так далее.
А теперь представим, что у главного контроллера есть два таких интерфейса, и по обоим летят пакеты и все это нужно успеть при тактовой чистоте 14МГц. При старой организации на С, в самых сложных случаях (когда контроллер передает в оба интерфейса одновременно, а значит и принимает для определения кализий) это занимало 2/3 процессорного времени, а сейчас 1/3. Объем кода снижен с 5К до 2К, а для atmega8 это существенно.