Работает ли flatbuffers на архитектурах, где байт занимает 16 или 32 бита?

Question

[Юрий]

Похоже, что flatbuffers ориентирован на архитектуры, где есть адресация по 8 бит. Можно ли его адаптировать под другие архитектуры, например, где байт занимает 16 или 32 бита? Точнее не адаптировать, а взять готовое решение?

Comments

[Robur]

что flatbuffers ориентирован на архитектуры, где есть адресация по 8 бит.

почему вы так думаете?

[Юрий]

Смотрел на GitHub немного FlatCC - компилятор для С (хотелось бы, чтобы сериализатор работал в том числе и на контроллерах, где нет STL). Как я понял, они достигают быстродействие сериализации благодаря тому, что не упаковывают/распаковывают данные, а передают структуры, как есть, т.е. с естественным выравниванием структур (с дырками). Доступ к полям обеспечивают простым смещением указателя. Так понял, что на разных языках структуры данных выравниваются одинаково. Они этим и пользуются. Но правила выравнивания ориентированы на х86, где есть адресация по байтам (точнее по 8-битам, т.к. байт может состоять из другого количества бит). Это значит, что в других системах (где адресация другая или бигэндиан) придется таки переупаковывать и терять производительность.

Ну ладно бы с производительностью.. Я бы пошел на это, если бы был сериализатор готовым. Но их FlatCC не умеет этого. Например, разработчики сильно удивились, что в некоторых компиляторах нет типа int8_t, а только int16_t или даже int32_t и выше. А у них все заточено на int8_t. Мне же предложили самому все закодить, написать документацию и вступить в их ряды. Но у меня нет ресурсов для этого. Нужно готовое решение. Кстати ветку с нашим обсуждением они быстро закрыли.

[AlexHell]

если у вас специализированная задача, и работать оно будет на спец оборудовании, врятли оно надо "всем" - т.е разрабатывать, поддерживать, документировать, тестировать - тем разработчикам просто "нет ресурсов" (также как и вам)

имхо вам стоит сделать чтото свое, зачем вам flatbuffers? можете же специально для своей архитектуры сделать свою сериализацию только нужных вам структур, не унивсальную даже, зачем вам компиляция и процессинг кода? пишите руками - специально на ваш проект
т.е сделайте нужную структуру на С, в нужными полями, и сериализуйте ее в файл, а на приемнике де-сериализуйте в такуюже структуру

[Юрий]

AlexHell: "можете же специально для своей архитектуры сделать свою сериализацию только нужных вам структур..."

Собственно, так и было сделано. Мы взяли в качестве стандарта структуры С/С++ и ими описали сообщения в сети между абонентами. Придумали правила, формирования структур, чтобы было одинаковое выравнивание на разных архитектурах (на 16-ти и на 32-разрядных контроллерах/процессорах).

Этого вполне хватало, пока мы работали в рамках одного проекта (назовем это беспилотником, на борту которого около десятка процессоров и пара десятков контроллеров). Мы, как головники, определили общие правила (стандарт) сети, а для каждого абонента - свой вход/выход в виде структур на С/С++. Контрагентов поставили перед фактом в виде ТЗ, и они его вынуждены отрабатывать. К тому же все программы для таких задач (эмбэд) пишутся на С/С++. Пару таких машин довели до серийного производства. Все прекрасно.

Но вот встали задачи пошире. Задача уровня носителя подобных беспилотников (на два порядка масштабнее система) и взаимодействия разнородных беспилотников между собой и с носителями. Т. е. много разных команд разработчиков, разных технологий, разных школ. Дикая каша получается. Всех заставить плясать под одну дудку не получается. Да и дудка наша (упоминавшийся выше подход) оказалась не вполне универсальной для новой задачи и мы не головники.

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

У нас тупиковая ситуация получается: каждый разработчик лепит так, как ему нравится, как привык. И отвечает только за свою частную задачу. Системные задачи, которые по своей сути везде одинаковые, решаются каждым разработчиком по разному (изобретается велосипед). Лепить в одну систему такие устройства невозможно. Разработка затягивается на десятилетия, а модернизационный потенциал никакой. Чтобы новую функцию (подсистему) добавить нужно перепроектировать все заново.

Американы лет 20 назад решили для себя эту проблему, внедрив единый обязательный стандарт DDS. Т.н. middleware, которое работает поверх разных физических коммуникаций, поверх разных ОС, на разных языках программирования. Один из камней в фундаменте DDS - язык IDL описания данных, передаваемых по сети (причем без вызова удаленных процедур, просто данные).

Казалось бы что проще - описать структуру данных на неком абстрактном языке, которую потом транслировать в нужный язык программирования. Но это превращается в такого монстра! От С они вообще отказались. На С++ во всю используют STL, которая практически не используется в системах реального времени (из-за тяжеловестности и низкой скорости), не говоря уже о микроконтроллерах. Короче, как я понял, DDS для тяжелых ОС типа Линукса и пр.

Хочется чего-то легкого. Но, к своему удивлению, не нашел подходящего. Больше всего привлек flatbuffers. У них есть даже компилятор в С (не в С++). Но они рассматривают, похоже, только настольные системы, о чем я писал в первом посте.

Короче, я вижу колоссальную (я бы сказал даже экзестенциальную) необходимость в middleware для интеграции систем реального времени. И первым кирпичом в ней вижу язык описания данных (с соответсвующими компиляторами под С, С++, Java и пр.).

Хочется, чтобы язык был простым и легким. Чтобы на микроконтроллерах можно было использовать.

[AlexHell]

Юрий, классную историю вы описали, я только не пойму почему у вас "нет ресурсов"? сами же пишите что переходите к большому проекту, много людей, каждый изобретал велосипед а теперь будет эффективней, в чем собственно проблема выделить команду и написать сначала нужный вам middleware, а потом на его основе пилить большой проект?

[Юрий]

Удивительно, что вам не понятно?

Во-первых проект еще не начался. Назревает. Во-вторых, мы не головники. Не можем диктовать. А в третьих, и это главное, где вы видели у нас много специалистов? Команды есть, но специфические. Как в Союзе. Даже хуже. На сто чиновников один специалист. В ряде направлений ситуация доходит до того, что один-два человека на всю страну владеют технологией. И им, как правило, за 70.

Чтобы было нагляднее скажу, что всю математику и все ПО для упомянутого мною аппарата разработал один человек. Хотя вокруг крутились сотни каких-то чиновников.

И еще пример. Считается, что разработка математики и ПО ничего не стоит. Оно как-то само собой появляется. Ресурсов не требует. Главное железяку выточить.

Все руководство, включая главных конструкторов, некомпетентно. Это чиновники. Попробуйте им объяснить, что такое мидлвэрэ. Что оно очень важно, надо много сил затратить... Он сделает круглые глаза и скажет: "Но ведь делают же без этого! А когда сделаете, то как его пощупать?" Попробуйте объяснить это, например, полковнику полиции.

Неужели вам не знакома картина? Сплошь и рядом.

Между прочим у Боинга подобная ситуация в космонавтике. Чтобы что-то небольшое изменить - сумасшедшие миллиарды государство должно потратить. Такой себе монстр-монополист. Как при социализме. Не зря у них правительство Маска продвигает. С огромным трудом, между прочим. Хотят конкурентный рынок создать. Но там правительство хоть понимает, что нужно делать! Они дельцы. Деньги умеют считать.

Ну и подобная мидлвэрэ не такая уж простая задача, чтобы вечерком ее решить. Амеры лет 15 возились с ней, прежде чем выйти на стандарт. Причем очень серьезные фирмы и ресурсы задействовались. Поинтересуйтесь про историю модернизации крейсеров Тикандерога.

Я сейчас не занимаюсь разработкой такого мидлвэра. И не понятно буду ли. Просто наблюдаю провал в отрасли. Хочу для себя оценить задачу, найти правильные идеи, решения. Концептуально. Когда все сложится в голове. Можно будет пробивать пытаться.

Мой вопрос в ветке - это один из огромного множества. Форумы не помогают особо. В идеале нужна консультация со спецами. И не одна. Ищу таких людей

[AlexHell]

Юрий, все о чем вы пишете - бюрократика и политика, вы "не головняки", а не программирование; то что у вас нет власти и не сможете продвинуть свою (или чужую) поделку \ middleware - проблемы вашей специфичной политики, и от того что я разработаю чтото за вечерок (как вы говорите нельзя разработать, а я допустим разработаю) вы всеравно не установите стандартом, изза ваших проблем, а не изза того что поделку долго делать

[Юрий]

AlexHell, проблем очень много. Если ничего не делать, то они и не решатся сами собой. Возможно я ничего не добьюсь в этом направлении. По большому счету это не важно. "Делай, что должен, и будь, что будет". Всю жизнь так работаем. Глаза боятся, а руки делают. И многое удается. Если не внедрим мидлвэр в отрасли, то у себя уж точно запустим, если он окажется стоящим.

Поэтому, несмотря на все страхи, не отношусь пессимистично к этой затее. Были бы решения правильные приняты и проверены, а дальше можно будет пробивать. За время работы связи появились очень большие. Но пока сам не готов концептуально. Точнее, в общих чертах все понятно, но в деталях не нахожу красивых решений. Вот, например, с flatbuffers