Да, для ARMовской части омапа идет тишный компилер в код-композере (TMS470). Я им для не-TI-шных АРМов код генерил, и, более того, даже умудрился через XDS510 прицепиться к альтерскому excalibur в паре с TMS320C55, т.е. сам собрал себе омап и без проблем подцепил тишной средой. («Телесистемы»: Конференция «Цифровые сигнальные процессоры (DSP) и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Цифровые сигнальные процессоры (DSP) и их применение»

Да, для ARMовской части омапа идет тишный компилер в код-композере (TMS470). Я им для не-TI-шных АРМов код генерил, и, более того, даже умудрился через XDS510 прицепиться к альтерскому excalibur в паре с TMS320C55, т.е. сам собрал себе омап и без проблем подцепил тишной средой.

Отправлено SM 13 декабря 2006 г. 14:53
В ответ на: Нет, что очень и очень жаль (+) отправлено <font color=gray>Harbour</font> 13 декабря 2006 г. 14:44

Составить ответ | Вернуться на конференцию

Ответы

Ну вот и гуд - для товарища andy_P есть вполне прикладная ситуация для обоснования, так сказать, наезда ;) — Harbour (13.12.2006 14:57 195.138.79.66, 33 байт)
- А чем АРМовский компилятор от TI плох? Я с ним возился немного - вроде бы ничего плохого. Хочешь 16-бит, хочешь 32, все вместе потом линкуется. Вобщем uCOS портанулся, собрался и работал. — andy_P (13.12.2006 15:05 89.18.130.241, пустое)
  - Мне интересно послушать чем же gcc так плох (+) — Harbour (13.12.2006 15:16 195.138.79.66, 88 байт)
    - Ответ: + — andy_P (13.12.2006 15:26 89.18.130.241, 470 байт)
      - Увы, в linux/Documentation/Changes все написано четко (+) — Harbour   (13.12.2006 15:34 195.138.79.66, 180 байт)
        
        Ядро линукс, видимо благодаря ребятам из редхат не собирается ничем кроме gcc. Поэтому его фтопку. :-)+ — andy_P   (13.12.2006 15:37 89.18.130.241, 143 байт)
        
        Хе-хе, ребята из редхат linux не пишут, ихнее ядро - это отдельная песня и к теме отношения не имеет (+) — Harbour   (13.12.2006 15:41 195.138.79.66, 17 байт)
        
        Ответ: + — andy_P   (13.12.2006 15:51 89.18.130.241, 463 байт)
        
        При чем тут драйвер к ядру, или ход мыслей таков - гляжу вот тут в исходники одного драйвера - бац код не понравился - значит gcc хероват ;) — Harbour   (13.12.2006 16:00 195.138.79.66, пустое)
        
        Ответ+ — andy_P   (13.12.2006 16:15 89.18.130.241, 414 байт)
        
        Тратят деньги и на gcc, может и не так круто как в m$ (+) — Harbour   (13.12.2006 16:26 195.138.79.66, 76 байт)
        
        Ответ: + — andy_P   (13.12.2006 16:48 89.18.130.241, 650 байт)
        
        Вот поэтому gcc и лучший - имея на руках x86/x86_64/arm/avr/ppc зоопарк и кипу софта под это дело - просто не вижу другой альтернативы ;) Конфа, глючит - небось perl gcc'ей компили ;) — Harbour   (13.12.2006 16:51 195.138.79.66, пустое)
        
        Кросс-платформенность - сильная сторона gcc. У меня такого нет. + — andy_P   (13.12.2006 17:09 89.18.130.241, 79 байт)
        
        Ответ: + — andy_P   (13.12.2006 16:45 89.18.130.241, 650 байт)
        
        Ответ+ — andy_P   (13.12.2006 16:11 89.18.130.241, 414 байт)
        
        Ответ: + — andy_P   (13.12.2006 15:51 89.18.130.241, 463 байт)
    - А в 6х non-aligned load/store вроде только с 64+ нормальное стало. Так что компилер-то тут причем? Архитектура не давала. — SM (13.12.2006 15:21 85.21.237.237, пустое)
      - Не понял, а байтовый доступ ? Тут ведь дело не в эффективности, а в портируемости, в интерфейсах с уже написанными приложениями — Harbour   (13.12.2006 15:27 195.138.79.66, пустое)
        
        И что - писать потом огромный хэлп, который будет рассказывать о нюансах тормозов, возникающих из-за сбора слов, не там лежащих, из отдельных байтов? И техподдержке это объяснять громадному валу юзеров, не вдающихся в тонкости архитектуры? Проще и правильнее не поддержать, кому надо сам соберет. Тем более, что это не стандарт, это расширения. — SM   (13.12.2006 15:31 85.21.237.237, пустое)
        
        Ну да, проще переписать все приложения, взаимодействующие с данной бордой, или обьяснить их программистам - видите ли у нас тут в структурке дырка, но зато обмен очень быстрый ;) — Harbour   (13.12.2006 15:38 195.138.79.66, пустое)
        
        Да нет, надо просто сразу при получении с интерфейсов все разбросать по структурам, не пакованным, а дальше по-нормальному с данными работать. А не таскать их в такм привязанном к компилеру виде через весь софт. — SM   (13.12.2006 15:51 85.21.237.237, пустое)
        
        Ну вот и имеем байтовый доступ, про который я и говорил — Harbour   (13.12.2006 15:54 195.138.79.66, пустое)
        
        Да, но программист сам разобрал байты, и сам распихал в структуру. И знает, что тут тормоз архитектурный. И знает, что при дальнейшей обработке эта структура, уже распакованная новых тормозов не внесет. — SM   (13.12.2006 15:56 85.21.237.237, пустое)
        
        Вот-вот, сам разобрал, а вот структур этих например несколько сотен. Спрашивается почему столь могучий компилер от TI не имеет такого примитивного расширения ? — Harbour   (13.12.2006 16:05 195.138.79.66, пустое)
        
        Потому что оно не нужно, если речь идет о правильном подходе к софтописанию. И, кстати, совместимости будет больше при переносе с этого компилера на другие. — SM   (13.12.2006 16:09 85.21.237.237, пустое)
        
        При чем тут подход - есть уже данная реальнось - и если компилер с этой реальностью не в ладах, то как показывает практика поменять проще компилер, чем реальность, в случае с TI - народу остается меняет реальность ;) — Harbour   (13.12.2006 16:21 195.138.79.66, пустое)
        
        Такую реальность надо просто нахрен выкинуть, если это готовый код, или уволить, если это программер. — SM   (13.12.2006 16:29 85.21.237.237, пустое)
        
        Ваши бы слова, да буржуям в зубы ;) — Harbour   (13.12.2006 16:39 195.138.79.66, пустое)
        
        Ваши бы слова, да буржуям в зубы ;) — Harbour   (13.12.2006 16:34 195.138.79.66, пустое)
        
        Смысл? Я просто не буду работать в такой конторе, где такой подход. Неправильный. — SM   (13.12.2006 16:38 85.21.237.237, пустое)
        
        Такую реальность надо просто нахрен выкинуть, если это готовый код, или уволить, если это программер. — SM   (13.12.2006 16:24 85.21.237.237, пустое)
        
        Да нет, надо просто сразу при получении с интерфейсов все разбросать по структурам, не пакованным, а дальше по-нормальному с данными работать. А не таскать их в такм привязанном к компилеру виде через весь софт. — SM   (13.12.2006 15:48 85.21.237.237, пустое)
- Весь список чего? — SM (13.12.2006 15:03 85.21.237.237, пустое)
  - Список недостатков gcc — Harbour (13.12.2006 15:16 195.138.79.66, пустое)
    - Для меня - один недостаток - что это вещь в себе, которую изучать надо отдельно. То есть например между TI и MSVC я туда-сюда свободно, то между TI-gcc и MSVC-gcc ну никак. А на кой мне это время тратить на х.з. что, если я без этого gcc все на порядок быстрее сделаю? — SM (13.12.2006 15:19 85.21.237.237, пустое)
      - Ну с подходом "кажному CPU по компилеру" - изучать придется каждый компилер, с gcc здесь все попроще, как минимум опции/аттрибуты остаются постоянными (+) — Harbour   (13.12.2006 15:46 195.138.79.66, 155 байт)
        
        Набор опций один раз из IDE галками сделать, потом "create makefile" и погнали. Знать сами опции нафиг не надо. А вот стоит ли изучать gcc - вопрос, так как кроме халявности у него плюсов что-то маловато, особенно по оптимальности кода. — SM   (13.12.2006 15:55 85.21.237.237, пустое)
        
        И вообще, доверия к софту, построенному по системе, когда толпа пишет по куску каждый сам по себе, порой не особо коррелировано друг с другом, у меня нет, и не будет. Коммерческий софт пишется по другим принципам. — SM   (13.12.2006 16:11 85.21.237.237, пустое)
        
        На примере TI можно видеть по каким - $3k зелени за жалкое виндовое подобие gcc, изменить которое нет никакой возможности — Harbour   (13.12.2006 16:18 195.138.79.66, пустое)
        
        3K зелени - примерно месяц - два труда одного хорошего программиста. В случае opensource столько времени бы ушло на прочтение списка глюков и попытки их исправления. + — andy_P   (13.12.2006 16:30 89.18.130.241, 34 байт)
        
        Текущий список глюков для gcc исчисляется одной-двумя сотнями. Так в отличие от коммерческих бездельников - на кажный запрос в bugzill'е будет реакция разработчика, а не менджера, который принимает решение о исправлении или неисправлении того или иного глюка — Harbour   (13.12.2006 17:04 195.138.79.66, пустое)
        
        Неверно, менеджер принимает решение, связать Вас с разработчиками или нет. Если Вы доказали, что не лох, и это действительно баг, то Вас отправляют уже в нужный team. Я доходил и до чиподелов, и до софтописателей. — SM   (13.12.2006 17:13 85.21.237.237, пустое)
        
        Мне проще и быстрее поправить исходники, чем долго и нудно пробивать бюрократическую стену добиваясь исправления бага за честно заплаченный софт, и потом еще столько же ждать пока его исправят — Harbour   (13.12.2006 17:23 195.138.79.66, пустое)
        
        Ага, и потом кричать что нет поддержки и никто ничего не исправляет. Когда самому лень. Никто не мешает и исходник поправить, и баг в баглист добавить. — SM   (13.12.2006 17:27 85.21.237.237, пустое)
        
        Что значит лень ? Баг он от лени сам не пропадет, и заказчик с бордой продолжает висеть на душой. Время - вот чего жаль. — Harbour   (13.12.2006 17:37 195.138.79.66, пустое)
        
        Заказчика устроит и исправление исходника, чтобы баг обойти. А лень - сделать так, чтобы в след. версии этого бага уже не стало. Хотя бы чтобы другие потом не нарвались. — SM   (13.12.2006 17:41 85.21.237.237, пустое)
        
        Нет никакой??? Не надо! По результатам моего общения с поддержкой например пофиксили они кой-что в транслятора асма. И постоянно у них и баг-фиксы и трекинг багов, и все как положено. — SM   (13.12.2006 16:24 85.21.237.237, пустое)
        
        Я неоднократно спрашивал когда выйдет версия codegen'а по linux (была у них в 3.0 версии) - один менеджер солгал, один ничего не ответил - желание с ними общаться пропало — Harbour   (13.12.2006 16:32 195.138.79.66, пустое)
        
        Я оказался настойчивее :) — SM   (13.12.2006 16:38 85.21.237.237, пустое)
        
        В смысле у Вас есть linux cgt 3.2 ? ;) — Harbour   (13.12.2006 17:47 195.138.79.66, пустое)
        
        Нет, нету, да и если бы я искал свежий cgt, то для 55 :) :) - я про то, что баг исправили по моему заявлению. — SM   (13.12.2006 18:03 85.21.237.237, пустое)
        
        Только надо доказать, что это баг. Они не бросаются править все подряд, и правильно делают. — SM   (13.12.2006 16:30 85.21.237.237, пустое)
        
        И вообще, доверия к софту, построенному по системе, когда толпа пишет по куску каждый сам по себе, порой не особо коррелировано друг с другом, у меня нет, и не будет. Коммерческий софт пишется по другим принципам. — SM   (13.12.2006 16:09 85.21.237.237, пустое)
        
        Этот подход хорош, когда все заделывают заплатки и дырки, отсюда надежность линукса. Но родить таким образом хорошо оптимизирующий компилятор я не верю, что возможно. — SM   (13.12.2006 16:14 85.21.237.237, пустое)
        
        Хотя... Если редхет получше все возьмет в свои руки, как он подходит к своим дистрам, и за что его уважают всякие синопсисы и e.t.c, то я возможно пересмотрю свое отношение к gcc — SM   (13.12.2006 16:18 85.21.237.237, пустое)