From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:ae9:e809:: with SMTP id a9mr169297qkg.92.1579535548937; Mon, 20 Jan 2020 07:52:28 -0800 (PST) X-Received: by 2002:a05:6808:b1c:: with SMTP id s28mr13342531oij.2.1579535548694; Mon, 20 Jan 2020 07:52:28 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!g89no4411074qtd.0!news-out.google.com!o19ni326qtr.1!nntp.google.com!g89no4411064qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 20 Jan 2020 07:52:28 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.239.228; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.239.228 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: is Ada used much for signal processing? Audio, digital communications, digital image processing? From: Optikos Injection-Date: Mon, 20 Jan 2020 15:52:28 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:57907 Date: 2020-01-20T07:52:28-08:00 List-Id: On Sunday, January 19, 2020 at 3:07:18 PM UTC-6, Nasser M. Abbasi wrote: > After reading this article >=20 > >=20 > I was wondering: why then Ada is not used much for signal processing appl= ications? > Either for simulation or for actual implementation? Or is it? As I do not= see > many links for Ada in this field. >=20 > From the article above: >=20 > "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." >=20 > "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." >=20 > 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= . >=20 > --Nasser There would be a chicken-&-egg problem to growing greater usage of Ada on a= udio signal processing: 1) Quite a few of the major algorithms (e.g., Goertzl filtering, Goertzl sy= nthesis, PSK, FSK, Bluestein/chirp-Z, particle acoustics, stereo-music effe= cts) would need impeccably trustworthy Ada implementations. 2) Quite a few of the major DSPs would need backends to FSF GNAT or some ot= her Ada compiler. Usually this is the expensive work developed by the manu= facturer of the DSP to hack a C compiler to have 16-, 24-, or even 32-bit b= ytes instead of 8-bit bytes, where the C and C++ standards define byte to b= e 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 pack= s 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 boutiqu= e firms such as https://www.dspalgorithms.com/w3/index.php but in Ada inste= ad of C. But this assumes that someone has deep enough pockets to substant= ially mimic the bulk of the product line of one of these DSP boutique softw= are firms (or figure out a lucrative audio-app-domain that these DSP boutiq= ue firms ignore to their peril, such as some off-the-beaten-path sonar or s= ome 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 des= ktop hobbyist world (ignoring industrial DSP world), then opportunistically= port all build-up of algorithm implementations to a DSP here and a DSP the= re as FSF GNAT supports a DSP by happenstance over a 25-year period. This = is more of a then-a-miracle-happens solution.