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

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Портирование кода с х86 на ARM9  (Прочитано 35970 раз)
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 тоже?
Записан

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

"железокаменный метеорит" мог образоваться от расплавления металлических конструкций в результате например ядерного взрыва и стекания жидкого железа в какой нибудь щебень (c) Иванов С.
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 » Записан

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

"железокаменный метеорит" мог образоваться от расплавления металлических конструкций в результате например ядерного взрыва и стекания жидкого железа в какой нибудь щебень (c) Иванов С.
Dimka
Деятель
Модератор

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

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

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

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

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

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines