Возник вопрос о переносе ассемблерных модулей из VDSP++ в gcc или в CrossCore® Embedded Studio.
Кто имеет опыт и может поделиться? Понятно, что в принципе можно причесать ассемблерный модуль к виду ассемблерной вставки,
однако с такой подход требует большого объема формальной работы по кодированию, да и для сложных ассемблерных модулей gcc
может не хватить регистров. На уровне исполняемых задач известны способы загрузить dxe или ldr и исполнить их, под uLinux. Однако,
это требует вручную разрешать конфликты ресурсов. Существует ли возможность подключения "чужих" объектных файлов, следующих
конвенциям С, С++ по передаче параметров?
Опять же какие типы объектных файлов использует CrossCore® Embedded Studio?
Вопрос связан,например, с тем, что AD выкладывал некоторые Application в виде объектных библиотек VDSP++. Возможно ли их использовать
в альтернативных средах?

Удалось ли вам продвинуться в изучении проблемы? Мы сейчас примерно с тем же столкнулись.

Нет, ведь это практическая проблема, а не умозрительная. Поэтому, я попросил поделиться опытом тех, кто этот путь проходил.
Изучайте проблему использования elf-toolchain
http://electronix.ru/forum/index.php?showt...p;#entry1408344

Мне кажется, что для перехода к gcc нужны очень веские основания. В типичном случае целевая плата обрабатывает данные с ацп и результат передает через универсальные порты (ethernet, usb, can, uart, spi) на компьютер или сервер. Нет необходимости поднимать сервисы на целевой плате и достаточно VDSP ++ При этом нет никаких резонов для использования для целевой задачи gcc, за исключением одного случая - когда это бортовая автономная система и никакого больше компьютера или сервера нет, но есть потребность в службах, типичных для универсального компьютера. Например, автономная бортовая система в которой нужно поднять файловую систему на флешке