TASKING, PARADIGM ..., Приглашение к обмену опытом Опции

[one_man_show]

Так исторически сложилось, что "настоящим" С-компилятором я все время считал тот, с которого начинал - это Borland C (ранее Turbo C). Когда круг задач модифицировался в Embedded, продолжаю использовать модификацию Borland C++ 5.02 под названием Paradigm C++. Его приходится применять, если задачи требуют x86 машинок. 8-битные всегда ранее программировал на ассемблере, а несколько лет назад перешел на Tasking, который так же могу назвать "настоящим" С-компилятором. Во-первых, при портировании кода на другую машинку и переходя на этот компилятор с "честных" С-приложений, не возникает никаких трудностей. Во-вторых, что часто бывает очень важно при обработке сигналов, "честная" поддержка арифметики с плавающей точкой.

Какие средства разработки вы используете, если проекты выходят за рамки одного семейства процессоров? Заботит ли вас, как и меня переносимость исходного кода на другие процессоры, отличающиеся разрядностью, архитектурой и пр.?

[Slavik]

Какие средства разработки вы используете, если проекты выходят за рамки одного семейства процессоров? Заботит ли вас, как и меня переносимость исходного кода на другие процессоры, отличающиеся разрядностью, архитектурой и пр.?

Под каждый проц используешь свои средства разработки, от этого не куда не денишься. Единственное исключение редактор, но тут дело вкуса. А когда переходишь к отладке, всё равно и редактор встроеный используешь.

Как только начинаешь тыкаться в регистры процессора или устройства - о любой переносимости можно забыть, здесь даже не важно на чём написан код C/Asm. Ну асм естественно на другой проц не переносим. На C целесообразно платформенно независимые куски собирать в отдельные функции (ну скажем обработка данных) и запихивать в отдельный файл, только для этой части кода можно говорить о какой-то переносимости. Тут Вам необходимо будет позаботиться о размерности переменных на разных платформах, сделать это можно заведя собственные типы через typedef и определить их для каждой платформы.

А по поводу оптимизации кода на асме - ну тут все зависит от того, на сколько голова работает. В идеале код должен получиться одинаковый, что у программиста, что у компилятора, вопрос лишь в том, кто глупее окажется.

[Armen]

Какие средства разработки вы используете, если проекты выходят за рамки одного семейства процессоров? Заботит ли вас, как и меня переносимость исходного кода на другие процессоры, отличающиеся разрядностью, архитектурой и пр.?

Под каждый проц используешь свои средства разработки, от этого не куда не денишься. Единственное исключение редактор, но тут дело вкуса. А когда переходишь к отладке, всё равно и редактор встроеный используешь.

Как только начинаешь тыкаться в регистры процессора или устройства - о любой переносимости можно забыть, здесь даже не важно на чём написан код C/Asm. Ну асм естественно на другой проц не переносим. На C целесообразно платформенно независимые куски собирать в отдельные функции (ну скажем обработка данных) и запихивать в отдельный файл, только для этой части кода можно говорить о какой-то переносимости. Тут Вам необходимо будет позаботиться о размерности переменных на разных платформах, сделать это можно заведя собственные типы через typedef и определить их для каждой платформы.

А по поводу оптимизации кода на асме - ну тут все зависит от того, на сколько голова работает. В идеале код должен получиться одинаковый, что у программиста, что у компилятора, вопрос лишь в том, кто глупее окажется.

Nu ya bi ne skazal.... po povodu odinakovosti koda ot komilyatora i programmista..
kak pravilo dostup k vozmojnostya proca(DSP) vozmojen cherez Intrinsic funkcii da i to ne vsegda i ne vse vozmojnosti... mojesh prosmotret dlya TI DSP 55xx. instruction set davolno shirokiy a vot compilyator ne dayet dostup ko vsem... prichem menyaetsya ot versii slava bogu kak pravilo obogoshaetsya. Idealniy variant kombinirovanniy kod s tochki zreniya proizvoditelnosti... prichem effekt skajem u togo je 55xx 2-3 raza... a to i celix 100 ( bil odin takoy sluchay ) no eto skoree isklyuchenie. Dlya serii 64, 67 koefficient ne tak visok.... compilyator udachney da i kod na asm slojnee pisat. Vobshem vse eto ot situacii i ne odnoznachno.

bivayut i drugie problemi... skajem alignment structur. Nepriyatnaya vesh. est komilyatori kotorim vse ravno chto v structure, razmer, fundamentalniy tip. Oni vse structuri delayut alignmet 4 i razmer toje kraten 4. Nepriyatnaya shtuka. Kstati mojet kto znaet kak s etim spravitsya s kompilyatorom ot Metrowerks dlya StarCore?