Разработка, производство и продажа радиоэлектронной аппаратуры
|
Карта сайта
|
Пишите нам
|
В избранное
Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:
jobsmp@pochta.ru
Телесистемы
|
Электроника
|
Конференция «Цифровые сигнальные процессоры (DSP) и их применение»
Мне интересно послушать чем же gcc так плох (+)
Отправлено
Harbour
13 декабря 2006 г. 15:16
В ответ на:
А чем АРМовский компилятор от TI плох? Я с ним возился немного - вроде бы ничего плохого. Хочешь 16-бит, хочешь 32, все вместе потом линкуется. Вобщем uCOS портанулся, собрался и работал.
отправлено andy_P 13 декабря 2006 г. 15:05
А что компилер от TI packed struct в АРМ'ах поддерживает ? А то в c6x с этим облом-с ...
Составить ответ
|
Вернуться на конференцию
Ответы
Ответ: +
—
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
,
пустое
)
Отправка ответа
Имя*:
Пароль:
E-mail:
Тема*:
Сообщение:
Ссылка на URL:
URL изображения:
если вы незарегистрированный на форуме пользователь, то
для успешного добавления сообщения заполните поле, как указано ниже:
вычтите два из трёх, получится:
Перейти к списку ответов
|
Конференция
|
Раздел "Электроника"
|
Главная страница
|
Карта сайта
Web
telesys.ru