<bgdev />^free

|

Хмм, работи ли добре ако предаваш "структурите" като параметри? На теория компилатора може да се сеща, че не са реално структури и да предава стойностите в регистри, но не знам дали е толкова умен все още.

Всичко си работи точно както го очакваш. Сеща се, че са точно по един регистър и си ползва регистрите. Т.е. няма run time penalty но пък има много предимства по време на програмиране - първо не ти позволява да смесиш приравнявания на променливи с различен endianness, второ навсякъде в кода е очевадно, че еди коя си променлива е с еди какъв си endianness.

Те ти малко код да видиш за какво иде реч:

little_big_endian.h

#pragma once

#include <stdint.h>

typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_int64_t { int64_t little_endian; } little_endian_int64_t;
typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_int32_t { int32_t little_endian; } little_endian_int32_t;
typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_int16_t { int16_t little_endian; } little_endian_int16_t;

typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_uint64_t { uint32_t little_endian; } little_endian_uint64_t;
typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_uint32_t { uint32_t little_endian; } little_endian_uint32_t;
typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_uint16_t { uint16_t little_endian; } little_endian_uint16_t;

typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_int64_t { int32_t big_endian; } big_endian_int64_t;
typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_int32_t { int32_t big_endian; } big_endian_int32_t;
typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_int16_t { int16_t big_endian; } big_endian_int16_t;

typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_uint64_t { uint32_t big_endian; } big_endian_uint64_t;
typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_uint32_t { uint32_t big_endian; } big_endian_uint32_t;
typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_uint16_t { uint16_t big_endian; } big_endian_uint16_t;

Предполагам, че нямаш нужда от пример как се ползва. Autocomplete на VIM & VSCode се справят чудесно.

waldorf

Всичко си работи точно както го очакваш. Сеща се, че са точно по един регистър и си ползва регистрите. Т.е. няма run time penalty но пък има много предимства по време на програмиране - първо не ти позволява да смесиш приравнявания на променливи с различен endianness, второ навсякъде в кода е очевадно, че еди коя си променлива е с еди какъв си endianness.

Те ти малко код да видиш за какво иде реч:

little_big_endian.h

#pragma once

#include <stdint.h>

typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_int64_t { int64_t little_endian; } little_endian_int64_t;
typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_int32_t { int32_t little_endian; } little_endian_int32_t;
typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_int16_t { int16_t little_endian; } little_endian_int16_t;

typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_uint64_t { uint32_t little_endian; } little_endian_uint64_t;
typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_uint32_t { uint32_t little_endian; } little_endian_uint32_t;
typedef struct __attribute__((scalar_storage_order("little-endian"))) little_endian_uint16_t { uint16_t little_endian; } little_endian_uint16_t;

typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_int64_t { int32_t big_endian; } big_endian_int64_t;
typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_int32_t { int32_t big_endian; } big_endian_int32_t;
typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_int16_t { int16_t big_endian; } big_endian_int16_t;

typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_uint64_t { uint32_t big_endian; } big_endian_uint64_t;
typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_uint32_t { uint32_t big_endian; } big_endian_uint32_t;
typedef struct __attribute__((scalar_storage_order("big-endian"))) big_endian_uint16_t { uint16_t big_endian; } big_endian_uint16_t;

Предполагам, че нямаш нужда от пример как се ползва. Autocomplete на VIM & VSCode се справят чудесно.

Изглежда доста добре, ще го имам предвид ако ми се налага да правя нещо подобно.

А козоеба ако пусне кода на проекта си, сглобен от краден код, ще му обясним кой ред какво прави та да не се чуди като го питат ганите.

waldorf

Тия дни ми се наложи и на мен да претаквам едни данни с различен endianness и все нещо не ми харесваше докато не изнамерих един gcc атрибут с който се маркират данните в какъв endianness са. Кривото е, че не може да го приложиш на променлива а трябва да го прилагаш на struct или union ... ядосах се и си направих една малка библиотечка little_big_endian.h която огражда 16, 32 и 64 signed и unsigned типове в структури. Получи се повече от добре. Дори по добре отколкото ако беше приложен атрибута директно на променливите защото така навсякъде в сорса където се налага да ги пипаш трябва да пишеш variable.big_endian или variable.little_endian с което е очевадно какво правиш и че на това място ще има обръщане на байтовете - то дори на най скопения Cortex M0 има инструкция де. Та така не ти дреме каква е endiannes на host машината и компилатора винаги си генерира оптимален код. Ще взема да го опън сорсна.

интересно как си се набутал в ситуация с голям индиянец в паметта. големия индианец само моторолата го обича май, но никога не съм позволявал такива данни да ми влязат неконвертирани

|

А козоеба ако пусне кода на проекта си, сглобен от краден код, ще му обясним кой ред какво прави та да не се чуди като го питат ганите.

Ще обясниш как го турят на макя ти чергарска. С МОДЕРЕН фронтенд ще гледаш като мишка в брашно.

Аз щом съм си къстомизирал проекта за мене - имам някаква идея. Махам някои неща - дописвам други.

Тизе не мож го пусна дори на localhost, бих заложил всичко, което имам, ако ти изтрия readme и нямаш нет.

Дон Реба

интересно как си се набутал в ситуация с голям индиянец в паметта. големия индианец само моторолата го обича май, но никога не съм позволявал такива данни да ми влязат неконвертирани

Съществуващ комуникационен протокол. Правя фирмуер за нов сензор за дебит на вода в тръбопроводи. И преди беше с едно викане на htonl или там както бяха тези функции за въртене на байтове. И ако забравиш да ги викнеш и всичко се сговняса. А така няма начин.

|

Изглежда доста добре, ще го имам предвид ако ми се налага да правя нещо подобно.

Винаги ме е кефил минимализма в програмирането, но си иска време човек да изчиства кода. И повечето хора с които работя все бързат и с времето излишно усложняват прости неща докато сложността не надхвърли капацитета на екипа.

waldorf

Винаги ме е кефил минимализма в програмирането, но си иска време човек да изчиства кода. И повечето хора с които работя все бързат и с времето излишно усложняват прости неща докато сложността не надхвърли капацитета на екипа.

150 мегабайта са ми библиотеките на елементарния проект, имам предвид като брой редове. Едва ли има и 1000.

Нищо не сте видели, лумпени малоумни! Написал 20 реда прагми, и вече се има за гений!

|

Давам на ChatGPT (4o) кода на моята библиотека и

За програмиране се ползват reasoning/thinking модели, пробвай го с о1, о3 и т.н. 4о не е подходящ тест