* Re: is Ada used much for signal processing? Audio, digital communications, digital image processing?
2020-01-19 21:07 is Ada used much for signal processing? Audio, digital communications, digital image processing? Nasser M. Abbasi
2020-01-20 11:02 ` Jerry
@ 2020-01-20 15:52 ` Optikos
1 sibling, 0 replies; 3+ messages in thread
From: Optikos @ 2020-01-20 15:52 UTC (permalink / raw)
On Sunday, January 19, 2020 at 3:07:18 PM UTC-6, Nasser M. Abbasi wrote:
> After reading this article
>
> <https://www.electronicdesign.com/technologies/embedded-revolution/article/21805823/assessing-the-ada-language-for-audio-applications>
>
> I was wondering: why then Ada is not used much for signal processing applications?
> Either for simulation or for actual implementation? Or is it? As I do not see
> many links for Ada in this field.
>
> From the article above:
>
> "This article presented an overview of the Ada language
> and its use in digital-signal-processing applications. We
> identified that Ada has many features supporting reliable DSP
> software development, such as strong data types, automatic range
> checks, overflow checks, and parameter modes."
>
> "In addition, the language facilitates DSP software
> development with its native support for fixed-point data
> types. Ada offers a great degree of flexibility and abstraction
> with features such as packages and generics. Moreover, its
> native support for multitasking with focus on safety makes
> it easy to convert single-threaded into multithreaded applications."
>
> Any thoughts on this subject? It seems to me, Ada would be perfect for
> signal processing instead of using weak typed languages like C and Python.
>
> --Nasser
There would be a chicken-&-egg problem to growing greater usage of Ada on audio signal processing:
1) Quite a few of the major algorithms (e.g., Goertzl filtering, Goertzl synthesis, PSK, FSK, Bluestein/chirp-Z, particle acoustics, stereo-music effects) would need impeccably trustworthy Ada implementations.
2) Quite a few of the major DSPs would need backends to FSF GNAT or some other Ada compiler. Usually this is the expensive work developed by the manufacturer of the DSP to hack a C compiler to have 16-, 24-, or even 32-bit bytes instead of 8-bit bytes, where the C and C++ standards define byte to be whatever char is and char is whatever the smallest addressable word size is, which is almost never 8 bits in DSPs. This usually also means that the C-compiler support for the DSP has an additional oddball library that packs 2 or 3 or 4 ASCII 8-bit chars in a 16-bit or 24-bit or 32-bit C char/byte. Because of the expense of development, usually only the DSP manufacturer has enough skin in the game to fund it (so that they create from a scratch a software marketplace for their hardware IC).
A business model for #1 above could be to compete head-to-head with boutique firms such as https://www.dspalgorithms.com/w3/index.php but in Ada instead of C. But this assumes that someone has deep enough pockets to substantially mimic the bulk of the product line of one of these DSP boutique software firms (or figure out a lucrative audio-app-domain that these DSP boutique firms ignore to their peril, such as some off-the-beaten-path sonar or some sort of flow-in-pipe monitoring system for pipelines/refineries/nuclear-plants).
Another approach would be to build out #1 over a 25-year period for the desktop hobbyist world (ignoring industrial DSP world), then opportunistically port all build-up of algorithm implementations to a DSP here and a DSP there as FSF GNAT supports a DSP by happenstance over a 25-year period. This is more of a then-a-miracle-happens solution.
^ permalink raw reply [flat|nested] 3+ messages in thread