Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: EWARM 5.10
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > IAR
Страницы: 1, 2, 3
Velund
Вопрос к "добычливым"... wink.gif

А плагин под uC/OS с версией 2.10 или выше (которая будет работать с 5.10) не попадался никому?

Может кто нибудь заодно и про uC/Probe чего нибудь скажет толковое? (будете ставить eval - учтите, стучит папе о своей установке, типа лицензию проверяет в онлайне, мелочь, а противно)...
VladislavS
А есть у кого __iar_data_init() в исходниках? А то привык в проекте cstartup.s79 , low_level_init.c и segment_init.c иметь. Пока только щупаю 5.10 - рабочие проекты на него еще не перевожу, но уже подумываю.
VladislavS
А может кто доходчиво объяснить, почему раньше я писал просто и доходчиво

Код
PIOA_PDR = 0x00000001;


То теперь надо наяривать

Код
AT91C_BASE_SYS->PIOA_PDR = 0x00000001;


К чему эта лишняя писанина?

Вот вы говорите, что старые проекты практически сразу завелись на 5.1. У вас в них все так было написано?
Nikola Kirov
Цитата(VladislavS @ Nov 24 2007, 21:14) *
А может кто доходчиво объяснить, почему раньше я писал просто и доходчиво

Код
PIOA_PDR = 0x00000001;


То теперь надо наяривать

Код
AT91C_BASE_SYS->PIOA_PDR = 0x00000001;


загляните в h file для соответного процесора. И в 4.42 не можно написат PIOA_PDR = 0x00000001

можно *AT91C_PIOA_PDR = 0x00000001

ето из фаил для SAM7S64

если захотите сделайте
#define PIOA_PDR *AT91C_PIOA_PDR

и будет работат и так как хотите
VladislavS
Цитата(Nikola Kirov @ Nov 24 2007, 20:27) *
И в 4.42 не можно написат PIOA_PDR = 0x00000001
можно *AT91C_PIOA_PDR = 0x00000001


Про 4.42 я не знал. На 5.1 переползаю еще с 4.40. В хидеры естественно заглядывал - что и как работает понятно. Непонятно ЗАЧЕМ? Неужели для совместимости c другими компиляторами?
VladislavS
Еще один вопрос созрел. Мне нужен файл прошивки в simple-code. В документации вот что сказано:
Цитата
BUILD CONSIDERATIONS
When you build an application that will be downloaded to flash, special consideration
is needed. Two output files must be generated. The first is the usual ELF/DWARF file
out) that provides the debugger with debug and symbol information. The second file
(is a simple-code file (filename extension sim) that will be opened and read by the flash
loader when it downloads the application to flash memory.
The simple-code file must have the same path and name as the ELF/DWARF file except
for the filename extension. This file is automatically generated by the linker.


Когда запускаешь отладку с прописанным флэшлоадером и правда появляется файл в simple-code. Но ведь как-то линкеру передаётся указание его сделать. Мистическое "This file is automatically generated by the linker" не может происходить самом собой. Как линкер узнает что НАДО ДЕЛАТЬ SIM?
zltigo
Цитата(VladislavS @ Nov 24 2007, 19:58) *
Непонятно ЗАЧЕМ? Неужели для совместимости c другими компиляторами?

Упаси бог - "совместимость" ни причем, скорее нарочитая несовместимость для того что-бы непонимающие сути сидели вечно на на одном компиляторе smile.gif. Вообще никогда не стоит пользоваться хидерами "любезно" предоставленными IAR, да и многими другими производителями тоже. Переписываете без специфичных наворотов и пользуетесь c любым компилятором.




Цитата(VladislavS @ Nov 25 2007, 21:59) *
Как линкер узнает что НАДО ДЕЛАТЬ SIM?

Не линкер.
Запускается objcopy и делает чего угодно из выходного файла линкера.
VladislavS
Цитата(zltigo @ Nov 25 2007, 23:47) *
Не линкер.

В приведенной мной цитате говорится что именно линкер.

Цитата
Запускается objcopy и делает чего угодно из выходного файла линкера.

Вот насчет "чего угодно" я что-то не нашел в его хэлпе ключа для simple-code. Не подскажете?
zltigo
Цитата(VladislavS @ Nov 26 2007, 07:10) *
Вот насчет "чего угодно" я что-то не нашел в его хэлпе ключа для simple-code. Не подскажете?

Не пользовался отладкой, не подскажу. Натравите на полученный "simple-code" objdump - что скажет?
VladislavS
Цитата
C:\IAR\EWARM510\ARM\BIN\OBJCOPY.EXE: spi_loader.sim: File format not recognized


Вот. Всёже линкер, но как ему приказать?
zltigo
Цитата(VladislavS @ Nov 26 2007, 14:09) *
Вот.

Вообще-то речь шла об objdump, хотя, видимо и objcopy должен сказать чего-нибудь более разумное.
Цитата
Всёже линкер, но как ему приказать?

Ну так просто посмотрите командные строки линкера в одном и другом случае.
Nikola Kirov
Для 4 версии бъило:
Project Options -> Linker -> Output -> Format -> Debug information for C-SPY -> Allow C-SPY extra output file поставит галочку
Project Options -> Linker -> Extra Output -> Generate Extra Output File поставит галочку
Project Options -> Linker -> Extra Output -> Format -> Output format = simple-code

Для 5 кажется что так
Project Options -> Linker -> Output -> Include debug information in output
файл после компиляции в exe директории с разширением .sim
VladislavS
Цитата(zltigo @ Nov 26 2007, 16:00) *
Вообще-то речь шла об objdump, хотя, видимо и objcopy должен сказать чего-нибудь более разумное.
Ну так просто посмотрите командные строки линкера в одном и другом случае.


objdump вообще как рыба об лёд, а командные строки я первым делом посмотрел - однохренственные до последнего символа.


PS:

С какого он секцию .intvec размером 0x40 размещает с 0x00000000 по 0x00000040 ? Раньше ему для этого хватало 0x00-0x3F и c 0x40 можно было что-то другое размещать. Теперь же только с 0x48.
VladislavS
Цитата(VladislavS @ Nov 26 2007, 16:43) *
С какого он секцию .intvec размером 0x40 размещает с 0x00000000 по 0x00000040 ? Раньше ему для этого хватало 0x00-0x3F и c 0x40 можно было что-то другое размещать. Теперь же только с 0x48.


В 5.11 пофиксили. Теперь .intvec как и прежде умещается в 0x00-0x3F.


Когда выдается совсем свободное время пробую перетаскивать проекты в 5-ю версию. С конфигами и кодом вроде никаких проблем - всё по migration guide получается. Один небольшой проект даже работает на железе. А вот отладка в C-SPY что-то не идет почеловечески никак. Работаю с J-Link. Макросы все те же. Но как-то непредсказуемо отладчик работает. То "застрянет" в любом месте, то наоборот вместо шага понесется дальше, то вообще на какое-нибудь прерывание свалится... И это даже на работающем проекте.
elcielo
I want EWARM 5.11.
plz help me.
KRS
Цитата(VladislavS @ Nov 8 2007, 23:20) *
А есть у кого __iar_data_init() в исходниках? А то привык в проекте cstartup.s79 , low_level_init.c и segment_init.c иметь. Пока только щупаю 5.10 - рабочие проекты на него еще не перевожу, но уже подумываю.


Т.к. пока приходится отлаживать через openOCD (в IAR 5.11 есть поддержка GDB server). Пришлось переходить на 5 IAR. Я тоже люблю цеплять свой стартап. Поэтому разобрался с принципиальным отличием 5 от перыдущих.
Раньше необходимые данные для инициализации сегментов генерил компилер в виде:
Код
PUBWEAK ?init?tab?DATA_Z
        RSEG INITTAB:CODE:ROOT(2)
        DATA
?init?tab?DATA_Z:
        DCD      sfe(DATA_Z) - sfb(DATA_Z), sfb(DATA_Z), sfb(DATA_Z)

        PUBWEAK ?init?tab?DATA_I
        RSEG DATA_ID:CONST:SORT:NOROOT(2)
`?*?DATA_ID`:

        RSEG INITTAB:CODE:ROOT(2)
        DATA
?init?tab?DATA_I:
        DCD      sfe(DATA_I) - sfb(DATA_I), sfb(DATA_I), sfb(DATA_ID)

        END

и т.п. всякими хитрыми метками и директивами. что бы полностью выкинуть этот стартап. можно было в своем стартапе определить
Код
        PUBLIC ?init?tab?DATA_I
?init?tab?DATA_I:
        PUBLIC ?init?tab?DATA_Z
?init?tab?DATA_Z:

и сегмент INITTAB не создавался и можно спокойно было инитить сегменты или не инитить...

Теперь принципиально идеология не поменялась просто все это свалили на линкер, поэтому он и не стандартный. Линкер генерит аналог INITTAB ( в который еще похоже добавили адрес функции инициализирующей...).

Но есть способ просто от этого всего избавится!
использовать do not initialize ( в том числе и для DATA_Z и заполнять 0 самому)
и initialize manually для сегментов, которые надо копировать (из флеша например)
ну и указать имя точки входа Override default program entry.

Для Coretx-M3 вообще можно обойтись без ASM, т.к. стек изначально сам проц инитит

Код
uint32_t const __vector_table@".intvec" =
{
    STACK_TOP,
    (uint32_t)main,
            ......
};

а в icf файле
place at start of ROM { section .intvec};
IgorKossak
Цитата(elcielo @ Dec 24 2007, 08:43) *
I want EWARM 5.11.
plz help me.

Download 30-day evaluation edition, V5.11
Vitaliy_ARM
Недавно заметил тут такую штуку.
Создаю структуру:

typedef struct _MY_STRUCT
{
BYTE Cmd;
BYTE Rsv;
WORD K1;
DWORD Status;
BYTE K2;
}MY_STRUCT, *pMY_STRUCT;

BYTE TxData[100];
pMY_STRUCT pMyStr = TxData;
-----
делаю вызов функции Func(TxData, sizeof(MY_STRUCT));

И вижу, что sizeof(MY_STRUCT) возвращает не 9 (как написано в книжках по C/C++), а 12!
Понятно, что это делается для выравнивания данных в OЗУ по 4 байтным словам.
Жутко не удобно постоянно для каждой структуры объявлять длину через дерективы препроцессора.
Может можно это отключить, и сделать так, чтобы sizeof() возвращал количество байт?
KRS
Цитата(Vitaliy_ARM @ Mar 18 2008, 12:10) *
И вижу, что sizeof(MY_STRUCT) возвращает не 9 (как написано в книжках по C/C++), а 12!
Понятно, что это делается для выравнивания данных в OЗУ по 4 байтным словам.
Жутко не удобно постоянно для каждой структуры объявлять длину через дерективы препроцессора.

Это делается по стандарту, что бы структуры можно было объеденить в массив. (данные внутри одной структуры и так выравнены)
Единтсвенный известный мне способ - это #pragma pack. Но при этом если обращаться к такой структуре через указатель будет большой оверхид потому что компилер не будет знать выравнена она или нет.
Vitaliy_ARM
Цитата(KRS @ Mar 18 2008, 12:24) *
Это делается по стандарту, что бы структуры можно было объеденить в массив. (данные внутри одной структуры и так выравнены)
Единтсвенный известный мне способ - это #pragma pack. Но при этом если обращаться к такой структуре через указатель будет большой оверхид потому что компилер не будет знать выравнена она или нет.


Думаю придется обойтись директивами. Не хочется лишний раз использовать #pragma.
KRS
Цитата(Vitaliy_ARM @ Mar 18 2008, 12:34) *
Думаю придется обойтись директивами. Не хочется лишний раз использовать #pragma.

Ну тут можно использовать стандартную фичу С99 _Pragma() внутри #define. Но IMHO главное на что надо обратить внимание это на тормознутый код при обращении через указатель к 16 и 32 битным полям именно по этому pack в данном случае лучше не использовать.
zltigo
Цитата(Vitaliy_ARM @ Mar 18 2008, 12:10) *
Может можно это отключить, и сделать так, чтобы sizeof() возвращал количество байт?

Бессмысленность какая-то НУ ЗАЧЕМ ИМЕТЬ некое абстрактное число, которое, Вы называете "КОЛИЧЕСТВО БАЙТ", если оно НЕ СООТВЕТСТВУЕТ реальному состоянию дел? sizeof() возвращает именно количество байт занимаемое структурой. Для чего понадобилось-бы число байт которое-бы занимала-бы структура если-бы была-бы упакована я ума не приложу - откройте тайну! Заодно еще один вопрос - а причем тут тема EWARM 5.10 ?
Vitaliy_ARM
Цитата(zltigo @ Mar 18 2008, 19:39) *
Бессмысленность какая-то НУ ЗАЧЕМ ИМЕТЬ некое абстрактное число, которое, Вы называете "КОЛИЧЕСТВО БАЙТ", если оно НЕ СООТВЕТСТВУЕТ реальному состоянию дел? sizeof() возвращает именно количество байт занимаемое структурой. Для чего понадобилось-бы число байт которое-бы занимала-бы структура если-бы была-бы упакована я ума не приложу - откройте тайну! Заодно еще один вопрос - а причем тут тема EWARM 5.10 ?


С программе больше 70 различных структур данных, которые в итоге, в зависимости от состояния программы, отправляются одной и той же функцией по RS232. Причем данные в структурах периодически меняются, но всегда выровнены по DWORD, за исключением байтовых концовок.
Причем содержимое(размер) структур колеблется при написании программы. Есть функция, которая умеет тупо передавать массив байт. При отправке указатель на структуру приводится к BYTE*, и еще указывается длина (все как обычно). Вот и хотел избавить себя от рутинной работы измерения размера структуры каждый раз при ее изменении и прописывания ее размера через константу в #define. Но как выяснилось, такое сделать не получается в принципе
zltigo
Цитата(Vitaliy_ARM @ Mar 18 2008, 21:24) *
...отправляются одной и той же функцией по RS232.
Есть функция, которая умеет тупо передавать массив байт. При отправке указатель на структуру приводится к BYTE*, и еще указывается длина (все как обычно).

Ну и чем, этой функции передачи, простите, поможет знание того, что в структре есть XX байтов, которые нужно выковырять и переслать? Все равно БЕЗ ЗНАНИЯ СТРУКТУРЫ только по XX функция передачи не сможет из извлечь. А если она знает структуру, то на кой ей сдалось какое-то число байтов живописно в этой структуре расположенных. Посему вопрос остался открытым - зачем?
В таких случаях несмотря на поигрыш в быстродействии идут на паковку структур. Получается просто и беспроблемно принимать-передавать. В конце концов все не так и срашно c паковкой - Вы ведь работаете со строками, например?
Цитата
Но как выяснилось, такое сделать не получается в принципе

Пока не выяснилось, как Вы себе представляете выковыривание значащих байтов из неупакованной структуры НЕ располагая знаниями о самой структуре.
Vitaliy_ARM
Цитата(zltigo @ Mar 18 2008, 21:42) *
Пока не выяснилось, как Вы себе представляете выковыривание значащих байтов из неупакованной структуры НЕ располагая знаниями о самой структуре.


Я не хочу ковырять байты, для этого пустоты ликвидировал,
уже писал, что все структуры выровнены, например так:

struct MyStr
{
BYTE P1;
BYTE P2;
WORD Z1;
DWORD Z2;
DWORD Z3;
BYTE K1;
}

Вот эта структура выровнена, потому что в ней все данные находятся в нужных местах и дыр в ней нет. Длина ее 13 байт, а область памяти, которую выделит компановщик, будет 16 байт. Передавать надо по GPRS, поэтому плодить лишьний трафик не выгодно. Собственно мне не хотелось еще плодить дополнительные директивы для определения длины каждой структуры. Которые потом надо еще не забыть поменять.
zltigo
Цитата(Vitaliy_ARM @ Mar 18 2008, 22:02) *
Вот эта структура выровнена, потому что в ней все данные находятся в нужных местах и дыр в ней нет.

Дыры в ней ЕСТЬ о чем Вам и говорит sizeof(). Хотите получить 13 - #pragma pack Вам в помощь.
MALLOY2
Код
struct MyStr
{
BYTE P1;
BYTE P2;
WORD Z1;
DWORD Z2;
DWORD Z3;
BYTE K1;
ДЫРКА 1;
ДЫРКА 2;
ДЫРКА 3;
}


smile.gif

Выход конечно есть , обьявляете массив из 13 байт, а далее через приведение типов. Но в будущем если понадобится изменить структру или она выростит или еще что то, проблемы гарантированы.

Код
char buff[13];
((struct MyStr*)buff)->P1 = 0xFF;
zltigo
Цитата(MALLOY2 @ Mar 19 2008, 10:05) *
Выход конечно есть..

Выход это официальная, четкая, ясная, переносимая и т.д...паковка структур а не построения предположений о размещении элементов в неупакованной структуре и ее размерах. Ну получили 16 байт, а получить на законных основаниях 24 не хотите?
MALLOY2
Цитата(zltigo @ Mar 19 2008, 11:47) *
Ну получили 16 байт, а получить на законных основаниях 24 не хотите?


Обьясните ?
zltigo
Цитата(MALLOY2 @ Mar 19 2008, 11:00) *
Обьясните ?

Что объяснить? Что компилятор имеет право выделять каждой из переменных неупакованной структуры, например, по 32 бита?
MALLOY2
Цитата
Что объяснить? Что компилятор имеет право выделять каждой из переменных неупакованной структуры, например, по 32 бита?


1. Мы ведь в ветке IAR, значит речь идет о нем, следовательно читаем как он пакует структуры.
2. Я еще не видел в жизни компилятора который для структуры из 4 байт выделил бы 16 байт памяти smile.gif
3. Выравнивание структуры подрузумевает размещение переменных согластно их типу по нужному для этого типа адресу + учитывается архитектура ядра (не все ядра умеют работать с байтами, но это уже отдельный случай), а не просто создание размера струкруры кратной кокогото размера.

Вывод НЕ ИМЕЕТ такого права, если конечно потдерживает стандарт.
zltigo
Цитата(MALLOY2 @ Mar 19 2008, 11:12) *
Вывод НЕ ИМЕЕТ такого права, если конечно потдерживает стандарт.

Тогда пречитайте свой-же п.3, (только до того места, когда началась явная отсебятина) - "Выравнивание структуры подрузумевает размещение переменных согластно их типу по нужному для этого типа адресу + учитывается архитектура ядра".
В который (последний, ибо утомило sad.gif ) раз спрашиваю, зачем отдавая паковку на опкуп компилятору пытатся после этого перехитрить и компилятор, и себя, и сетовать на разработчиков языка, если предусмотрено УПРАВЛЕНИЕ паковкой структур???
MALLOY2
Цитата
который (последний, ибо утомило ) раз спрашиваю, зачем отдавая паковку на опкуп компилятору пытатся после этого перехитрить и компилятор, и себя, и сетовать на разработчиков языка, если предусмотрено УПРАВЛЕНИЕ паковкой структур???



Производительность !. Код с упакованными структурами меделеннее и более емкий. так как компилятор начинает с структурой по байтово работать.

Расмотрим такой вариант.

Есть некий интерфейс скажем UART. Он умеет отсылать массив данных.

Прототип
Код
u32_t uart_send (void *data, u32_t len);    

u32_t uart_rcv (void *data, u32_t len);


Чисто гипотетически выдумаем протокол.
Структура протокола

u8_t prot_type;
u8_t paket_len;
u16_t cmd;
u32_t parametrs;
u16_t crc;
u8_t data[x]; //где x это поле данных которое имеет переменную длинну указанную в paket_len;

Сточки зрения структур "С" его надо упаковывать. Но у него все поля выравнены, и с точки зрения программы на ASM никакого выравнивания не надо так как все поля находятся с учетом алигна на своих адресах.

Имеем следующую функцию
Код
void Device_Send_Cmd(Cmd, Parametrs, char *data, u8_t len)
{
   char send_buff[SEND_BUFF_SIZE];
   char *data_ptr;
   u32_t i;
  
   ((struct MyStr*)send_buff)->prot_type = MY_PROTOCOL;
   ((struct MyStr*)send_buff)->paket_len = len
   ((struct MyStr*)send_buff)->cmd = Cmd;
   ((struct MyStr*)send_buff)->parametrs= Parametrs;
   ((struct MyStr*)send_buff)->crc = crc_update(...);
   data_ptr = &send_buff[11];       //это не достакок размер структуры нужно посчитать самому и подставить нужное смещение для данных;
   for (i=0;i<len; len++) *data_ptr++ = *data++;  
   uart_send(send_buff, len+11);   //тут тоже кривовато, но можно все вынести в дефайн  
}


Вот на таком примере можете посмотреть на листинг функции с упакованной структорой и нет.

И раскажите в чем выиграш упаковки, в переносимости ? удобстве ? за все это можно заплать ценой более мощного контроллера или кричать что на С код большой и начинать функцию писать на асме, что приведет к полной потере переносимости. Иногда удорожание девайса на 10 центов недопустимо.

Исключением составляют 8 битные процессоры на них код будет одинаковый что с упакованной структурой что нет.

Цитата
пытатся после этого перехитрить и компилятор, и себя, и сетовать на разработчиков языка

Ну это уже проблемы сугобо личные...

P.S. отредактировал под автора
Vitaliy_ARM
Цитата(MALLOY2 @ Mar 19 2008, 10:05) *
Выход конечно есть , обьявляете массив из 13 байт, а далее через приведение типов. Но в будущем если понадобится изменить структру или она выростит или еще что то, проблемы гарантированы.


Собственно примерно так и работал.
В итоге получается что при использовании структур нарушается переносимость кода с платформы на платформу. Например один и тот же код под AVR будет компилироваться без проблем, Под ARM уже могут быть дыры, если элементы структуры не выровнены. Получается для более менее хорошей переносимости необходимо ориентироваться на старший процессор.
MALLOY2
Цитата(Vitaliy_ARM @ Mar 19 2008, 16:59) *
Собственно примерно так и работал.
В итоге получается что при использовании структур нарушается переносимость кода с платформы на платформу. Например один и тот же код под AVR будет компилироваться без проблем, Под ARM уже могут быть дыры, если элементы структуры не выровнены. Получается для более менее хорошей переносимости необходимо ориентироваться на старший процессор.



Что бы получить кросс платформенность при обмене с внешним миром, без кучи кучи настроек не обойдетесь, так как ядрабывают разные, бывает с разным представление чисел в памяти (LITE ENDIAN & BIG ENDIAN), есть у которых минимальная еденица (char) 16 бит - TMS320VC5502 и т.д. завта появятся 64 битные и т.д.

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

Код
#define STRUCT_FILED_SIZE(filed)   sizeof(((struct MyStr*)0)->field)  
void Device_Send_Cmd(Cmd, Parametrs, char *data, u8_t len)
{
   char send_buff[SEND_BUFF_SIZE];
   char *data_ptr;
   u32_t i;
   head_len = 0;
  
   ((struct MyStr*)send_buff)->prot_type = MY_PROTOCOL;
    head_len += STRUCT_FILED_SIZE(prot_type);
   ((struct MyStr*)send_buff)->paket_len = len
   head_len += STRUCT_FILED_SIZE(paket_len);
   ((struct MyStr*)send_buff)->cmd = Cmd;
    head_len += STRUCT_FILED_SIZE(cmd);
   ((struct MyStr*)send_buff)->parametrs= Parametrs;
   head_len += STRUCT_FILED_SIZE(parametrs);
   ((struct MyStr*)send_buff)->crc = crc_update(...);
   head_len += STRUCT_FILED_SIZE(crc);
   data_ptr = &send_buff[head_len];
   for (i=0;i<len; len++) *data_ptr++ = *data++;  
   uart_send(send_buff, len+head_len);
}
Сергей Борщ
Цитата(MALLOY2 @ Mar 19 2008, 14:30) *
Производительность !. Код с упакованными структурами меделеннее и более емкий. так как компилятор начинает с структурой по байтово работать.
Так сделайте два варианта структур - один неупакованный для работы и второй упакованный для передачи. Упакованная структура может иметь единственный конструктор с неупакованной в качестве аргумента. Да, придется для каждого типа вручную написать присваивание всех полей. Но это действительно переносимый способ и рыбку съесть и ... дальше вы знаете.
zltigo
Цитата(MALLOY2 @ Mar 19 2008, 15:30) *
Производительность !. Код с упакованными структурами меделеннее и более емкий. так как компилятор начинает с структурой по байтово работать.

Абсолютно не о том - в данном случае автор имеет НЕЯВНО УПАКОВАННУЮ структуру - подобрал последовательность полей до получения УПАКОВКИ, которая его устраивает. Работает точно так-же, как и явно упакованная структура. Только с упоством достойным лучшего применения ни он ни Вы не желаете явно указать компилятору паковать структуру и получить реальный sizeof() этой структуры.
Vitaliy_ARM
Цитата(zltigo @ Mar 19 2008, 18:31) *
Абсолютно не о том - в данном случае автор имеет НЕЯВНО УПАКОВАННУЮ структуру - подобрал последовательность полей до получения УПАКОВКИ, которая его устраивает. Работает точно так-же, как и явно упакованная структура. Только с упоством достойным лучшего применения ни он ни Вы не желаете явно указать компилятору паковать структуру и получить реальный sizeof() этой структуры.


Я против применения расширений компилятора, применяю только в исключительных случаях. Сегодня один компилятор хорош, завтра другой, у одного можно так сделать у другого нельзя. А переползать с такими директивами с компилятора на компилятор не весело. Поэтому предпочел обойтись
#define STRUCT1_SIZE 10
дабы стандартного способа измерить структуру (т.е. размер объявленных переменных в ней (в выровненной )) с точностью до байта автоматически при компиляции не оказалось.
zltigo
Цитата(Vitaliy_ARM @ Mar 20 2008, 18:09) *
Поэтому предпочел обойтись
#define STRUCT1_SIZE 10

Каждый сам себе Буратино, но хуже варианта я даже представить не могу. Собственно это даже не "вариант" - это манипуляции с бубном.
Vitaliy_ARM
Цитата(zltigo @ Mar 20 2008, 18:15) *
Каждый сам себе Буратино, но хуже варианта я даже представить не могу. Собственно это даже не "вариант" - это манипуляции с бубном.



Предложите вариант лучше без использования IAR-ских спец. директив
zltigo
Цитата(Vitaliy_ARM @ Mar 20 2008, 18:18) *
Предложите вариант лучше без использования IAR-ских спец. директив

Не сочтите за труд, наконец прочитать ответ на Ваш вопрос и подумать над тем использовать-ли абсолютно не документированные и именно IAR-овские и конкретно не переносимые реализации паковки структрур, причем дополненнные абсолютно мутными крнстантами, либо использовать совершенно НЕ IAR-овский и имеющийся абсолютно у всех не 8-бит компиляторов механизм паковки структур.
Sapienti Sat.
Vitaliy_ARM
Цитата(zltigo @ Mar 20 2008, 18:45) *
Не сочтите за труд, наконец прочитать ответ на Ваш вопрос и подумать над тем использовать-ли абсолютно не документированные и именно IAR-овские и конкретно не переносимые реализации паковки структрур, причем дополненнные абсолютно мутными крнстантами, либо использовать совершенно НЕ IAR-овский и имеющийся абсолютно у всех не 8-бит компиляторов механизм паковки структур.


Прочитал, подумал, проверил:

Код
#pragma pack(1)
    struct First
{
  char alpha;
  DWORD beta;
};

struct First dataa;

dataa.alpha = 0;
dataa.beta = 0x2134;


на последние две строчки уходит около 18 команд (побайтная обработка).

если так
Код
//#pragma pack(1)

тогда 5 тактов.

А если сделать так:
#pragma pack(1)
struct First
{
DWORD beta;
char alpha;
};

Получились те же 5 тактов и sizeof(dataa) дает 5 байт.
Получается последний вариант самый лучший, и скорость таже и sizeof(работает). Вывод: в моем случае самому заботиться о выравнивании и использовать паковку.
Просмотрел ссылки, как эта http://electronix.ru/forum/lofiversion/index.php/t30833.html и должен признать, этот вариант лучше. Паковка есть практически во всех компиляторах.
zltigo
Цитата(Vitaliy_ARM @ Mar 20 2008, 19:40) *
Получается последний вариант самый лучший...

Ура!!! Вот тут http://electronix.ru/forum/index.php?showt...6&hl=packon есть подарочек для бездумной переносимости на разные компиляторы - ваял под все мной используемые:
PACK_on_off.rar
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.