Отправлено yes 26 мая 2004 г. 09:34 В ответ на: а чего тут понимать, видел такое же и для TI (С64) vs PPC (жаль что ALPHA умерла) отправлено yes 26 мая 2004 г. 09:25

понятно, что по параметрам - потребление, стоимость железа - TMS64 круче

но сложный компилятор гораздо сложнее сделать, чем сложный процессор.
единственный известный мне успешный пример - CRUSOE (но может это PR, так как лично мне такое в руки не попадало, а сами трансметовцы очень осторожно оценивают производительность, так как можно придумать бенчмарк, по которым CRUSOE будет плох). ну и транслировать готовый бинарный код - это не С

то есть разработки на "простых" векторных процах - это для каких-нибудь суперпроектов (когда 1000 человек 10 лет код пишет), а для коммерческого с его time-to-market - имхо женераль пёпорз - лучше

• Про 1000 человек и 10 лет (+) — SM   (26.05.2004 10:56, 468 байт)
  • ну и еще специфика лично меня преследует, — yes   (26.05.2004 13:29, 226 байт)
    • Реальное время (+) — SM   (26.05.2004 14:23, 311 байт)
      • ну а если в ТЗ заложена вероятность пропуска/потери отклика? — yes   (26.05.2004 17:43, пустое)
        • Так какая в конце концов тогда разница (+) — SM   (26.05.2004 17:49, 325 байт)
      • Реальное время (как понятие, применимое к системе обработки данных) — Fat Robot   (26.05.2004 14:53, 283 байт)
        • Но система может иметь (+) — SM   (26.05.2004 15:02, 211 байт)
          • "Мертвороженных, как идеальный результат жизненного цикла, — Fat Robot   (26.05.2004 15:15, 157 байт)
            • Я некорректно выразился (+) — SM   (26.05.2004 15:34, 474 байт)
              • А если блок равен одному отсчету? — Fat Robot   (26.05.2004 15:56, 412 байт)
                • просто вопрос возникает - всегда ли нужна большая производительность проца - или ну его, лучше обеспечить удобство разработки — yes   (26.05.2004 17:45, пустое)
                  • Ответ: — -=ВН=-   (26.05.2004 18:00, пустое)
                    • Это было согласием с предыдущими ораторами:-) — -=ВН=-   (26.05.2004 18:02, пустое)
                      • я утверждаю, что пиковая производительность DSP - PR-овская акция производителей — yes   (26.05.2004 18:11, 223 байт)
                        • Так кто бы возражал про PR, кругом один PR:-) — -=ВН=-   (26.05.2004 18:44, 492 байт)
                        • Интересно Ваше определение "нормального средства разработки". — SM   (26.05.2004 18:25, пустое)
                          • А пиковая производительность когда как (+) — SM   (26.05.2004 18:52, 100 байт)
                  • Согласен с предыдущим ответом. Чем выше производительность. тем выше удобство (+) — SM   (26.05.2004 17:53, 132 байт)
                    • да при использовании нормальной связки проц/компилер - вообще не надо думать об оптимизации — yes   (26.05.2004 18:06, 208 байт)
                      • Вот в это не верю (+) — SM   (26.05.2004 18:24, 977 байт)
                        • прямо ответ на "нормальные средства разработки" :) — yes   (27.05.2004 09:12, 819 байт)
                          • Одинаковый фронтенд :) (+) — SM   (27.05.2004 09:34, 386 байт)
                            • а xemacs правильная среда - я с его HDL-ных мод просто тащусь — yes   (27.05.2004 11:01, пустое)
                            • на примере gcc (как кодогенератора) — yes   (27.05.2004 10:59, 802 байт)
                              • Так бы сразу и сказали (+) — SM   (27.05.2004 12:16, 273 байт)
                                • возникает С++ vs C. а gnu-тый девелопмент - увижу что лучше - напишу :) — yes   (27.05.2004 13:22, пустое)
                                  • Если придерживаться ANSI - то такого вопроса не возникает :) — SM   (27.05.2004 13:40, пустое)
                  • Даже не знаю как отреагировать... — Fat Robot   (26.05.2004 17:50, 161 байт)
  • наверно от привычки зависит, но основные сложности возникают, когда проект разрабатывается не 1, а, например, 10+ программерами — yes   (26.05.2004 13:24, 608 байт)
    • Просто у всех разная специфика (+) — SM   (26.05.2004 14:18, 255 байт)
      • неверю :), вобщем-то и ассемблерные библиотеки люди склеивают... но это непростой путь — yes   (26.05.2004 17:42, пустое)
        • Чему не верите (+) — SM   (26.05.2004 17:47, 296 байт)
          • то что заработает слинкованная библиотека (предполагая, что между "модулями" есть какое-то взаимодействие) — yes   (26.05.2004 17:49, 56 байт)
            • Ответ: (+) — SM   (26.05.2004 17:51, 173 байт)
              • а есть методы переложить договоренности на систему. у меня были случаи, когда динамическая линковка полезна была — yes   (26.05.2004 18:02, 446 байт)
                • Да любой линкер (+) — SM   (26.05.2004 18:30, 451 байт)
                  • ха-ха. я это и хочу сказать, что не любой. а про разработку своей линковки - время/деньги однако — yes   (27.05.2004 09:17, 149 байт)
                    • Объясните пожалуйста, (+) — SM   (27.05.2004 09:38, 334 байт)
                      • LGPL - для ембедеров есть (и все там правильно), сделать то хороший линкер не сложно, только блин не делают почему-то — yes   (27.05.2004 11:07, 281 байт)
                        • Сигнатуры C++ (+) — SM   (27.05.2004 12:12, 330 байт)
    • это кстати и к С++ vs C относится (вроде когда-то обсуждалось) — yes   (26.05.2004 13:30, пустое)