Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Портирование кода с х86 на ARM9  (Прочитано 35839 раз)
0 Пользователей и 1 Гость смотрят эту тему.
dimedrol
Помогающий

ru
Offline Offline

« : 04-05-2011 08:48 » 

День добрый! Достался тут в наследство мне большой проект, написанный под x86-32, с заданием портировать его под ARM9, все бы хорошо, да только под арм данные должны выравниваться на границе их размерностей. Естетственно долгие годы проект писался с кучей структур #pragma packed(1) и относительно вольной работой с указателями и сейчас представляет собой просто чудовищный объект для портирования. Покурив мануалы, вырисовывается 3 способа:
1) попытка переопределить все необходимые указатели для компилятора как packed, после чего компилер (GCC) будет вынимать память аккуратно побайтно, что устанит проблему. Минусы - падение производительности и обльшой объем кода для рефакторинга.
2) возложить на ОС обработку исключений выравнивания, чтоб она в обработчике сама довыбрала побайтно то, что не удалось программе. в QNX и Linux вроде есть такое. Минусы - думается мне, чудовищное падение производительности. Плюс - портирование достается даром Улыбаюсь
3)полный рефакторинг кода с учетом платформенных особенностей. Минусы - объем работы. Плюсы - хорошая производительность.

Собсвенно тема для обсуждения - а есть ли какие-либо методики и книжки на тему подобного портирования? Может кто-то поделиться опытом, по какому пути стоит идти.

ЗЫ Есть вроде новые армы, которые позволяют выборку невыровненных данных, с потерей 1 машинного такта, но ,в данном случае, в ТЗ не упихиваются по цене.
Записан

Как говориться, cемь бед - один Reset Улыбаюсь
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 04-05-2011 09:04 » 

Для чего использовались упакованные структуры? Только внутри или для IO тоже?
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
dimedrol
Помогающий

ru
Offline Offline

« Ответ #2 : 04-05-2011 10:01 » 

и там и там, но объем IO мал - тут проблем переписать нет, проблемы с внутренними алгоритмами и организацией данных.
Записан

Как говориться, cемь бед - один Reset Улыбаюсь
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 04-05-2011 11:12 » 

dimedrol, если это не проблема ввода-вывода, то можно какой-нибудь пример посмотреть проблемного места?

Если работа с памятью происходит аккуратно через sizeof, а данные тщательно сгруппированы по struct и union, я не вижу никакой проблемы в снятии pack(1) - всё автоматически должно развернуться.

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
dimedrol
Помогающий

ru
Offline Offline

« Ответ #4 : 04-05-2011 11:58 » 

Проблемные места размазаны по коду, например тянется цепочка вызовов функций (код - С, без ++), в первую передается указатель на какое-либо поле упакованной структуры, в результате информация об упаковке теряется и компилятор обращается по указателю как по выровненному, где-то в середине цепочки может встретится какое-нибудь лихое преобразование типа:
Код:
    pvars = (int*)((uint8_t*)p->base + p->off);
после чего полученный указатель расползается еще в 10 мест,и прочие прелести. По ходу работы программа разбирает навороченный бинарный файл конфигурации, а также исполняет некоторые инструкции собственной виртуальной машины. Естественно везде никаким выравниванием и не пахнет.
Записан

Как говориться, cемь бед - один Reset Улыбаюсь
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 04-05-2011 12:35 » 

Думаю, стоит оценить объем работ по переделке, умножить на Пи и сравнить с имеющимися возможностями.

Ужас да и только.
« Последнее редактирование: 04-05-2011 12:39 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 04-05-2011 16:59 » 

dimedrol, в общем, потеря информации о типах и программирование методом грубой силы.

Какие же тут книжки?..
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines