Перейти к содержанию
    

tema13tema

Участник
  • Постов

    10
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о tema13tema

  • День рождения 13.11.1984

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array
  1. diwil, спасибо. Я уже откомпилировал CGEN :), но по всем отзывам вижу, что это будет дополнительная головная боль :krapula: Пока не буду его юзать...
  2. Сергей, я остановился на некотором промежуточном этапе портирования GCC компилятора (на базе проекта LLVM). Задача подключить отладчик (я задавал вопрос по этому поводу: http://electronix.ru/forum/index.php?showtopic=64554. Судьба заставляет меня вернуться в этот проект). А так как он очень тесно связан с пакетом binutils и берет его составные части, то было бы замечательно портировать всю стандартную цепочку инструментов :) P.S. Нашел твою ветку по вопросу портирования binutils :) (http://electronix.ru/forum/index.php?showtopic=32783) Извиняюсь, SM твоя ветка по вопросу портирования binutils (http://electronix.ru/forum/index.php?showtopic=32783)
  3. SM, а дизассемблер у отладчика GDB как-то опирается на дизассемблер из binutils? Или GDB использует только структуру BFD из binutils?
  4. Огромная благодарность за помощь. Сергей, структуру BFD изучаю :) SM, буду пытаться разобраться сам, но если сил не хватит, буду спрашивать по делу.
  5. Доброго времени суток, гуру и форумчане! Возникла острая необходимость в наборе binutils для своего проца. Сейчас существует просто perl-скрипт перевода ассемблер-кода в загружаемый бинарник. Изучая многие ветки форума, неоднократно попадал на упоминания об опыте портирования binutils у участников. Хотелось бы получить ценные советы, с чего начинать, что использовать, чтобы избежать глупых ошибок и затратить меньше времени на портирование. Как я понимаю, хорошо начинать с существующего примера. Рекомендуют M32R - в описании к CGEN. Насколько оправдано использование CGEN? Буду благодарен любым советам/предложениям/замечаниям/рекомендациям!
  6. Klen, про морковку занимательная история :) А с отладчиком мне всё-равно нужно разбираться, деваться некуда :(
  7. Make_Pic , спасибо за ответ. Поясню: Есть фирма Hilscher GmbH, давно разрабатывают свой чип - NetX, сейчас у них уже целая линейка. Основа ARM 9й серии, но к нему есть обвязка из нескольких одинаковых сопроцессоров (ХРЕС). ARMу доступны их все адреса и ресурсяы. Вот эти сопроцессоры как раз и самопальные :rolleyes: Для ARM весь набор компилятор/отладчик соответственно есть, для сопроцессоров - нет. Отлаживать хочу на собственном асме, неудобно, но так нужно)) Буду смотреть описание форматов ELF и COFF. Описание есть - разберусь. Думаю, это то, что мне и нужно, т.к. в промежуточный код при компиляции в DEBUG режиме добавляется отладочная информация, но в непонятном формате, но есть описание))) Писать свой GNU компилятор не собираюсь, ведь LLVM это он и есть, уже готовый. Сергей, спасибо. Буду читать доку к GDB.
  8. Уважаемые ГУРУ и МАГИ форума! Описание: Есть проц собственной разработки, под который на фирме программировали до сих пор на асме. Стала задача портировать компилятор Си. После некоторого времени капания в сети нашел проект LLVM (http://llvm.org/). Идея проста: под GCC-фронтэнд компилятора компилирует в промежуточный код, который не привязан к платформе, а бекэнд (который нужно написать своими ручками) переводит этот промежуточный код уже непосредственно в ассемблер или в бинарный код для процессора. Эта часть успешно была мной реализована, Си успешно компилируется в асм. Проблема: Но есть острая необходимость в возможности отладки исходного Си-кода. Изучил много доки по GDB, по его удаленной отладке (target remote ... ). Насколько я понимаю, GDB должен знать архитектуру моего проца, т.е. регистры, стек и т.п. Это значит нужно что-то дописать в самом GDB? Что именно? Или сам компилятор должен в исполняемый код добавить эту информацию для GDB? (так нет, при удаленной отладке не нужна даже таблица символов в исполняемом коде :wassat: ) Просмотрел львиную долю форума, много тем по отладке, но пока меня ничто не натолкнуло куда мне двигаться дальше, в каком направлении рыть. Буду благодарен любой помощи!
  9. Tue, у нас в корне меняется и сама модель, и система ввода-вывода. Система ввода-вывода становится быстрее, а модель сложнее. Полная модель ещё не тестировалась, т.к. полностью переход на xPC-Target не осуществлен. Поэтому за неимением результатов я ответить не могу. Ещё полностью не определились переходить на xPC-Target или на что-нибудь другое. Поэтому и был вопрос про QNX.
  10. Есть такая задача: построение системы регулирования мехатронной системы с использованием MATLAB/Simulink. В начале разработок эта задача решалась непосредственно работой самого Simulink в реальном времени (на основе специальных S-функций), хотя такой реалтайм очень сомнителен, но для периодов дискретизации до 10мс этого хватало. В последнее время возникла необходимость в уменьшении периода дискретизации до 1000 - 100 мкс, вседствии чего перешли на xPC-Target, где удаётся выдержать такие требования, легко компилируется модель (самому дописывать ничего не нужно) , и обращение к платам ввода-вывода легко осуществимо. Однако недостатком такого варианта является то, что нет поддержки многоядерных процессоров и не ясны возможности кластеризации (разбиение модели для исполнения на нескольких компьютерах). Из возможных альтернатив вижу использование вместо xPC-target реалтайм системы QNX, что подтверждают многие проекты, описанные в интернет. Хотя я не отрицаю использование других RTOS. Встречался ли кто-нибудь с компилированием Simulink-модели под QNX и как это осуществляется? Буду рад любым советам, указаниям и предложениям.
×
×
  • Создать...