[bookevg 0]

Резюме походу работы с Sharc-процессорами: VDSP++ компилятор С/C++ не полностью использует возможности процессора:

1.Нет родной поддержки 40-битного float, но своими ручками эта проблема решается

2.Нет родной поддержки 16-битных чисел, но своими ручками эта проблема решается

3.Нет родной поддержки half-float, опять все своими ручками решается.

4.Битовые поля структур - нет поддержки little endian, только big endian

5.и много другого нет, все самому надо делать

Вывод: плохое отношение аналога к клиентам своих процессоров, которое м.б. из-за:

1) эти процы используются в военных целях армии США - и поэтому не надо всем раскрывать их полный потенциал;

2) клиенты очень умные (сам таким стал) и решают самостоятельно свои проблемы, но при таком отношении новым клиентом аналога не советую становится уж лучше взять техас, особенно C674x, или renesas (SH2A или SH4A);

3) программеров VDSP++ в аналоге очень ценят и отход от стандарта расценивается как измена: на их месте я давно бы реализовал 40-битный float и 16-битный float и трубил об этом всем, ведь в принципе 64-битный double и не нужен, но вот 32-битного float иногда не хватает, а 40-битный float самое то.

Та же самая ситуация была у аналога с ADSP219x - все приходилось делать самому - они также могли сделать 32-битный float, но от бы отличался от стандартного IEE754, но зато бы не тратилось бы 50-70% на проебразование из IEE754 в формат, который является родственным для ядра

[olefil 0]

1. А смысл есть в 16-ти битном float на 32-х битной архитектуре?

2. Используйте 40 битный формат. Кто вам это запрещает?

3. Военные в основном юзают TigerSharc.

[Stanislav 0]

Резюме походу работы с Sharc-процессорами: VDSP++ компилятор С/C++ не полностью использует возможности процессора:

1.Нет родной поддержки 40-битного float, но своими ручками эта проблема решается

2.Нет родной поддержки 16-битных чисел, но своими ручками эта проблема решается

3.Нет родной поддержки half-float, опять все своими ручками решается.

4.Битовые поля структур - нет поддержки little endian, только big endian

5.и много другого нет, все самому надо делать

А как Вы хотели?

Компилер соответствует стандартам языка, не более того. Конечно, типы данных, присущие только DSP, равно как и многие полезные фичи, компилер не поддерживает, вследствие именно специфичности дивайса и универсальности ЯВУ. Поэтому, DSP программисту нужно быть готовым к написанию 10-15% исходников на АСМе, если он хочет в полной мере использовать преимущества архитектуры "железа".

 

Вывод: плохое отношение аналога к клиентам своих процессоров, которое м.б. из-за:

..................................................

По-моему, это крайне поверхностное суждение. :(

Желающему создать какой-то другой язык, отличный от C/C++, вряд ли кто-нибудь станет мешать.

А VDSP++ - один из лучших компилеров, с которыми приходилось работать.

[bookevg 0]

1. А смысл есть в 16-ти битном float на 32-х битной архитектуре?

Коэффициенты, участвующие в расчетах, не требующих особой точности

2. Используйте 40 битный формат. Кто вам это запрещает?

Никто не запрещает, только:

1) 40-битные данные надо размещать или в специлизированной 48-битной области dmda_48 (для уменьшения размера данных, которым надо только 32 бита) или в общей 48-битной области dmda (но при этом для данных, которым надо только 32 бита будут приплюсовываться доп.16бит).

2) при использовании специализированной 48-битной области dmda_48 надо следить за размером ширины доступа внутр.блока данных, если в нем размещаются данные не только 48 битные.

3. Военные в основном юзают TigerSharc.

Я бы наверное тоже их использовал, если бы были недорогие, тогда бы не ломал голову где разместить данные (чтобы сэкономить место), а сделал всю область 48-битной

 

 

А как Вы хотели?

Компилер соответствует стандартам языка, не более того. Конечно, типы данных, присущие только DSP, равно как и многие полезные фичи, компилер не поддерживает, вследствие именно специфичности дивайса и универсальности ЯВУ. Поэтому, DSP программисту нужно быть готовым к написанию 10-15% исходников на АСМе, если он хочет в полной мере использовать преимущества архитектуры "железа".

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

Но вот еще бы на их месте я бы создал класс double40bit и сказал всем - используйте, а захотите на другой проц перейдите, где нет 40-bit float, то просто замените double40bit на double.

Ведь класс fract они не поленились сделать, а вот fract64, long int и double40bit не захотели, а что им стоило - ведь как никак используем C++ - а они создатели проца и VDSP++ и поэтому все про него знают.

Моя душа возмущается, когда видит такие возможности процессора и отсутствие готовых средств для их использования, хотя я знаю как задействовать эти все возможности - с одной стороны это хорошо, ни каждый на это способен, отсюда хлеба моего меньше не станет

 

По-моему, это крайне поверхностное суждение. :(

Желающему создать какой-то другой язык, отличный от C/C++, вряд ли кто-нибудь станет мешать.

А VDSP++ - один из лучших компилеров, с которыми приходилось работать.

Я не предлагаю создавать новый язык, я просто советую (и удивляюсь) аналогу создать новые классы, которые поддерживали все возможности процессора

[jojo 0]

Все нормально и на ассемблере программируется.

 

На Си компилятор делает грязный код, который часто страннее и заметно медленнее ручного кода.

 

Интринсики тоже не всегда ловко кладутся в код.

[gridinp 2]

Согласен с предыдущим автором 10-15%, собственно в которых обычно и сосредоточена основная нагрузка на процессор. А всё писать на асме :) верный путь стать незаменимым программистом, поскольку у продолжателей твоего дела в C то мало желания разбираться, а в асме и подавно.

Вывод сделан из собственных наблюдений, может чего не понимаю.

[jojo 0]

Программист шарков незаменим по определению. :)

 

Согласен про 10-15 % кода и основную нагрузку. Соблюдая конвенцию вызова Асм из Си, можно программировать милые маленькие процедурки, в которые лезть не нужно.

[gridinp 2]

Тем более что Analog сделал очень не плохой asm с параметрами, фактически C-переменные в инструкциях испольовать можно.

[Stanislav 0]

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

ЯВУ, собственно, для этого и предназначены.

 

...Но вот еще бы на их месте я бы создал класс double40bit и сказал всем - используйте, а захотите на другой проц перейдите, где нет 40-bit float, то просто замените double40bit на double.

А я бы - не создавал, дабы не плодить лишние сущности.

Кроме того, в предлагаемом Вами типе данных очень мало практической пользы.

Видимо, Аналог Дивайсис считает так же, как и я. :)

 

...Ведь класс fract они не поленились сделать, а вот fract64, long int и double40bit не захотели, а что им стоило - ведь как никак используем C++ - а они создатели проца и VDSP++ и поэтому все про него знают.

1. Что касается fract. Этот тип был введён с целью указания DSP, каким образом ему следует размещать результат умножения. Без него обойтись просто нельзя, и введен он был не для "удобства" пользования, а вследствие крайней необходимости. Такова специфика DSP, отличающая его от "классических" универсальных процессоров.

Кроме того, этот тип по размерности данных не отличается от int, ни для компилера, ни для линкера, и соответствует разрядности процессора.

2. Вы плохо читали мануалы. long int в VDSP++ присутствует. 64-битное целое же называется long long.

Все приведённые выше типы совершенно органично поддерживаются как шарками, так и финами.

3. По поводу fract64 и double40bit. А вот это - совершенно неестественные для процессоров всех семейств фирмы AD типы, которые не нужны для практического использования, если говорить хоть о мало-мальской эффективности кода.

 

Если задачу для 40-бит плывучки ещё как-то можно измыслить, для каких таких практических целей может пригодиться fract64, не просветите?

 

...Моя душа возмущается, когда видит такие возможности процессора и отсутствие готовых средств для их использования,

Погодите о душе-то...

Возможностей процессора Вы, по всему видать, как раз и не знаете. Иначе такую ахинею не стали бы писать. :(

"Готовые средства" же имеются в полном объёме. Вам просто предстоит научиться ими пользоваться.

 

...хотя я знаю как задействовать эти все возможности - с одной стороны это хорошо, ни каждый на это способен, отсюда хлеба моего меньше не станет

Сильно сомневаюсь в Ваших знаниях и способностях, чего не скажешь о скромности... :(

Думаю, не сильно ошибусь, если предположу, что Вы лишь нахватались верхушек "програмизьма", а затем ринулись сиим сокровенным знанием ниспровергать устои и сворачивать горы.

Не выйдет эдак ничего хорошего. На поприще DSP - уж точно.

 

...Я не предлагаю создавать новый язык, я просто советую (и удивляюсь) аналогу создать новые классы, которые поддерживали все возможности процессора

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

[bookevg 0]

ЯВУ, собственно, для этого и предназначены.

 

А я бы - не создавал, дабы не плодить лишние сущности.

Кроме того, в предлагаемом Вами типе данных очень мало практической пользы.

Видимо, Аналог Дивайсис считает так же, как и я. :)

Для вас и не надо, а кому то надо.

 

1. Что касается fract. Этот тип был введён с целью указания DSP, каким образом ему следует размещать результат умножения. Без него обойтись просто нельзя, и введен он был не для "удобства" пользования, а вследствие крайней необходимости. Такова специфика DSP, отличающая его от "классических" универсальных процессоров.

Кроме того, этот тип по размерности данных не отличается от int, ни для компилера, ни для линкера, и соответствует разрядности процессора.

Еще в ADSP219x можно было использовать int как fract, только надо было процессор каждый раз переключать с int умножения на fract, а затем обратно + правильную интерпретацию при сложении/вычитании.

В Sharc - команды умножения для int и fract стали разными.

Поэтому, чтобы компилятор знал какие команды или режимы использовать в нем и создали класс fract - причем только в С++.

2. Вы плохо читали мануалы. long int в VDSP++ присутствует. 64-битное целое же называется long long.

Все приведённые выше типы совершенно органично поддерживаются как шарками, так и финами.

Согласен я ошибся, хотел написать long long int

3. По поводу fract64 и double40bit. А вот это - совершенно неестественные для процессоров всех семейств фирмы AD типы, которые не нужны для практического использования, если говорить хоть о мало-мальской эффективности кода.

Если задачу для 40-бит плывучки ещё как-то можно измыслить, для каких таких практических целей может пригодиться fract64, не просветите?

Зачем тогда application создавать Extended-Precision Fixed-Point Arithmetic on SIMD SHARC® Processors или аналог не согласен с вашим мнением и он считает, что кому-то эти типы нужны, но вот только не вашим задачам.

Зачем аналогу трубить о 40-битной плавучки в своих мануалах на проц?

Ну а использовании fract64 - я так думаю в прецизионных системах.

Погодите о душе-то...

Возможностей процессора Вы, по всему видать, как раз и не знаете. Иначе такую ахинею не стали бы писать. :(

"Готовые средства" же имеются в полном объёме. Вам просто предстоит научиться ими пользоваться.

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

Я согласен, что все, что я перечислял можно реализовать, но только после детального изучения материала (хорошо, что я хорошо знаком с ADSP219x, но вот новичку было бы туго)

Сильно сомневаюсь в Ваших знаниях и способностях, чего не скажешь о скромности... :(

Думаю, не сильно ошибусь, если предположу, что Вы лишь нахватались верхушек "програмизьма", а затем ринулись сиим сокровенным знанием ниспровергать устои и сворачивать горы.

Не выйдет эдак ничего хорошего. На поприще DSP - уж точно.

Не согласен, возможно я и молодой (начал работать только с 2001) и использую процы аналога не для чистых DSP-задач, а для motor control (с 2004 года - ADSP219x, а Sharc c этого года) - да и реализация проектов в области энергетики очень ответственных, где цена ошибки отказ заказчиком от дорогостоящего оборудования (от 1.5 миллиона за экземпляр).

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

Железо давно изучено. Причем замечено, что архитектура DMA Sharc и ADSP219x приблизительно одинаковая. Так и неспособность работы SPI-канала в режиме DMA одновременно как прием, так и на передачу передалась и Sharc-ку.

 

Итого: мы мое резюме посвящалось следующему (возможно некорректно его описал): чтоб использовать все возможности Sharc - необходимо детальное изучение проца, а если эти все возможности использовать и на C/C++, то и знание компилятора и линкера.

[FatRobot 0]

Насчет

 

2.Нет родной поддержки 16-битных чисел, но своими ручками эта проблема решается

 

Насколько я помню по 065L, никаких команд, кроме преобразований float32<->float16 ядро shark не поддерживает. так что всё обосновано. Скорее всего есть intrisic ф-ции преобразования.

 

Насчет

 

4.Битовые поля структур - нет поддержки little endian, только big endian

 

Вы могли бы привести пример компилятора С/С++ (для любого процессора), в котором порядок следования битовых полей в структуре можно было бы изменить?

 

Заранее благодарю.

[jojo 0]

Изучать в любом случае это все придется. Хоть для Sharc, хоть для Core2.

Вот ЯВУ для Core2 - С++ от Микрософта - в 2-4 раза хуже делает код для SSE, чем человек.

А для оптимального написания кода "маршрут" программирования от шарков практически не отличается.

 

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

 

Быстрее, оно конечно, желательно. Но время изучения новых инструментов и возможностей для Sharc очень небольшое, это недели. Так что можно изучить и творить отличный код. И потом, за что 100000-120000 рублей чистыми платить программисту, за код с интринсиками и неуправляемой автоматической оптимизацией?