Формирование int из массива char Опции

[AlexeyT]

Задача такая - есть массив test_buff, из подряд идущих 4-х элементов которого нужно сформировать переменную unsigned int.

unsigned char test_buff[20] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20};
unsigned char *tst_point = &test_buff[0];
unsigned int *tst;

tst = (unsigned int *)(tst_point + 2*sizeof(unsigned char)); //должны получить 0x06050403 = 100992003

Т.е. в *tst пытаюсь записать unsigned int, состоящий из байтов массива с 3-го по 6-й.

При исполнении этого кода на ARM-процессоре (ядро Cortex-M1) происходит зависание ядра (когда обращаюсь к адресу, некратному 4 байтам).
При исполнении этого же кода на ПК - все ок, *tst = 100992003, как и должно быть.
Компилятор Keil.

Есть идеи, как решить задачу?

Сообщение отредактировал AlexeyT - Feb 12 2016, 15:07

[scifi]

Хм, я думал, что там опечатка в коде.

unsigned int *tst;

tst = (unsigned int *)(tst_point + 2*sizeof(unsigned char)); //должны получить 0x06050403 = 100992003

Т.е. в *tst пытаюсь записать unsigned int, состоящий из байтов массива с 3-го по 6-й.

Нет. Этот код указателю tst присваевается адрес элемента другого массива &test_buff[2].

При исполнении этого кода на ARM-процессоре (ядро Cortex-M1) происходит зависание ядра (когда обращаюсь к адресу, некратному 4 байтам).

При исполнении какой конкретно строки кода происходит зависание?

1) Мне нужна int-переменная, состоящая из test_buff[2]...test_buff[5].

Это именно то, что я сделал в этом коде. Или вы int-переменной называете указатель? Ну так вас никто не поймёт, выражайтесь корректно.

[AlexeyT]

Нет. Этот код указателю tst присваевается адрес элемента другого массива &test_buff[2].

Само собой, указателю tst присваивается адрес массива test_buff[2].
При этом значение int-переменной я получаю, обратившись к *tst.

В каком именно месте происходит зависание, сказать не могу, процессор - 1986ВЕ1Т, там с дебагом туго.

Вот полный исходник тестового кода, на котором все виснет:

unsigned char test_buff[20] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20};
unsigned char *tst_point = &test_buff[0];
unsigned int *tst;
unsigned int temp;

tst = (unsigned int *)(tst_point + 2*sizeof(unsigned char)); //должны получить 0x06050403 = 100992003

temp = *tst;

printf("%d", temp);


Сообщение отредактировал AlexeyT - Feb 12 2016, 15:35

[demiurg_spb]

В каком именно месте происходит зависание, сказать не могу, процессор - 1986ВЕ1Т, там с дебагом туго.

Ничего туго там нет.
Пишется обработчик hard_fault и всё...
Главное, перед тем как применять этот проц, прочитать еррату, тогда вообще никаких сюрпризов.

Ну, а на счёт __packed для указателя, то в GCC аналогичного инструментария нет -
изучали эту тему несколько лет назад вдоль и поперёк.
Из того что удалось накопать сейчас - это __builtin_assume_aligned(ptr, align), но пока нет времени вникать как это использовать...

[scifi]

Ну, а на счёт __packed для указателя, то в GCC аналогичного инструментария нет -
изучали эту тему несколько лет назад вдоль и поперёк.

А я не очень-то понимаю, зачем этот инструментарий вообще где-то есть. Всё то же самое легко делается стандартными средствами языка (тот же memcpy), к тому же этот __packed внутри именно так и работает. ИМХО, это поощрение говнокода и привязка к компилятору, что не есть гут.

[Сергей Борщ]

ИМХО, это поощрение говнокода и привязка к компилятору, что не есть гут.

А по мне так наоборот - если происходит действие "обращение по указателю" - то логично было бы использовать предусмотренные для этого в языке средства разыменования указателя, а не захламлять исходник вызовами memcpy(). То, что этот указатель учитывает какие-то аппаратные особенности (невыровненный доступ), логично было бы как-то указать один раз при объявлении указателя (тот же __packed), а не распылять по исходнику в виде memcpy() и надеяться, что программист не забудет именно этот указатель использовать через memcpy().

В gcc можно обернуть искомые данные в упакованную структуру и обращаться по указателю на эту структуру.

[zltigo]

В gcc можно обернуть искомые данные в упакованную структуру и обращаться по указателю на эту структуру.

А поскольку так можно делать на любом компиляторе, то так не только можно, но и следует делать всегда.

[AVI-crak]

Даже в случае безумного С кода, на асме получается необходимый минимум. В даже если проц не может читать/писать не выровненное - этот кусок он обязан выполнить.

Код

    ldr      r1, =адрес_char
    mov     r3, #0
    ldrb    r0, [r1], #4
    add     r3, r3, r0,
    ldrb    r0, [r1], #4
    add     r3, r3, r0, lsl #8
    ldrb    r0, [r1], #4
    add     r3, r3, r0, lsl #16
    ldrb    r0, [r1], #4
    add     r3, r3, r0, lsl #24
    ldr     r1, =адрес_uint32_t
    str     r3, [r1]

Сообщение отредактировал AVI-crak - Feb 15 2016, 15:19

[scifi]

Даже в случае безумного С кода, на асме получается необходимый минимум.

И это тоже. Прогресс в компиляторостроении привёл к тому, что вот эти стенания "а как же эти лишние две инструкции?" - зачастую устаревшая выдумка. Но даже если не так, пара лишних тактов и байтов вредит крайне редко. Короче, "преждевременная оптимизация", если говорить без матюков, но иметь в виду именно их

[jcxz]

И это тоже. Прогресс в компиляторостроении привёл к тому, что вот эти стенания "а как же эти лишние две инструкции?" - зачастую устаревшая выдумка

Типичный аргумент кодера-форточника, создающего шедевры, способные показом обычного диалога загрузить intel-i7 на 100% на минуту.

Но даже не так, пара лишних тактов и байтов вредит крайне редко. Короче, "преждевременная оптимизация", если говорить без матюков, но иметь в виду именно их

Предположим: нужна функция, инкрементирующая пакованный int. С __packed на Cortex-M это будет:

Код

LDR R1, [R0]
ADDS R1, R1, #1
STR R1, [R0]
BX LR

В случае с memcpy будет: создание стекового фрейма, копирование, инкремент, опять копирование, удаление стекового фрейма - итого:
не на пару байт, а во много раз (!!!) дольше + занимает доп.регистры + доп.стек.

[demiurg_spb]

В случае с memcpy будет: создание стекового фрейма...

Такого ужаса уже давно нет.
По крайней мере, в gcc практически все библиотечные функции за'builtin'ены, и компилятор встраивает и разворачивает их максимально гибко, вплоть до того, что sin(const) и иже с ним считается чуть-ли не на этапе препроцессинга и может использоваться даже для инициализации констант.

Код

          typedef struct { uint16_t value __attribute__(( packed ));}unaligned_uint16_t;

          (( unaligned_uint16_t *)EP0Buf)->value = 1;

С выкрутасом решение, но читаемость хромает.
Если запрятать это в макрос, то читаемость поднимется в разы...
Спасибо! Может когда-нибудь пригодится.

[jcxz]

Такого ужаса уже давно нет.
По крайней мере, в gcc практически все библиотечные функции за'builtin'ены, и компилятор встраивает и разворачивает их максимально гибко, вплоть до того, что sin(const) и иже с ним считается чуть-ли не на этапе препроцессинга и может использоваться даже для инициализации констант.

Часто приходится компилить без оптимизации, для отладки и т.п. С отключенной оптимизацией разве развернёт?
Один фиг - писать все эти memcpy() для доступа к одной пакованной переменной - это как раз глупо и слишком громоздко (снижает читаемость исходника).

[_pv]

Один фиг - писать все эти memcpy() для доступа к одной пакованной переменной - это как раз глупо и слишком громоздко (снижает читаемость исходника).

ради одной пакованной переменной писать кучу #if при объявлении, с различными прагмами/атрибутами для разных компиляторов не менее глупо.
лучше уж макрос или инлайн функция которая возвращает нормальный int из невыровненного адреса.

в единственном случае где могут понадобится упакованные структуры и где без этого вполне можно обойтись - в случае с протоколами обмена, там всё равно все доступы к структуре будут обёрнуты в hton / ntoh. ну будет еще одна обёртка для выравнивания, тоже мне проблема.

[zltigo]

ради одной пакованной переменной писать кучу #if при объявлении, с различными прагмами/атрибутами для разных компиляторов не менее глупо.
лучше уж макрос или инлайн функция которая возвращает нормальный int из невыровненного адреса.

Городить какую-то функцию, которая будет разбитаться как именно невыровнен адрес а может и выровнен.... тода уж memcpy() - эта занимается тем-же самым, но понятно, что делает.
И все это ради того, что-бы отвергать великолепный механизм паковки и доступа к структурам. Дурдом. Но понятный после этого заявления:

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

становится понятным, что задачи обмена данными бесконечно далеки от Вас и "контроллеров светодиодов".

, там всё равно все доступы к структуре будут обёрнуты в hton / ntoh.

C какого бодуна, если это зависит от протокола и контрорлера.

[_pv]

Городить какую-то функцию, которая будет разбитаться как именно невыровнен адрес а может и выровнен.... тода уж memcpy() - эта занимается тем-же самым, но понятно, что делает.
И все это ради того, что-бы отвергать великолепный механизм паковки и доступа к структурам. Дурдом.

Этот великолепный механизм - костыли которые в каждом компиляторе сделаны (и хорошо если в каждом) по своему.
Вон у TI, TCP стэк для msp430, как-то обошлись без великолепных механизмов.
И раз уж Вы так близки к задачам обмена данными, не приведёте код объявления упакованной структуры который любой С компилятор поймёт?

C какого бодуна, если это зависит от протокола и контрорлера.

endiannes у всех всех контроллеров вдруг стала одинаковая и так получиться так что она будет отличаться от заданной в протоколе никак не может?

[zltigo]

И раз уж Вы так близки к задачам обмена данными, не приведёте код объявления упакованной структуры который любой С компилятор поймёт?

http://electronix.ru/forum/index.php?showt...st&p=268461

В файлы постепенно добавляете все компиляторы с которыми работаете. Вот так просто.

Вон у TI, TCP стэк для msp430, как-то обошлись без великолепных механизмов.

Не смотрел, по причине наличия уже лет, как 25 своих нескольких стеков. Но охотно верю, что через анус можно сделать все.
Вопрос зачем?

endiannes у всех всех контроллеров вдруг стала одинаковая и так получиться так что она будет отличаться от заданной в протоколе никак не может?

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

...всё равно все доступы к структуре будут обёрнуты в hton / ntoh.

?
Конкретные протоколы могут создаватья и с учетом уже конкретных платформ. Вот я прямо сейчас сочиняю маршрутизируемый для RS485 для трех платформ. Получается на весь протокол одно ntohs() да и то не в явном виде.