поменять местами байты в uint32_t - C/C++

Здравствуйте, Andrew S, Вы писали:

а можешь еще проверить вариант с

                uint32_t a = (p.color >> 24) & 0xFF;
                uint32_t b = (p.color >> 16) & 0xFF;
                uint32_t g = (p.color >> 8) & 0xFF;
                uint32_t r = (p.color >> 0) & 0xFF;

                ColourValue_ARGB p_color = (a << 24) | (r << 16) | (g << 8) | (b << 0);

и

когда идет каст на uint8_t * а не через юнион

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Mr.Delphist, Вы писали:

MD>>2) работа с non-aligned адресами может быть либо хуже с точки зрения перфоманса, либо просто невозможна на данной машинной архитектуре

PD>О каком align может идти речь при работе с байтами ? Для них alignment вроде как всегда 1 ?

Мы все уже привыкли к тому, что байт является минимальной аппаратно адресуемой единицей на всех распространённых CPU, но если говорить о кросс-платформе "по гамбургскому счёту", то я бы не стал упускать из вида всякие хитровывернутые микроконтроллеры, у которых минимально адресуемым может быть WORD или DWORD (проще блок доступа к памяти, меньше заморочек с кешем и т.п.).

IRO>а можешь еще проверить вариант с

IRO>

IRO>                uint32_t a = (p.color >> 24) & 0xFF;
IRO>                uint32_t b = (p.color >> 16) & 0xFF;
IRO>                uint32_t g = (p.color >> 8) & 0xFF;
IRO>                uint32_t r = (p.color >> 0) & 0xFF;

IRO>                ColourValue_ARGB p_color = (a << 24) | (r << 16) | (g << 8) | (b << 0);
IRO>

IRO>и

IRO>когда идет каст на uint8_t * а не через юнион

Это бессмысленно — лучше оптимизировать это компилятор не сможет, а вот хуже — запросто. Вариант с rol будет либо такой же, либо чуть лучше. Так что используйте либо битфилд, либо только требуемые битовые операции

Здравствуйте, Andrew S, Вы писали:

IRO>>а можешь еще проверить вариант с

IRO>>

IRO>>                uint32_t a = (p.color >> 24) & 0xFF;
IRO>>                uint32_t b = (p.color >> 16) & 0xFF;
IRO>>                uint32_t g = (p.color >> 8) & 0xFF;
IRO>>                uint32_t r = (p.color >> 0) & 0xFF;

IRO>>                ColourValue_ARGB p_color = (a << 24) | (r << 16) | (g << 8) | (b << 0);
IRO>>

IRO>>и

IRO>>когда идет каст на uint8_t * а не через юнион

AS>Это бессмысленно — лучше оптимизировать это компилятор не сможет, а вот хуже — запросто. Вариант с rol будет либо такой же, либо чуть лучше. Так что используйте либо битфилд, либо только требуемые битовые операции

.
Мы как всегда отошли от темы топика, если честно изначально меня не интересовало "самое быстрое".
А факт того что по указателю будет медленней чем арифметически. Или даже могут быть проблемы с align или еще какими прелестями. Вот основной посыл который я услышал из всего топика — только то что есть проблемы endian и что компилятор — не будет оптимизировать. с endian понятно, но мой оппонент говорит что в его жизни нету и не будет других кроме как little. А вот "отказ оптимизатора" это весомый аргумент.

Здравствуйте, IROV.., Вы писали:

IRO>как правильней делать?
IRO>преобразовать к uint8_t * и свапнуть 0 и 2 элемент.
IRO>либо делать

явный union и выглядит наиболее "канонично":

uint32_t swap(uint32_t v)
{
  union
  {
    uint32_t v;
    uint8_t b[4];
  } c;
  c.v = v;
  uint8_t x = c.b[0];
  c.b[0] = c.b[2];
  c.b[2] = c.b[0];
  return c.v;
}

и gcc с ним вроде бы самый адекватный результат даёт и для x86 и для arm — http://goo.gl/lHC96I

Здравствуйте, Pavel Dvorkin, Вы писали:

MD>>2) работа с non-aligned адресами может быть либо хуже с точки зрения перфоманса, либо просто невозможна на данной машинной архитектуре
PD>О каком align может идти речь при работе с байтами ? Для них alignment вроде как всегда 1 ?

Не всякая аппаратура умеет адресовать части слов...

Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском

Здравствуйте, Andrew S, Вы писали:

AS>Это бессмысленно — лучше оптимизировать это компилятор не сможет, а вот хуже — запросто. Вариант с rol будет либо такой же, либо чуть лучше. Так что используйте либо битфилд, либо только требуемые битовые операции

.

Битфилд тоже стрёмно, так как переносимых гарантий раскладки полей по битам нет...

Здравствуйте, IROV.., Вы писали:

IRO>Мы как всегда отошли от темы топика, если честно изначально меня не интересовало "самое быстрое".

А какое интересовало? В чём критерий хорошести решений?
И если самое быстрое не интересовало, то почему отказ от оптимизации -- аргумент?

Здравствуйте, IROV.., Вы писали:

IRO>есть

IRO>

IRO>uint32_t color = 0xFFFF00AA;
IRO>

IRO>нужно поменять FF и AA местами

Похоже, меня одного смутила неопределённость вопроса:
Какие FF?
0xFFFF00AA ?
0xFFFF00AA ?
0xFFFF00AA ?

Из разговора о uint8_t как бы понятно, что НЕ средний вариант.

Здравствуйте, VladFein, Вы писали:

VF>Какие FF?
VF>0xFFFF00AA ?
VF>0xFFFF00AA ?

А какая разница?

Меня смутило ещё и то, что не ясно что делать, если там не AA, а что-то другое, 66, например...

IRO>>как правильней делать?
IRO>>преобразовать к uint8_t * и свапнуть 0 и 2 элемент.
IRO>>либо делать

F>явный union и выглядит наиболее "канонично":
F>

F>uint32_t swap(uint32_t v)
F>{
F>  union
F>  {
F>    uint32_t v;
F>    uint8_t b[4];
F>  } c;
F>  c.v = v;
F>  uint8_t x = c.b[0];
F>  c.b[0] = c.b[2];
F>  c.b[2] = c.b[0];
F>  return c.v;
F>}
F>

F>и gcc с ним вроде бы самый адекватный результат даёт и для x86 и для arm — http://goo.gl/lHC96I

Вариат с битфилдами не хуже на gcc и сильно лучше на vc.

AS>>Это бессмысленно — лучше оптимизировать это компилятор не сможет, а вот хуже — запросто. Вариант с rol будет либо такой же, либо чуть лучше. Так что используйте либо битфилд, либо только требуемые битовые операции

.

E>Битфилд тоже стрёмно, так как переносимых гарантий раскладки полей по битам нет...

Скажем так, по опыту это не менее переносимо, чем битовые операции. И как минимум ровно так же эффективно.

Здравствуйте, VladFein, Вы писали:

VF>Здравствуйте, IROV.., Вы писали:

IRO>>есть

IRO>>

IRO>>uint32_t color = 0xFFFF00AA;
IRO>>

IRO>>нужно поменять FF и AA местами

VF>Похоже, меня одного смутила неопределённость вопроса:
VF>Какие FF?
VF>0xFFFF00AA ?
VF>0xFFFF00AA ?
VF>0xFFFF00AA ?
согласен, не корректно.
Но если прочитать вопрос целиком, а не частями то станет ясно что не важно что с чем. А важно как!? и точнее даже не как, а с намеком на то "а не будет ли плохо делать это через указатели" я специально не хотел точную формулировку. Хотел услышать более расширенное мнение людей по данному поводу.
Узнал что бест-практик все таки битовые операции.

VF>Из разговора о uint8_t как бы понятно, что НЕ средний вариант.
не уловил замечание по поводу uint8_t

Здравствуйте, IROV.., Вы писали:

IRO>

IRO>uint8_t a = (color >> 24) & 0xFF;
IRO>uint8_t b = (color >> 16) & 0xFF;
IRO>uint8_t g = (color >> 8) & 0xFF;
IRO>uint8_t r = (color >> 0) & 0xFF;

IRO>uint32_t p_color = (a << 24) + (r << 16) + (g << 8) + (b << 0);
IRO>

Да, кстати, настоящие программисты записывают этот код так:

    uint32_t p_color = (((color >> 030) & 0xFF) << 030) 
                     + (((color >> 000) & 0xFF) << 020)  
                     + (((color >> 010) & 0xFF) << 010)  
                     + (((color >> 020) & 0xFF) << 000);

Здравствуйте, B0FEE664, Вы писали:

BFE>Да, кстати, настоящие программисты записывают этот код так:
BFE>

BFE>    uint32_t p_color = (((color >> 030) & 0xFF) << 030) 
BFE>                     + (((color >> 000) & 0xFF) << 020)  
BFE>                     + (((color >> 010) & 0xFF) << 010)  
BFE>                     + (((color >> 020) & 0xFF) << 000);
BFE>

а как же матерый operator | вместо жалкого operator +?

	От:	IROV..
	Дата:	25.03.15 11:38
	Оценка:

	От:	Mr.Delphist
	Дата:	25.03.15 16:24
	Оценка:	+1

От:	Andrew S	http://alchemy-lab.com
Дата:	25.03.15 22:03
Оценка:

	От:	IROV..
	Дата:	26.03.15 07:42
	Оценка:

	От:	frymode
	Дата:	26.03.15 11:08
	Оценка:

	От:	B0FEE664
	Дата:	27.03.15 10:38
	Оценка:

	От:	Шахтер
	Дата:	28.03.15 10:36
	Оценка: